分布式事务 TCC
tip：作为程序员一定学习编程之道，一定要对代码的编写有追求，不能实现就完事了。我们应该让自己写的代码更加优雅，即使这会费时费力。
推荐：体系化学习Java（Java面试专题）
文章目录
- 一、简介
- 二、运行流程
- 三、优缺点
- 四、TCC 和 2PC 相比
- 五、TCC 和 3PC 相比
- 六、TCC 如何解决幂等问题？
- 七、TCC 如何解决悬挂问题？
- 八、TCC 在 cancel 阶段如果出现失败怎么处理？
一、简介
TCC（Try-Confirm-Cancel）是一种分布式事务解决方案，也是一种补偿式的分布式事务。它通过在业务逻辑中嵌入Try-Confirm-Cancel三个阶段的逻辑，来保证分布式事务的一致性和可靠性。TCC协议的核心思想是“补偿机制”，即在分布式事务出现异常或失败时，通过执行相反的操作来补偿之前的操作，从而达到事务的一致性。
二、运行流程
TCC协议的三个阶段分别为：
-
Try 阶段：在这个阶段，业务逻辑会预留资源，并检查所有的前提条件是否满足。如果检查通过，则执行业务逻辑，否则回滚预留的资源。
-
Confirm 阶段：在这个阶段，业务逻辑会确认执行结果，如果确认通过，则提交所有的操作，否则回滚所有的操作。
-
Cancel 阶段：在这个阶段，业务逻辑会撤销之前执行的操作，并释放之前预留的资源。
三、优缺点
TCC协议相比于2PC和3PC协议，具有以下优点：
-
可以在业务逻辑中自定义补偿操作：TCC协议允许在业务逻辑中自定义补偿操作，可以根据具体业务场景进行灵活配置，从而提高了协议的适用性和灵活性。
-
支持分布式事务：TCC协议可以支持分布式事务，可以在跨多个服务之间保证事务的一致性和可靠性。
-
可以减少阻塞时间：TCC协议中的Try阶段可以预留资源，从而减少了阻塞时间，提高了系统的性能。
需要注意的是，TCC协议虽然具有很多优点，但也存在一些问题，例如需要在业务逻辑中嵌入Try-Confirm-Cancel三个阶段的逻辑，实现起来可能会比较复杂；同时，TCC协议也需要考虑幂等性等问题。因此，在实际应用中，需要根据具体情况选择合适的分布式事务解决方案。
四、TCC 和 2PC 相比
TCC和2PC都是分布式事务解决方案，它们在保证分布式事务一致性和可靠性方面有一些相似之处，但也存在一些不同点。
相同点：
-
都是为了保证分布式事务的一致性和可靠性而设计的；
-
都需要在多个参与者之间进行协调和通信，以确保事务的正确执行；
-
都需要考虑事务的超时、异常处理等问题。
不同点：
-
TCC协议可以在业务逻辑中自定义补偿操作，而2PC协议的补偿操作相对固定；
-
TCC协议的Try阶段可以预留资源，从而减少阻塞时间，提高系统性能，而2PC协议需要等待所有参与者的响应，可能会导致阻塞；
-
TCC协议相对于2PC协议更加灵活，可以根据具体业务场景进行定制，但实现起来可能会比较复杂。
总之，TCC和2PC协议都是分布式事务解决方案，需要根据具体业务场景选择合适的解决方案。如果业务逻辑比较复杂，需要灵活定制补偿操作，可以选择TCC协议；如果业务逻辑比较简单，可以选择2PC协议。
五、TCC 和 3PC 相比
TCC和3PC都是分布式事务解决方案，它们在保证分布式事务一致性和可靠性方面有一些相似之处，但也存在一些不同点。
相同点：
-
都是为了保证分布式事务的一致性和可靠性而设计的；
-
都需要在多个参与者之间进行协调和通信，以确保事务的正确执行；
-
都需要考虑事务的超时、异常处理等问题。
不同点：
-
TCC协议可以在业务逻辑中自定义补偿操作，而3PC协议的补偿操作相对固定；
-
TCC协议相对于3PC协议更加灵活，可以根据具体业务场景进行定制，但实现起来可能会比较复杂；
-
3PC协议相对于TCC协议更加稳定，可以在网络不稳定或参与者宕机的情况下保证事务的正确执行；
-
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阶段，如果执行失败，需要进行补偿操作，以保证分布式事务的一致性。具体补偿操作的实现方式取决于具体的业务场景，可以根据以下几种方式进行补偿：
-
重试：可以尝试重新执行Cancel操作，直到操作成功为止。
-
补偿：可以通过执行补偿操作来补偿Cancel操作的失败，从而保证数据的一致性。
-
人工介入：如果补偿操作无法自动完成，可以通过人工介入来解决问题，例如手动修改数据、调整系统配置等。
需要注意的是，在Cancel阶段出现失败时，需要记录失败信息，并及时通知相关人员进行处理，以避免数据不一致或系统异常等问题的出现。同时，也需要对补偿操作进行测试和验证，以确保其正确性和可靠性。