分布式事务的解决方法中，TCC是较为經典的方式，应用2环节递交的观念来完成分布式事务的最后一致。但近期我有点儿讨厌TCC方式了。
TCC回望
TCC究竟是什么呢?
以經典的电商系统而言，顾客选购一件产品，系统软件必须3个服务项目来合作进行。订单信息服务项目提升订单信息，库存量服务项目扣除库存量，帐户服务项目扣除额度。如下图：
如果我们用图中的方法，每一个服务项目分别递交事务管理，很有可能会发生数据信息不一致的状况。由于3个服务项目应用不一样数据库查询，并并不是一个原子操作，例如订单信息服务项目操作成功而帐户服务项目失败了，那样数据信息也不一致了。
TCC的观念是应用2环节递交，try环节最先试着每个服务项目预埋資源，假如预埋取得成功则进到commit环节递交事务管理，假如有一个服务项目预埋不成功，那么就进到cancel环节撤消事务管理。这必须添加一个融洽连接点来对3个服务项目下达指令而且获得每一个服务项目的支系事务管理实行結果。try环节用下面的图表明：
try环节假如每个服务项目预埋資源取得成功，融洽连接点便会对各服务项目下达commit指令，如下图：
全部服务项目commit取得成功后，全部事务管理进行。
编码完成
融洽连接点必须给每一个分布式事务出示一个全局性事务管理id，称为xid，用于跟每一个服务项目的当地事务管理关联。大家以帐户服务项目为例子，看来一下try/commit/cancel这3个环节的编码：
这一段编码应用了jdbc来解决当地事务管理，try环节大家获得了connection而且储存在connectionMap，key是xid，那样在commit/cancel环节，从connectionMap中取下connection来commit/rollback。
存在的问题
上边TCC方式的编码完成有什么问题吗?
服务项目群集
如下图，假如订单信息服务项目群集布署在3个设备上，try要求发送至订单信息服务项目1，而commit要求发至订单信息服务项目2上，订单信息服务项目2的connectionMap怎么可能有xid=123的这一值呢?订单信息服务项目当地事务管理不可以递交了。
因此假如真的用维持connection的方法来递交事务管理，融洽连接点就必须确保同一个xid相匹配的try/commit/cancel要求到同一个设备上。
解决方法毫无疑问有，更新改造认证中心，或是融洽连接点自身维护保养服务项目目录。前面一种让认证中心藕合了业务流程编码，后面一种等同于废料了认证中心。
空递交
认证中心和融洽连接点的更新改造都必须非常大的劳动量，是否有其他方式 呢?大家做一个改善，这儿orm框架应用mybatis，编码以下：
try环节要预埋資源，这一段编码假如预埋資源取得成功，实际上早已递交支系事务管理了，commit环节仅仅一个空递交，沒有具体功效了。
也有一种方法便是try环节立即回到true，到commit环节真实递交事务管理。
可是这二种方法都违反了TCC的观念。
幂等
假如融洽连接点设定了请求超时再试，发生了下面的图的状况，订单信息服务项目1实行完try方式 后产生常见故障，融洽连接点不能收到取得成功回应一定会开展再试，那样订单信息服务项目便会反复实行try方式 。
为了更好地避开这个问题，try/confirm/cancel方式 都务必添加幂等逻辑性，纪录全局性事务管理xid相匹配当地事务管理的实行情况。
空回退
应用架构来完成TCC方式时，会有一种空回退的状况。
如圖，由于订单信息服务项目1节点常见故障，try方式 不成功，可是全局性事务管理早已打开，架构务必要把这个全局性事务管理引向完毕情况，那样就迫不得已启用订单信息服务项目cancel方式 开展回退，結果订单信息服务项目空跑了一次cancel方式 。
处理这个问题，try环节必须纪录xid相匹配的支系事务管理实行情况，cancel环节依据这一纪录来开展分辨。
悬架
上边讲了seata的应用全过程中会产生空回退，假如发生了空回退，实行了cancel方式 后全局性事务管理告一段落，可是由于网络问题，订单信息服务项目又收到了try要求，实行try方式 后预埋資源取得成功，这种資源却不可以释放出来了。
处理这个问题的方式 便是在cancel方式 中纪录xid相匹配的支系事务管理实行情况，try环节实行的情况下先分辨支系事务管理是不是早已回退。
编码入侵高
TCC的try/commit/cancel，对业务流程编码都是有入侵，假如再考虑到幂等、空回退、悬架等，编码入侵会高些。
小结
TCC是分布式事务中十分經典的方式，但即便依靠架构完成，编码完成也非常复杂。
具体应用时必须考虑到服务项目群集、空递交、幂等、空回退、悬架等难题。
对业务流程编码入侵性很高。
