TCC

TCC

两阶段提交协议和三阶段提交协议，用它们解决分布式事务的问题，但是遇到极端情况时，系统会产生 阻塞或者不一致的问题，需要运营或者技术人员解决。两阶段及三阶段 方案中都包含多个参与者、多个阶段实现一个事务，实现复杂，性能也 是一个很大的问题，因此，在互联网的高并发系统中，鲜有使用两阶段 提交和三阶段提交协议的场景。

后来有人提出了TCC协议，TCC协议将一个任务拆分成Try、 Confirm、Cancel三个步骤，正常的流程会先执行Try，如果执行没有问 题，则再执行Confirm，如果执行过程中出了问题，则执行操作的逆操 作Cancel。从正常的流程上讲，这仍然是一个两阶段提交协议，但是在 执行出现问题时有一定的自我修复能力，如果任何参与者出现了问题， 则协调者通过执行操作的逆操作来Cancel之前的操作，达到最终的一致 状态。

可以看出，从时序上来说，如果遇到极端情况，则TCC会有很多问 题，例如，如果在取消时一些参与者收到指令，而另一些参与者没有收 到指令，则整个系统仍然是不一致的。对于这种复杂的情况，系统首先 会通过补偿的方式尝试自动修复，如果系统无法修复，则必须由人工参 与解决。 从TCC的逻辑上看，可以说TCC是简化版的三阶段提交协议，解决 了两阶段提交协议的阻塞问题，但是没有解决极端情况下会出现不一致 和脑裂的问题。然而，TCC通过自动化补偿手段，将需要人工处理的不 一致情况降到最少，也是一种非常有用的解决方案。某著名的互联网公司在内部的一些中间件上实现了TCC模式。

我们给出一个使用TCC的实际案例，在秒杀的场景中，用户发起下 订单请求，应用层先查询库存，确认商品库存还有余量，则锁定库存， 此时订单状态为待支付，然后指引用户去支付，由于某种原因用户支付 失败或者支付超时，则系统会自动将锁定的库存解锁以供其他用户秒 杀。