分布式事务 TCC

落日映苍穹つ 2024-03-16 14:03 12阅读 0赞

tip：作为程序员一定学习编程之道，一定要对代码的编写有追求，不能实现就完事了。我们应该让自己写的代码更加优雅，即使这会费时费力。

推荐：**[体系化学习Java（Java面试专题）][Java_Java]**

#### 文章目录 ####

*  一、简介
 *  二、运行流程
 *  三、优缺点
 *  四、TCC 和 2PC 相比
 *  五、TCC 和 3PC 相比
 *  六、TCC 如何解决幂等问题？
 *  七、TCC 如何解决悬挂问题？
 *  八、TCC 在 cancel 阶段如果出现失败怎么处理？

## 一、简介 ##

TCC（Try-Confirm-Cancel）是一种分布式事务解决方案，也是一种补偿式的分布式事务。它通过在业务逻辑中嵌入Try-Confirm-Cancel三个阶段的逻辑，来保证分布式事务的一致性和可靠性。TCC协议的核心思想是“补偿机制”，即在分布式事务出现异常或失败时，通过执行相反的操作来补偿之前的操作，从而达到事务的一致性。

## 二、运行流程 ##

TCC协议的三个阶段分别为：

1.  Try 阶段：在这个阶段，业务逻辑会预留资源，并检查所有的前提条件是否满足。如果检查通过，则执行业务逻辑，否则回滚预留的资源。
2.  Confirm 阶段：在这个阶段，业务逻辑会确认执行结果，如果确认通过，则提交所有的操作，否则回滚所有的操作。
3.  Cancel 阶段：在这个阶段，业务逻辑会撤销之前执行的操作，并释放之前预留的资源。

## 三、优缺点 ##

TCC协议相比于2PC和3PC协议，具有以下优点：

1.  可以在业务逻辑中自定义补偿操作：TCC协议允许在业务逻辑中自定义补偿操作，可以根据具体业务场景进行灵活配置，从而提高了协议的适用性和灵活性。
2.  支持分布式事务：TCC协议可以支持分布式事务，可以在跨多个服务之间保证事务的一致性和可靠性。
3.  可以减少阻塞时间：TCC协议中的Try阶段可以预留资源，从而减少了阻塞时间，提高了系统的性能。

需要注意的是，TCC协议虽然具有很多优点，但也存在一些问题，例如需要在业务逻辑中嵌入Try-Confirm-Cancel三个阶段的逻辑，实现起来可能会比较复杂；同时，TCC协议也需要考虑幂等性等问题。因此，在实际应用中，需要根据具体情况选择合适的分布式事务解决方案。

## 四、TCC 和 2PC 相比 ##

TCC和2PC都是分布式事务解决方案，它们在保证分布式事务一致性和可靠性方面有一些相似之处，但也存在一些不同点。

相同点：

1.  都是为了保证分布式事务的一致性和可靠性而设计的；
2.  都需要在多个参与者之间进行协调和通信，以确保事务的正确执行；
3.  都需要考虑事务的超时、异常处理等问题。

不同点：

1.  TCC协议可以在业务逻辑中自定义补偿操作，而2PC协议的补偿操作相对固定；
2.  TCC协议的Try阶段可以预留资源，从而减少阻塞时间，提高系统性能，而2PC协议需要等待所有参与者的响应，可能会导致阻塞；
3.  TCC协议相对于2PC协议更加灵活，可以根据具体业务场景进行定制，但实现起来可能会比较复杂。

总之，TCC和2PC协议都是分布式事务解决方案，需要根据具体业务场景选择合适的解决方案。如果业务逻辑比较复杂，需要灵活定制补偿操作，可以选择TCC协议；如果业务逻辑比较简单，可以选择2PC协议。

## 五、TCC 和 3PC 相比 ##

TCC和3PC都是分布式事务解决方案，它们在保证分布式事务一致性和可靠性方面有一些相似之处，但也存在一些不同点。

相同点：

不同点：

1.  TCC协议可以在业务逻辑中自定义补偿操作，而3PC协议的补偿操作相对固定；
2.  TCC协议相对于3PC协议更加灵活，可以根据具体业务场景进行定制，但实现起来可能会比较复杂；
3.  3PC协议相对于TCC协议更加稳定，可以在网络不稳定或参与者宕机的情况下保证事务的正确执行；
4.  TCC协议的Try阶段可以预留资源，从而减少阻塞时间，提高系统性能，而3PC协议需要等待所有参与者的响应，可能会导致阻塞。

TCC和3PC协议都是分布式事务解决方案，需要根据具体业务场景选择合适的解决方案。如果业务逻辑比较复杂，需要灵活定制补偿操作，可以选择TCC协议；如果需要更高的稳定性和可靠性，可以选择3PC协议。

## 六、TCC 如何解决幂等问题？ ##

通过增加一张事务状态表。

TCC通过在Try和Confirm阶段添加幂等性校验来解决幂等问题。在Try阶段，TCC会生成一个全局唯一的事务ID，同时将该事务ID和Try阶段执行的业务操作记录在一个事务日志中，并将事务日志状态设置为“TRYING”。在Confirm阶段，TCC会再次检查事务日志状态，如果状态为“CONFIRMING”，则说明该事务已被提交，此时TCC会执行Confirm操作，并将事务日志状态设置为“CONFIRMED”。如果状态为其他值，则说明该事务已被取消或已提交，此时TCC会直接返回成功，避免重复执行操作。在Cancel阶段也是类似的，TCC会检查事务日志状态，如果状态为“CANCELLING”，则说明该事务已被取消，此时TCC会执行Cancel操作，并将事务日志状态设置为“CANCELLED”。如果状态为其他值，则说明该事务已被提交或已取消，此时TCC会直接返回成功，避免重复执行操作。通过这种方式，TCC可以保证在分布式环境下执行业务操作的幂等性。

## 七、TCC 如何解决悬挂问题？ ##

什么是悬挂问题？  
某种原因导致Cancle在Try之前执行，那么再执行Try导致资源不能释放。

解决方案：  
1、TCC通过设置Try阶段的超时时间来解决悬挂问题。在TCC中，Try阶段需要预留资源，如果Try阶段执行时间过长，可能会导致资源被长时间占用，从而影响系统的性能。为了避免这种情况，TCC会设置Try阶段的超时时间，如果Try阶段执行时间超过超时时间，TCC会自动执行Cancel操作，释放预留的资源，并将事务状态设置为“CANCELLED”，从而避免悬挂问题的发生。在实际应用中，需要根据业务场景合理设置Try阶段的超时时间，以充分利用资源、提高系统性能，并避免悬挂问题的发生。

2、增加分支事务记录表，查看有没有执行cancle，如果执行了就不执行try。

## 八、TCC 在 cancel 阶段如果出现失败怎么处理？ ##

在TCC的Cancel阶段，如果执行失败，需要进行补偿操作，以保证分布式事务的一致性。具体补偿操作的实现方式取决于具体的业务场景，可以根据以下几种方式进行补偿：

1.  重试：可以尝试重新执行Cancel操作，直到操作成功为止。
2.  补偿：可以通过执行补偿操作来补偿Cancel操作的失败，从而保证数据的一致性。
3.  人工介入：如果补偿操作无法自动完成，可以通过人工介入来解决问题，例如手动修改数据、调整系统配置等。

需要注意的是，在Cancel阶段出现失败时，需要记录失败信息，并及时通知相关人员进行处理，以避免数据不一致或系统异常等问题的出现。同时，也需要对补偿操作进行测试和验证，以确保其正确性和可靠性。

[Java_Java]: https://blog.csdn.net/qq_37967783/article/details/130940512