Alibaba Seata 学习日记(分布式事务协议)

Alibaba Seata 学习日记(分布式事务协议)

分布式事务协议

在分布式系统里，每个节点都可以知晓自己操作的成功或者失败，却无法直到其他节点操作的成功或失败。当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者回滚(rollback)

二阶段提交 (2PC)

二阶段提交协议（Two-phase Commit，即 2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理。

阶段

• 准备阶段
• 提交阶段

参与角色

• 协调者： 事务的发起者
• 参与者：事务的执行者

1. 第一阶段（voting phase投票阶段）

1. 协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待答复
2. 各参与者执行事务操作，将 undo 和 redo 信息记入事务日志中（但不提交事务）
3. 如参与者执行成功，给协调者反馈同意，否则反馈中止

2. 第二阶段（commit phase提交执行阶段）：

当协调者节点从所有参与者节点获得的相应消息都为同意时：

1. 协调者节点向所有参与者节点发出正式提交(commit)的请求。
2. 参与者节点正式完成操作，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送ack完成消息。
4. 协调者节点收到所有参与者节点反馈的ack完成消息后，完成事务。

如果任一参与者节点在第一阶段返回的响应消息为中止，或者 协调者节点在第一阶段的询问超时之前无法获取所有参与者节点的响应消息时：

1. 协调者节点向所有参与者节点发出回滚操作(rollback)的请求。
2. 参与者节点利用阶段1写入的undo信息执行回滚，并释放在整个事务期间内占用的资源。
3. 参与者节点向协调者节点发送ack回滚完成消息。
4. 协调者节点受到所有参与者节点反馈的ack回滚完成消息后，取消事务。

不管最后结果如何，第二阶段都会结束当前事务。

二阶段提交看起来确实能够提供原子性的操作，但是不幸的是，二阶段提交还是有几个缺点的：

1. 性能问题：执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
2. 可靠性问题：参与者发生故障。协调者需要给每个参与者额外指定超时机制，超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。
3. 数据一致性问题：二阶段无法解决的问题：协调者在发出 commit 消息之后宕机，而唯一接收到这条消息的参与者同时宕机了，那么即使协调者通过选举产生了新的协调者，者条事务的状态也是不确定的，没人直到事务是否被提交。

优点

尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。(其实也不能100%保证强一致)

缺点

实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

三阶段提交 (3PC)

三阶段提交协议，是二阶段提交协议的改进版本，三阶段提交有两个改动店。

• 在协调者和参与者中都引入超时机制
• 在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段各个参与阶段的状态是一致的。

也就是说，除了引入超时机制之外，3PC 把 2PC 的准备阶段再次一份为二，这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。处理流程如下：

1. 阶段一：CanCommit阶段

3PC 的 CanCommit 阶段其实和 2PC 的准备阶段很想。协调者向参与者发送 commit请求，参与者如果可以提交就返回 yes。否则返回NO响应。

1. 事务询问协调者向所有参与者发出包含事务内容的 canCommit 请求，询问是否可以提交事务，并等待所有参与者答复。
2. 响应反馈参与者收到 canCommit 请求后，如果任务可以执行事务操作，则反馈 yes 并进入预备状态，否则反馈 no

2. PreCommit阶段

协调者根据参与者的反应情况来决定是否可以进行事务的 PreCommit 操作。根据响应情况，有以下两种可能。

• 加入所有参与者反馈 yes，协调者预执行事务
  1. 发送与提交请求：协调者向参与者发送 PreCommit 请求，并进入准备阶段
  2. 事务预提交: 参与者收到 PreCommit 请求后，会执行事务操作，并将 undo 和 redo 信息记录到事务日志中(但不提交事务)。
  3. 响应反馈: 如果参与者成功的执行了事务，则返回 ACK 响应，同时开始等待最终指令。
• 加入有任何一个参与者向协调者发送了 No 响应，或者等待超时之后，协调者都没有接到参与者的响应，那么就执行事务终端。
  1. 发送中断请求：协调者向所有参与者发送 abort 请求。
  2. 中断事务：参与者收到来自协调者的 abort 请求之后(或超时之后，仍未收到协调者的请求),执行事务中断。

3. doCommit阶段 该阶段进行真正的事务提交，也可以分为以下两种情况。

注意:进入阶段3后，无论协调者出现问题，或者协调者与参与者网络出现问题，都会导致参与者无法收到协调者发出的 doCommit 请求或 abort 请求。此时，参与者都会在等待超时之后，继续执行事务提交。

1. 执行提交

   所有参与者均反馈 ack 响应，执行真正的事务提交

   1. 发送提交请求协调者收到参与者发送的 ACK 响应，那么他将从预提交状态进入提交状态。并向所有参与者发送 doCommit 请求。

   2. 事务提交 参与者接收到 doCommit 请求之后，执行正式的事务提交。并在完成事务提交之后释放所有的事务资源。

   3. 响应反馈 事务提交完之后，向协调者发送 ack 响应。

   4. 完成事务 协调者收到所有参与者的 ack 响应之后，完成事务。

      

2. 中断事务

   任何一个参与者反馈 no, 或者等待超时后协调者尚无法收到所有参与者的反馈，即中断事务

   1. 发送中断请求 如果协调者处于工作状态，向所有参与者发出 abort 请求。
   2. 事务回滚 参与者收到 abort 请求，利用其在阶段二记录的 undo 信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。
   3. 反馈结果 参与者完成事务回滚之后，向协调者返回 ACK 消息。
   4. 中断事务 协调者接收到参与者反馈的 ACK 消息之后，执行事务的中断。

在 doCommit 阶段，如果参与者无法及时接收到来自协调者的 doCommit 或者 abort 请求时，会在等待超时之后，会继续进行事务提交。(其实这个应该是基于概率来决定的，当进入第三阶段，说明参与者在第二极端已经收到了 PreCommit 请求，那么协调者产生 PreCommit 请求的前提条件是他参与者的 CanCommit 响应都是 yes。(一旦参与者收到了 PreCommit,意味着他直到大家其实都同意修改了)所以，一句话概括，当进入第三阶段时，由于网络超时等原因，虽然参与者没有收到 commit 或者 abort 响应，但是他有理由相信：成功提交的几率很大。)

优点: 相比二阶段提交，三阶段提交降低了阻塞范围，在等到超时后协调者或者参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。

**缺点:**数据不一致问题依然存在，当在参与者收到 PreCommit 请求后等待 doCommit 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

reference

https://www.bilibili.com/video/BV1uJ411h7px?from=search&seid=17886022887642019485

https://www.it235.com/%E9%AB%98%E7%BA%A7%E6%A1%86%E6%9E%B6/SpringCloudAlibaba/seata.html#%E4%BA%8B%E5%8A%A1