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

TCC (Try-Confirm-Cancel) 模式

Try 尝试阶段

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

Confirm 确认阶段

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

Cancel 撤销阶段

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

SAGA模式

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

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. 协调者如果如果收到所有参与者的确认指令。则向所有的参与者下发提交指令，所有参与者提交事务并释放所有事务处理过程中使用的锁资源。

三段提交和二段提交比较

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