Distributed Transaction Processing

分布式事务有

• 2PC(Two-phase Commit), 3PC
• TCC(Try-Confirm-Cancel)
• 事务消息

事务消息适用的场景主要是那些需要异步更新数据，并且对数据实时性要求不太高的场景。比如我们在开始时提到的那个例子，在创建订单后，如果出现短暂的几秒，购物车里的商品没有被及时清空，也不是完全不可接受的，只要最终购物车的数据和订单数据保持一致就可以了。

SEATA mode

• AT
• TCC
• SAGA
• XA

---

1. 2PC 两段提交协议

   3PC 三段提交协议(弥补两端提交协议缺点)

2. TCC 或者 GTS(阿里)

3. 消息中间件最终一致性

4. LCN 分布式事物，理念“LCN 并不生产事务，LCN 只是本地事务的搬运工”。

---

术语

• TC (Transaction Coordinator) - 事务协调者
  维护全局和分支事务的状态，驱动全局事务提交或回滚。

• TM (Transaction Manager) - 事务管理器
  定义全局事务的范围：开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - 资源管理器
  管理分支事务处理的资源，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

2PC

1. PreCommit
2. DoCommit

3PC

1. CanCommit
2. PreCommit
3. DoCommit

CanCommit

之前 2PC 的一阶段是本地事务执行结束后，最后不 Commit,等其它服务都执行结束并返回 Yes，由协调者发生 commit 才真正执行 commit。而这里的 CanCommit 指的是 尝试获取数据库锁 如果可以，就返回 Yes。

这阶段主要分为 2 步

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

在阶段一中，如果所有的参与者都返回 Yes 的话，那么就会进入 PreCommit 阶段进行事务预提交。这里的PreCommit 阶段 跟上面的第一阶段是差不多的，只不过这里 协调者和参与者都引入了超时机制 （2PC 中只有协调者可以超时，参与者没有超时机制）。

3PC 第一阶段可以理解为心跳机制，检查服务是否健康。ping 一下发现服务是不可用的直接返回失败了，没必要再进行预处理阶段。预处理或者回滚比 ping 一下资源消耗是要小的。

相比较 2PC 而言，3PC 对于协调者（Coordinator）和参与者（Partcipant）都设置了超时时间，而 2PC 只有协调者才拥有超时机制。这解决了一个什么问题呢？

这个优化点，主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，

自动进行本地 commit 从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

另外，通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于 2PC 而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的。

以上就是 3PC 相对于 2PC 的一个提高（相对缓解了 2PC 中的前两个问题），但是 3PC 依然没有完全解决数据不一致的问题。