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失败，系统管理员也能够通过日志了解失败的原因，并且监控系统可以及时发现问题。