分布式事务11_TCC 两阶段型、补偿型

柔性事务解决方案：TCC（两阶段型、补偿型）

更多干货

• 分布式事务处理一
• 分布式事务二
• 分布式事务处理三
• 分布式事务四_基于可靠消息的最终一致性
• 分布式事务五_基于可靠消息的最终一致性_异常流程
• 分布式事务六_常规MQ队列
• 分布式事务七_幂等性设计
• 分布式事务八_可靠消息最终一致性方案
• 分布式事务九_基于可靠消息的最终一致性代码
• 分布式事务10_最大努力通知形势
• 柔性事务解决方案：TCC（两阶段型、补偿型）
• 支付宝 分布式事务服务 DTS 一
• 分布式事务服务 DTS二
• 分布式事务服务 DTS三
• 支付宝 分布式事务服务 DTS四

实现

• 一个完整的业务活动由一个主业务服务与若干从业务服务组成
• 主业务服务负责发起并完成整个业务活动
• 从业务服务提供TCC型业务操作
• 业务活动管理器控制业务活动的一致性，它登记业务活动中的操作， 并在业务活动提交时确认所有的TCC型操作的confirm操作，在业务活动取消时调用所有TCC型操作的cancel操作

成本

• 实现TCC操作的成本
• 业务活动结束时confirm或cancel操作的执行成本
• 业务活动日志成本

适用范围

• 强隔离性、严格一致性要求的业务活动
• 适用于执行时间较短的业务（比如处理账户、收费等业务）

用到的服务模式

• TCC操作、幂等操作、可补偿操作、可查询操作

方案特点

• 不与具体的服务框架耦合（在RPC架构中通用）
• 位于业务服务层，而非资源层
• 可以灵活选择业务资源的锁定粒度
• TCC里对每个服务资源操作的是本地事务，数据被lock的时间短，可扩展性好（可以说是为独立部署的SOA服务而设计的）

行业应用案例

• 支付宝XTS（蚂蚁金融云的分布式事务服务DTS）

Try: 尝试执行业务

• 完成所有业务检查(一致性)
• 预留必须业务资源(准隔离性)

Confirm:确认执行业务

• 真正执行业务
• 不作任何业务检查
• 只使用Try阶段预留的业务资源
• Confirm操作要满足幂等性

Cancel: 取消执行业务

• 释放Try阶段预留的业务资源
• Cancel操作要满足幂等性

与2PC协议比较

• 位于业务服务层而非资源层
• 没有单独的准备(Prepare)阶段，Try操作兼备资源操作与准备能力
• Try操作可以灵活选择业务资源的锁定粒度(以业务定粒度)
• 较高开发成本

误区：很多人把两阶段型操作等同于两阶段提交协议2PC操作。其实TCC操作也属于两阶段型操作。

可补偿操作

do: 真正执行业务

• 完成业务处理
• 业务执行结果外部可见

compensate:业务补偿

• 抵销(或部分抵销)正向业务操作的业务结果
• 补偿操作满足幂等性

约束

• 补偿在业务上可行
• 由于业务执行结果未隔离、或者补偿不完整带来的风险与成本可控

（TCC操作中的Confirm操作和Cancel操作，其实也可以看作是补偿操作）

TCC框架github地址

• https://github.com/changmingxie/tcc-transaction

流程图

• 如果try阶段异常则进入cancel阶段
• 如果try阶段成功则进入confirm阶段，且进入confirm阶段的事务只会向前推进。不会cancel。如果confirm失败则走恢复事务的流程。达到最大重试次数后则需要人工干预。