文章目录
- 导图
- Pre
- 流程图
- 2PC VS 3PC VS TCC
- 2PC（Two-Phase Commit，二阶段提交）
- 3PC（Three-Phase Commit，三阶段提交）
- TCC（Try-Confirm-Cancel）
- 2PC、3PC与TCC的区别
- 2PC、3PC与TCC的联系
导图
Pre
随着大流量、高并发业务场景的出现，对系统可用性的要求变得越来越高，这时 CAP 理论和 BASE 理论逐渐进入人们的视野，柔性事务成为分布式事务的主要实现方式，TCC 作为补偿事务也位列其中.
TCC（Try-Confirm-Cancel）的核心思想是对于每个资源的原子操作，应用程序都需要注册一个与此操作对应的确认操作和补偿（撤销）操作。其中确认操作负责在原子操作执行成功时进行事务提交，补偿操作负责在原子操作执行失败时对事务进行回滚。
流程图
-
Try阶段（资源锁定）：
- 客户端（A）发起请求，通知服务B进行事务操作。
- 服务B执行Try操作，尝试锁定资源（例如扣款或占用库存）。此时，服务B的资源被锁定，但尚未提交任何操作。
- 服务B返回给客户端A，表示资源已锁定，并准备进入下一阶段。
-
Confirm阶段（提交）：
- 客户端（A）根据其他服务的响应，决定是否进入Confirm阶段。
- 服务C接收到确认请求后，执行Confirm操作，将之前的预处理结果提交（如真正扣款、更新库存等）。
- 如果操作成功，服务C返回确认成功给客户端A，表示事务提交完成。
-
Cancel阶段（回滚）：
- 如果在Try阶段发现某些条件未达成（例如余额不足，库存不足等），或者在Confirm阶段发生错误，客户端或服务将请求进入Cancel阶段。
- 服务C会执行Cancel操作，回滚之前的操作（如退还款项或恢复库存）。
- 服务C返回取消失败信息，客户端A可以根据返回结果进行相应的补救措施。
2PC VS 3PC VS TCC
2PC（Two-Phase Commit，二阶段提交）
2PC协议是分布式事务中最基础的协议，分为两个阶段：
-
准备阶段（Voting Phase）：协调者（通常是事务管理器）向所有参与者发送“准备提交”请求，要求参与者执行事务操作并保留结果，但不提交数据，参与者需要返回“准备好”或“无法提交”的响应。
-
提交阶段（Commit Phase）：如果所有参与者都返回“准备好”，则协调者发送“提交”请求，所有参与者正式提交操作。如果任何一个参与者返回“无法提交”，则协调者发送“回滚”请求，所有参与者回滚操作。
优点：
- 实现简单，易于理解。
缺点：
- 阻塞问题：如果协调者崩溃，参与者会一直等待协调者的决策，造成系统阻塞。
- 单点故障：协调者是单点，若协调者失败，事务无法完成。
- 资源占用：参与者需要长时间持有锁，直到事务提交或回滚。
3PC（Three-Phase Commit，三阶段提交）
3PC是在2PC基础上改进而来的，目的是解决2PC中的阻塞问题。它增加了一个额外的阶段来进行更细粒度的事务状态控制。
-
询问阶段（CanCommit Phase）：协调者询问所有参与者是否可以执行事务，并预备提交。参与者在此阶段进行必要的预处理。
-
预提交阶段（PreCommit Phase）：所有参与者确认可以提交后，协调者要求所有参与者进行预提交操作。此时，参与者已经做好提交操作的准备，但还没有真正提交。
-
提交阶段（DoCommit Phase）：协调者正式通知所有参与者提交操作，事务正式完成。
优点：
- 改进了2PC的阻塞问题，因为3PC在协调者崩溃后参与者不会一直等待，可以通过预提交阶段保证一致性。
缺点：
- 实现复杂。
- 仍然存在一定的网络分区和故障恢复问题。
TCC（Try-Confirm-Cancel）
TCC是分布式事务处理中较为复杂的一种方案，通常在资源管理和高一致性要求的场景下使用。它将分布式事务拆解为三个阶段：Try、Confirm和Cancel。
-
Try（尝试）：在此阶段，参与者执行尝试操作，如锁定资源，并确保幂等性。Try阶段完成后，系统处于“预提交”状态，但未真正提交数据。
-
Confirm（确认）：在所有操作都顺利完成时，协调者通知各参与者提交事务。此时所有操作都是最终的提交。
-
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特别适合对事务回滚有要求且资源操作可幂等的场景。
