SpringCloud微服务原理与实战第八章读书笔记分布式事务

分布式事务

X/Open分布式事务模型

X/Open DTP 是X/Open组织定义的一套分布式事务的标准，这个事务使用两阶段提交的提点，来保证分布式事务的一致性问题。

1. AP：Application，表示应用层。
2. RM：Resource Manager，表示资源管理器
3. TM：Transaction Manager 表示事务管理器，一般指事务协调者，负责协调和管理事务，提供AP变成接口或管理RM。可以理解为Spring中提供的Transaction Manager。
   

如图所示角色和关系与本地事务的原理基本一致，唯一不同的在于，如果此时Rm代表数据库，那么TM需要能够管理多个数据库的事务：

1. 配置TM，把多个RM注册到TM，相当于TM注册RM作为数据源。
2. AP从TM管理的RM中获取链接，如果RM时数据库则获取JDBC链接。
3. AP向TM发起第一个全局事务，生成全局事务ID（XID），XID会通知各个RM。
4. ap通过第二部获取的链接直接操作RM完成数据操作，这是AP在每次操作的同时会把XID传递给RM。
5. AP结束全局事务，TM会通知各个RM全局事务结束
6. 根据各个RM的事务执行情况决定事务是提交还是会滚。
   

两阶段提交协议

在上图中TM实现了多个RM事务的管理，实际上会涉及两个阶段的提交，一个是事务的准备阶段，一个是事务的提交或者会滚的阶段。这两个阶段都是由事务管理器发起的。两个阶段提交协议的执行流程

1. 准备阶段：TM通知RM准备分支事务，记录事务日志，并告知事务管理器的准备结果。
2. 提交/会滚阶段：如果所有的资源管理器在准备阶段都明确的返回成功，则事务管理器TM向所有的资源管理器RM发起事务提交指定完成数据变更。反之发起会滚指令。

两阶段事务存在的缺点

1. 同步阻塞：所有参与者RM都是事务阻塞型，对于任何一次指令都必须要有明确的响应才能继续进行下一步，否则会处于阻塞状态，占用的资源一直被锁定。
2. 过于保守：任何一个节点失败都会造成会滚。
3. 事务协调者的单点故障：如果协调者在第二阶段出现故障，那么其他参与者RM会一致处于锁定状态下。
4. “脑裂”导致数据不一致问题：在第二阶段中，事务协调者向所有的参与者发送commit请求后，发生局域网络波动导致一部分的参与者收到commit请求，这部分参与者RM收到请求后会执行commi操作，但是未收到commit请求的节点无法提交导致数据不一致问题。
   

三阶段提交协议

1. CanCommit（询问阶段）：事务协调者向参与者发送事务执行请求，询问是否可以完成指令，参与者只需要回答是或者不是，不需要真正的执行事务，这个阶段会有超时终止机制。
2. PreCommit（准备阶段）：事务协调者会根据参与者的反馈结果决定是否继续执行，如果在询问阶段参与者都返回可执行，则事务协调者会向所有的参与者发送PreCommit请求，参与者收到请求后写redo和undo日志，执行事务操作但是不提交事务，然后返回ACK响应等待事务协调者下一步通知，如果在询问阶段任意参与者返回不能执行操作的结果，那么事务协调者会想所有参与者下发事务中断请求。
3. DoCommit（提交或回滚）：这个阶段也存在者两种结果，和上边一样向所有的参与者发起提价事务，如果上个阶段有参与者返回失败，就发送回滚请求。
   

三段式事务和两阶段事务的区别

1. 增加了一个CanCommit阶段，用于询问所有参与者是否可以执行事务操作并且响应，它的好处是可以尽早发现无法执行操作而后终止的行为。
2. 在准备阶段之后，事务协调者和参与者都引入了超时机制，一旦超时，事务协调者和参与者会继续提交事务，并且认为处于成功状态，因为在这种情况下事务默认为成功的可能性更大。
   实际上，一旦超时，在三阶段提交协议下还是有可能出现数据不一致的情况，只是概率小一些。另外最大的好处是引入了超时机制，可以防止资源锁定。

CAP定理和BASE理论

CAP定理

CAP定理，又叫布鲁尔定理。它是指在分布式系统中不可能同时满足一致性（C：Consistency）、可用性（A：Availability）、分区容错性（P：Partition Tolerance）。最多同时满足两个。

1. C：数据在多个副本中要保持强一致性，
2. A：系统对外提供的服务必须一直处于可用状态，在任何故障下，客户端都能在合理的时间内获得服务端提供的非错误响应。
3. P：在分布式系统中遇到任何网络分区故障，系统仍然能够正常对外提供服务。

CAP定理证明，在分布式系统中，要么满足CP，或者AP不可能实现满足CAP或者CA。原始是网络通信并不是绝对可靠的，比如网络延迟、网络异常等都会导致系统故障。所以在分布式系统中P是绝对会出现，也是需要满足分区容错。

1. AP：对于AP而言相当于放弃了强一致性，实现最终一致性。
2. CP，放弃了高可用性，实现强一致性。

BASE理论

BASE理论是由CAP中的一致性和可用性不可兼得而衍生出来一种信的思想，BASE理论的核心思想是通过牺牲数据的强一致性来获得高可用性。

1. Basically Available（基本可用）：分布式系统在出现故障时，允许损失一部分功能的可用性，保证核心功能的可用。
2. Soft state（软状态）：允许系统中的数据存在中间态，这个状态不行赢系统的可用性，也就是允系统中不同节点的数据副本之间的同步延迟。
3. Eventually Consistent （最终一致性）：中间状态的数据在经过一段时间之后，会达到一个最终的数据一致性。

分布式事务问题的常见解决方案

TCC补偿方案

1. Try：这个阶段主要是对数据的校验或者资源预留。
2. Confirm：确认真正执行的任务，只操作Try阶段的预留的资源。
3. Cancel：取消执行，释放Try预留的资源。
   

基于可靠性消息的最终一致性方案

它主要是通过消息中间件（Kafka、RocketMq、RabbitMQ）的可靠性机制来实现数据一致性的投递。

最大努力通知型

分布式事务框架Seata

Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。它提供了AT、TCC、Saga和XA事务模式。

AT模式

AT模式是Seata蕞主推的分布式事务解决方案，它是基于XA演进而来的一种分布式事务模式，所以它也是分为三大块，分别是TM、RM、TC，其中TM和RM作为Seata的客户端与业务系统集成，TC作为Seata的服务器独立部署。TM表示事务管理器（Transaction Manager），它负责向TC注册一个全局事务，并声称一个全局唯一的XID。在AT模式下，每个数据库资源被当作一个RM处理，在业务层面通过JDBC标准的借口访问RM时，Seata会对所有请求进行拦截，每个本地事务进行提交时，RM都会想TC（Transaction coordinator）注册一个分支事务。

1. TM向TC注册全局事务，并声称XID。
2. RM向TC注册分支事务，并将其纳入XID对应的全局事务范围。
3. RM向TC回报资源的准备情况。
4. TC汇总所有事务参与者的执行状态，决定分布式事务是全部回滚还是提交。
5. TC通知所有的RM提交或者回滚。

Saga模式

Saga模式又称为长事务解决方案，主要是在没有两阶段提交的情况下如何解决分布式事务。其核心思想是把一个业务流程中的长事务拆分为多个本地短事务，业务流程中的每个参与者都提交真是的提交给该本地短事务，如果有一个参与只执行失败了，则通过补偿机制补偿前面已经成功的参与者。

1. 执行方式是两种一种正常执行T系列。
2. 一种执行其中一个环节失败，执行C系列的补偿事务。

Saga的补偿方式

1. 向后恢复，也就是上面执行C系列的过程。
2. 向前恢复，也就是不尽兴补偿，而是对失败的事务进行重试，这种方式比较适合于事务必须执行成功的场景。

Saga的优劣势

与XA或者TCC相比，它的优势包括：

1. 一阶段直接提交本地事务，没有锁等待，性能较高。
2. 在事件驱动的模式下，短事务可以执行异步
3. 补偿机制的实现比较简单。

缺点

1. 不提供原子性，和个理性

AT模式的实现原理

AT是基于XA事务模型演变来的。

1. 一阶段，业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和链接资源。
2. 二阶段，提交一步化，非常快速的完成。回滚通过第一阶段的回滚日志进行反向补偿。

AT模型第一阶段的实现原理

1. 通过DataSourceProxy对业务SQL进行解析，得到SQL的类型，表、条件等信息
2. 查询修改之前将数据镜像，根据解析得到的条件信息生成查询语句，定位数据。
3. 执行业务SQL：更新数据
4. 查询修改之后的数据镜像，根据之前景象的结果，通过逐渐定位数据，得到修改之后的数据。
5. 插入回滚日志：把前、后景象数据及业务SQL相关的信息组成一条回滚日志记录，插入UNDO_LOG表中。
6. 提交前，向TC注册分支事务：申请tbl_repo表中主键值等于1的记录的全局锁。
7. 本地事务提交：业务数据的更新和前面的步骤中生成的UNDO_LOG一并提交。
8. 将本地事务提交的结果上报给TC；

AT模型的第二阶段的实现原理

事务提交

1. 分支事务收到TC的提交请求后把请求放入一个异步任务队列中，并马上返回提交成功的结果给TC。
2. 从一步队列中执行分支，提交请求，鼻梁删除对应的UNDO_LOG

事务回滚

1. 通过XID和branchID 查询到响应的UNDO_LOG记录
2. 数据校验：拿UNDO_LOG中的afterImage镜像数据与当前业务表中的数据进行比较，如果不同，说明数据被当前全局事务之外的动作做了修改，那么事务将不会回滚。
3. 如果afterImage中的数据和当前业务表中的对应数据相同，则根据UNDO_LOG中的beforeImage镜像数据和业务SQL的相关信息生成回滚语句并执行。
4. 提交本地事务，并把本地事务的执行结果上报给TC。

关于事务的隔离性保证

写隔离

读隔离

在本地数据库的事务隔离级别为提交读的前提下Seata AT的默认是为提交读。