TCC简介

TCC

TCC（Try-Confirm/Cancel）是一种分布式事务处理模型，旨在解决分布式系统中的事务一致性问题。

三阶段

1. Try阶段： 在这个阶段，业务参与者尝试执行事务，并执行相应的业务逻辑。该阶段用于检查事务执行的先决条件，确保所有需要的资源都可用，并预留这些资源。如果在Try阶段发生任何故障，系统将尝试执行Cancel阶段。
2. Confirm阶段： 如果Try阶段成功完成，系统将执行Confirm阶段。在这个阶段，所有的业务参与者确认事务的执行，将先前预留的资源正式应用到系统中，使事务生效。
3. Cancel阶段： 如果在Try阶段发生故障，或者业务逻辑判定需要取消事务，系统将执行Cancel阶段。在这个阶段，事务参与者会释放之前预留的资源，回滚事务的执行，确保系统的一致性。

和2PC区别

执行方式：

• TCC： TCC是一种乐观并发控制协议。它试图执行一个事务，然后确认执行，最后取消执行。这三个阶段分别是Try、Confirm、和Cancel。
• 2PC： 2PC是一种悲观并发控制协议。它分为两个阶段：准备阶段和提交阶段。在准备阶段，协调者询问所有参与者是否可以提交，然后在提交阶段进行实际的提交。

原子性：

• TCC： TCC协议的每个阶段都是业务逻辑的一部分，因此能够提供更细粒度的控制，使得业务逻辑更容易实现原子性。
• 2PC： 2PC是一个强一致性的协议，要么所有的事务参与者都提交，要么都回滚，以保持全局一致性。

实现难度：

• TCC： TCC对业务逻辑的要求较高，因为业务逻辑需要被拆分成Try、Confirm和Cancel三个阶段。
• 2PC： 2PC的实现相对来说更直观，但由于其强一致性的特性，可能会在分布式环境中引入一些性能和可扩展性方面的挑战。

cancel失败了怎么办？

重试： 在Cancel阶段失败后，可以尝试重新执行Cancel操作。这可能是因为在第一次执行时发生了一些临时问题，例如网络故障或者参与者的不可用。重试的次数和频率可以根据具体情况进行调整。

补偿操作： 如果Cancel无法成功执行，系统可能需要引入补偿操作，以确保数据的一致性。补偿操作是一种对已执行的操作进行反向操作的手段，从而将系统恢复到一致的状态。

人工介入： 在某些情况下，可能需要人工介入来解决问题。例如，如果Cancel无法成功执行，系统可能需要通知管理员或相关人员，以便他们能够手动处理问题。

日志和监控： 对于Cancel阶段的失败，系统应该有适当的日志记录和监控机制。这样，即使Cancel失败，系统管理员也能够通过日志了解失败的原因，并且监控系统可以及时发现问题。

TCC存在问题

空回滚

在没有调用TCC资源Try方法得情况下，调用了二阶段得Cancel方法，Cancel方法需要识别出这是一个空回滚，然后直接返回成功。

事务悬挂

悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。

解决办法

解决办法就是引入分布式事务记录表，记录事务的状态。

例如：

try ：0；confirm：1；cancel：2

空回滚解决

应对空回滚的时候，在cancel时，去数据库查询下是否执行了try，有try，则进行一次回滚；没有try，则不做操作或者直接返回成功（空回滚）。并且记录状态为2。

事务悬挂解决

由于cancel操作之后，记录了状态cancel，在try的时候判断一下状态是否为cancel，是cancel则拒绝本次try操作，否则执行try操作。