分布式事务各种模式解释[粗略]

怼烎@ 2022-12-20 15:59 238阅读 0赞

### 文章目录 ###

*   *   *  TCC (Try-Confirm-Cancel) 模式
         *   *   *  Try 尝试阶段
                 *  Confirm 确认阶段
                 *  Cancel 撤销阶段
         *  SAGA模式
         *  Seata AT 模式
         *  两段提交
         *   *  角色
             *   *  事务协调者
                 *  事务参与者
             *  事务执行的流程
             *   *  准备阶段
                 *  提交阶段
         *  三段提交
         *   *   *  CanCommit阶段 询问阶段
                 *  PreCommit阶段 准备提交阶段
                 *  doCommit阶段 事务提交阶段
         *  三段提交和二段提交比较

### TCC (Try-Confirm-Cancel) 模式 ###

##### Try 尝试阶段 #####

1. 尝试执行，确保所有参与事务的服务都能正常执行，所有的数据库，缓存等参与的中间件都在线

##### Confirm 确认阶段 #####

2. 确认所有服务都在线，所有参与中间件都在线。执行事务

##### Cancel 撤销阶段 #####

3. 有某些服务不能参与，或者宕机。撤销尝试阶段的操作

### SAGA模式 ###

SAGA 补偿模式。假设所有的服务都正常执行（有点乐观锁的意思）。业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

### Seata AT 模式 ###

基于两段提交演变
    一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
    
    二阶段：
    提交异步化，非常快速地完成。
    回滚通过一阶段的回滚日志进行反向补偿。

[Seata AT 模式详解][Seata AT]

### 两段提交 ###

#### 角色 ####

##### 事务协调者 #####

协调事务的进行

##### 事务参与者 #####

事务的参与者

#### 事务执行的流程 ####

##### 准备阶段 #####

1.  由协调者想参与者发送准备指令。
2.  参与者收到指令后。要么直接返回失败，要么在本地执行事务（占用锁），写本地的redo和undo日志，但不提交，到达一种“万事俱备，只欠东风”的状态，并返回同意。

##### 提交阶段 #####

1.  协调者如果收到参与者的失败或者超时的消息。则向所有的参与者下发回滚指令。回滚准备阶段的操作。
2.  协调者如果如果收到所有参与者的确认指令。则向所有的参与者下发提交指令，所有参与者提交事务并释放所有事务处理过程中使用的锁资源。

### 三段提交 ###

##### CanCommit阶段 询问阶段 #####

1.  事务询问 协调者向参与者发送CanCommit请求。询问是否可以执行事务提交操作。然后开始等待参与者的响应。
2.  响应反馈 参与者接到CanCommit请求之后，正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态。否则反馈No

##### PreCommit阶段 准备提交阶段 #####

1.  发送预提交请求 协调者向参与者发送PreCommit请求，并进入Prepared阶段。
2.  事务预提交 参与者接收到PreCommit请求后，会执行事务操作，并将undo和redo信息记录到事务日志中。
3.  响应反馈 如果参与者成功的执行了事务操作，则返回ACK响应，同时开始等待最终指令。

##### doCommit阶段 事务提交阶段 #####

### 三段提交和二段提交比较 ###

1.  三段提交多了一个询问阶段，询问阶段并不占用锁。减少了堵塞。如果有某个参与者宕机。在第一阶段就终止了事务。
2.  二阶段第一个阶段就是准备阶段。如果有某个服务宕机。那么在协调者没有下发撤销指令前。锁资源被占用。服务进入堵塞。

[Seata AT]: https://seata.io/zh-cn/docs/dev/mode/at-mode.html