柔性事务解决方案: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地址
流程图
- 如果try阶段异常则进入cancel阶段
- 如果try阶段成功则进入confirm阶段,且进入confirm阶段的事务只会向前推进。不会cancel。如果confirm失败则走恢复事务的流程。达到最大重试次数后则需要人工干预。