TCC方案 详解

简介

TCC是 try预处理 confirm确认 cancel撤销三个操作。
try 预处理：业务检查及资源预留
confirm确认： 业务确认
cancel 撤销：实现与try相反的回滚操作。

首先发起try操作，任何一个分支事务try操作失败，都要全体分支事务cancel.
若全部成功，则对全体confirm。

三个阶段
一个管理器：TM事务管理器，可以实现为独立服务，或者让全局事务的发起者充当TM，目的是为了成为公用组件，以复用功能。
TM发起全局事务时生成全局事务记录，每条记录有全局事务ID，用来记录事务上下文，追踪和记录状态。由于confirm和cancel需要重试，因此需要幂等性。

1. try做业务检查（主要检查一致性）以及资源预留（隔离性）。
2. confirm做确认提交，通常认为，confirm不会出错，即只要try成功，confirm必定成功
3. cancel阶段在业务执行错误，需要回滚状态下执行对分支事务的业务取消，同时取消预留的资源，通常情况下，也一定成功。

异常处理

空回滚

即没有先调用try方法，却直接调用了cancel方法，cancel需要识别出这是一个空的回滚，直接返回成功。
原因：
当一个分支事务所在的服务器宕机或网络异常，分支事务调用记录为失败，这时其实没有try，但是故障恢复后，发现失败，进行回滚从而调用了cancel。

解决
关键是得识别出try是否执行了，用一张分支事务记录表，记录全局事务ID以及分支事务ID，每次try完成就往里插入一条记录，以表示try执行了，这时cancel方法只需要调用这个接口看记录表中是否有该记录，有说明执行了，正常回滚，没有则没有try，直接空回滚。

幂等

为了保证TCC二阶段提交重试机制不会引发数据不一致，要求TCC的二阶段Try、Confirm和Cancel接口保证幂等，这样不会重复使用或者放资源。如果幂等控制没有做好，很有可能导致数据不一致等严重问题。
解决
在上述 “分支事务记录表”中增加执行状态，每次执行前都查询该状态。

悬挂

悬挂就是对于一个分布式事务，其二阶段Cancel接口比Try接口先执行。
原因：
RPC调用分支事务try时，先注册这个分支事务，再执行RPC调用，此时如果网络拥堵，会导致RPC调用超时。
超时之后，TM就要通知回滚这个分布式事务，有可能回滚都结束了，RPC请求才刚到需要执行的地方，而try到了之后需要预留资源，只有刚才被回滚的那个事务才能用，那么这个预留的资源就没有人能够处理了。主要导致try操作预留的资源，因为事务已经被回滚，无法继续处理。

解决
如果某个事务二阶段的cancel执行完成，则一阶段try不允许执行。在“分支事务记录表”中查，如果有二阶段cancel记录，则不执行try。

TCC特点

1. 不与特定的服务框架耦合：需要常用的微服务框架，但是TCC框架本身不应该与特定框架绑定。即不论基于TCP/HTTP协议，公有协议还是私有协议。
2. 支持多种事务日志持久化机制：事务日志持久化的性能是影响TCC性能的一个很重要因素，因此支持多种持久化机制便于根据特定应用场景进行灵活选择
3. 支持可配置recovery策略：对于异常的事务（比如Confirm失败），TCC框架应该提供recovery机制，它会对事务日志进行扫描监控，并根据策略进行recovery操作。策略必须是可以配置的（基于xml或者注解），配置项可以有：最大重试次数、recovery时间间隔、支持Cron表达式等。

TCC与2PC（两阶段提交）区别

1. TCC位于业务服务层，并非2pc在数据库的资源层。
2. 2pc没有单独的准备阶段，而try兼顾资源操作与准备两方面。
3. TCC的try操作可以以业务确定粒度，即灵活选择资源的锁定粒度。
4. 2PC开发成本高。