企业官网建设流程全解析

分布式事务理论

在分布式框架中，一个流程可能会涉及到多个服务，此时就需要使用分布式事务来保证这整个流程的事务，也就是保证这个流程要么都执行要么都不执行。实际上，只要跨数据库的场景都会使用到分布式事务来保证操作的原子性，假设某个数据库量太大，进行了分库的操作，此时数据库的事务已经无法满足需求了，就需要使用分布式事务来保证事务。

对于事务而言，它是有ACID的四个特性的，但是分布式事务较为特殊，它其实无法完全满足这四个特性，往往只能进行折中处理。

在分布式事务中有两个经典的理论，CAP以及BASE理论。

CAP

CAP代表的是可用性、一致性以及分区容错性。

可用性指的是在分布式架构下，我们不论访问哪个节点，都需要能够正常访问，不能出现阻塞或拒绝的情况；

而一致性则指的是在分布式的集群架构下，当用户访问相同的数据时，每个节点锁返回的数据应该都是一致的；

最后来说分区容错性，这个需要拆开来看，首先是分区，这个指的是当某一个服务有3台实例A、B、C，此时由于网络问题导致C与A、B之间断开联系了，此时就分为两个区，这个情况就叫分区，而分区容错则指的是当出现分区的情况下，整个系统也要能够正常的为用户提供服务。

因此对于CAP这三个特性而言，分区容错是一定要保证的，否则当出现网络抖动时，整个分布式架构直接崩溃，这对系统而言是非常灾难的。在保证分区容错的前提下，还是刚才A、B、C的例子，当用户访问到C机器时，此时由于C被孤立出来了，无法与A、B两台机器进行通信，那么它的数据一定是过时的，在这种情况下，如果想要保证可用性，就只能让C机器返回过期的数据，这样就无法保证数据的一致性；而如果想保证一致性，则只能等A、B与C之间的连接重新建立起来，在这个过程中，C实际上是不可用的，可用性就无法进行保证。

上面这段话就回答了这个理论两个比较经典的问题，分区容错为什么一定要保证以及在保证分区容错性的前提下，一致性与可用性为什么只能保证一个。

因此在实际的开发中，需要根据业务需求来选择保证CP还是AP。

而在实际的开发中，当我们选择了AP的方案时，就可以使用BASE理论来指导AP方案。

BASE

接下来说说base理论，这个理论其实就是CAP中AP的指导思想，帮助我们实现最终一致性的。BASE有基本可用、软状态以及最终一致三要素，这三要素并不像CAP一样是取舍的关系，而是层层递进的关系。

基本可用指的是服务出现故障时，允许牺牲部分可用性，来保证整体架构的可用性。

软状态指的是在整个流程中，允许出现中间态，也就是在过程中可以出现数据的不一致。

最终一致性则指的是虽然在过程中无法保证强一致性，但是当软状态结束之后，整个数据要达成最终一致的状态。

例如一个下单业务中，其中涉及到订单服务、账户服务以及库存服务，在整个流程中，前两个服务都正常执行并提交事务，此时对于整个流程而言，它们是存在中间态的，因为整个流程还没走完，此时在执行最后一个服务的时候报错了，此时需要对前两个服务进行回滚，但是前两个服务执行完毕之后直接将事务提交了，此时就只能对前两个事务进行逆向操作，来实现回滚的逻辑。

总结

ACID 是数据库事务完整性的理论，CAP 是分布式存储系统的设计理论，BASE 是 ACID 在分布式场景中的替代品，同时也是 AP 架构的工程实践指南。

分布式事务解决方案

分布式事务最常见的是使用seata组件解决

seata

这个组件是阿里出的spring cloud组件，专门用于处理分布式事务问题的组件。

它包含以下三部分：

TC（事务协调器）：维护全局事务以及分支事务的状态，协调全局事务提交以及回滚

TM（事务管理器）：定义全局事务的范围、开启全局事务、提交以及回滚全局事务

RM（资源管理器）：在事务中的每一个微服务就是一个RM

在seata中，有不同的模式，不同的模式对应不同的流程。

XA模式

1. 首先由事务管理器来开启全局事务

2. 之后事务管理器调用分支事务，让每一个分支事务注册到事务协调器中

3. 接下来各个微服务执行自己的业务sql

4. 分支事务向事务协调器报告自己的事务状态

5. 当事务管理器提交全局事务的时候，事务协调器此时检查分支事务所提交的事务状态，以此判断分支事务是提交还是回滚，进而决定事务协调器是提交还是回滚全局事务

这整个流程实际上是实现了CAP思想中的CP思想，保证了数据的强一致性，因为对于所有的分支事务而言，它们只在最后一步才会同时进行提交或回滚，这也就意味着当微服务没有执行完时，其它已经执行完毕的服务只能等待，性能上会有降低

AT模式

对于这种模式，其实它算是XA模式的优化，前面的步骤都一样，但是到了执行业务sql这一步的时候会有区别，AT模式在执行完业务sql之后会直接进行提交，之后假设需要回滚，直接利用undo log实现对业务sql的回滚即可，如果不需要回滚，则直接将undo log生成的命令直接删除即可。

这种模式的好处就是不再需要像XA模式那样让每个服务之间进行等待，每个服务执行完业务sql之后直接提交即可，通过引入undo log在保证强一致的情况下还提升的性能，通常开发中使用的比较多的就是AT模式，也是seata官方推荐的模式

TCC模式

这个模式主要涉及到三个步骤，try、confirm以及cancle。

当执行业务sql的时候，先执行try操作，也就是对要操作的资源进行预留，如果此时数据库中有这么多的资源，此时就可以进行confirm操作，这个操作就是实际的执行业务sql的操作，如果执行失败，则走到cancle的逻辑，对前一步的confirm进行回滚。假设在try操作的时候发现数据库中没有这么多资源，此时就会直接对资源进行解冻。

这个模式的流程，其实性能相较于XA模式也是较高的，但是它的三个步骤都需要我们手动编码实现，代码耦合度太高了，而前面两个模式都是组件帮助我们进行实现。

MQ