分布式协同 - 分布式事务_TCC解决方案

导图

---

Pre

随着大流量、高并发业务场景的出现，对系统可用性的要求变得越来越高，这时 CAP 理论和 BASE 理论逐渐进入人们的视野，柔性事务成为分布式事务的主要实现方式，TCC 作为补偿事务也位列其中.

TCC（Try-Confirm-Cancel）的核心思想是对于每个资源的原子操作，应用程序都需要注册一个与此操作对应的确认操作和补偿（撤销）操作。其中确认操作负责在原子操作执行成功时进行事务提交，补偿操作负责在原子操作执行失败时对事务进行回滚。

---

流程图

1. Try阶段（资源锁定）：

   • 客户端（A）发起请求，通知服务B进行事务操作。
   • 服务B执行Try操作，尝试锁定资源（例如扣款或占用库存）。此时，服务B的资源被锁定，但尚未提交任何操作。
   • 服务B返回给客户端A，表示资源已锁定，并准备进入下一阶段。

2. Confirm阶段（提交）：

   • 客户端（A）根据其他服务的响应，决定是否进入Confirm阶段。
   • 服务C接收到确认请求后，执行Confirm操作，将之前的预处理结果提交（如真正扣款、更新库存等）。
   • 如果操作成功，服务C返回确认成功给客户端A，表示事务提交完成。

3. Cancel阶段（回滚）：

   • 如果在Try阶段发现某些条件未达成（例如余额不足，库存不足等），或者在Confirm阶段发生错误，客户端或服务将请求进入Cancel阶段。
   • 服务C会执行Cancel操作，回滚之前的操作（如退还款项或恢复库存）。
   • 服务C返回取消失败信息，客户端A可以根据返回结果进行相应的补救措施。

---

2PC VS 3PC VS TCC

2PC（Two-Phase Commit，二阶段提交）

2PC协议是分布式事务中最基础的协议，分为两个阶段：

1. 准备阶段（Voting Phase）：协调者（通常是事务管理器）向所有参与者发送“准备提交”请求，要求参与者执行事务操作并保留结果，但不提交数据，参与者需要返回“准备好”或“无法提交”的响应。

2. 提交阶段（Commit Phase）：如果所有参与者都返回“准备好”，则协调者发送“提交”请求，所有参与者正式提交操作。如果任何一个参与者返回“无法提交”，则协调者发送“回滚”请求，所有参与者回滚操作。

优点：

• 实现简单，易于理解。

缺点：

• 阻塞问题：如果协调者崩溃，参与者会一直等待协调者的决策，造成系统阻塞。
• 单点故障：协调者是单点，若协调者失败，事务无法完成。
• 资源占用：参与者需要长时间持有锁，直到事务提交或回滚。

---

3PC（Three-Phase Commit，三阶段提交）

3PC是在2PC基础上改进而来的，目的是解决2PC中的阻塞问题。它增加了一个额外的阶段来进行更细粒度的事务状态控制。

1. 询问阶段（CanCommit Phase）：协调者询问所有参与者是否可以执行事务，并预备提交。参与者在此阶段进行必要的预处理。

2. 预提交阶段（PreCommit Phase）：所有参与者确认可以提交后，协调者要求所有参与者进行预提交操作。此时，参与者已经做好提交操作的准备，但还没有真正提交。

3. 提交阶段（DoCommit Phase）：协调者正式通知所有参与者提交操作，事务正式完成。

优点：

• 改进了2PC的阻塞问题，因为3PC在协调者崩溃后参与者不会一直等待，可以通过预提交阶段保证一致性。

缺点：

• 实现复杂。
• 仍然存在一定的网络分区和故障恢复问题。

TCC（Try-Confirm-Cancel）

TCC是分布式事务处理中较为复杂的一种方案，通常在资源管理和高一致性要求的场景下使用。它将分布式事务拆解为三个阶段：Try、Confirm和Cancel。

1. Try（尝试）：在此阶段，参与者执行尝试操作，如锁定资源，并确保幂等性。Try阶段完成后，系统处于“预提交”状态，但未真正提交数据。

2. Confirm（确认）：在所有操作都顺利完成时，协调者通知各参与者提交事务。此时所有操作都是最终的提交。

3. Cancel（取消）：如果某些操作失败，或者出现异常，协调者会通知参与者回滚操作，恢复到事务前的状态。

优点：

• 高度可控，支持显式的回滚。
• 支持幂等性操作，能更好地处理异常场景。

缺点：

• 需要在每个参与者上实现Try、Confirm和Cancel逻辑，复杂度较高。
• 性能和资源消耗较大，因为每个参与者都需要进行锁定和操作恢复。

---

2PC、3PC与TCC的区别

特性	2PC	3PC	TCC
阶段	2个阶段：准备、提交	3个阶段：询问、预提交、提交	3个阶段：尝试、确认、取消
阻塞问题	存在，协调者崩溃时参与者会一直阻塞	解决了部分阻塞问题，但不完全消除	无阻塞问题，失败时有明确的回滚操作
容错能力	较差，协调者故障会导致整个事务失败	相较2PC，容错能力提高，但仍有不足	较强，支持回滚，适合高度容错和一致性要求的场景
资源占用	参与者需要长时间持有锁，资源占用较大	参与者需要长时间持有锁，资源占用较大	各参与者在不同阶段持有锁，资源占用较大
复杂度	简单实现，但功能受限	实现较复杂，增加了容错机制	实现较复杂，需要业务逻辑支持
适用场景	一致性要求较低的小型分布式系统	对容错性有一定要求的分布式事务系统	高一致性、高可用性要求的复杂场景，尤其是金融、库存管理等

---

2PC、3PC与TCC的联系

• 相似性：这三种协议都属于分布式事务协议，目的是保证分布式系统中多个参与者的一致性和数据的可靠性。它们都涉及到协调者与参与者之间的交互，以及如何确保事务的一致性和成功提交。

• 演化关系：2PC是最早的分布式事务协议，虽然实现简单，但存在阻塞和单点故障的问题。为了避免这些问题，3PC在2PC的基础上增加了一个预提交阶段，进一步解决了阻塞问题。而TCC则通过引入Try、Confirm和Cancel三个阶段，提供了更灵活的事务控制，适合于更复杂的分布式事务场景。

• 应用场景重叠：这三种协议在一些场景中可以互相替代，例如金融系统的支付操作等高一致性场景。但在不同的系统需求下，选择的协议会有所不同。TCC特别适合对事务回滚有要求且资源操作可幂等的场景。