背景
整体的交易架构主要由两部分组成：C端交易平台 - B端交易平台
由于组织架构的特殊性，并没有采用两阶段提交、三阶段提交这种刚性分布式事务的方案。
主要采用了基于TCC思想的TOC柔性事务补偿方案。
柔性事务：遵循BASE原则，最终一致性 ，允许在一定时间内，不同节点数据不一致。
TOC
TOC：Time out control（超时控制中心）
TOC有三大功能：注册超时任务、取消超时任务、超时任务回调
节点A驱动节点B，节点A完成之后，注册一个超时任务，如果如期到达节点B，则取消超时任务，否则TOC会回调该超时任务。
举个例子：
创单完成之后，会注册支付超时任务，随后会驱动系统进行支付，如果创单之后，因为种种原因（用户一直未支付或系统故障），没有执行支付功能，则TOC回调支付超时任务，系统进行关单处理。
任务
具体的超时任务要根据各个交易环节制定。
- 创单超时任务（预下单 - 创单）
- 支付超时任务（创单 - 支付）
- 预定资源超时任务（支付 - 预定资源）
- 确定资源超时任务（预定资源 - 确定资源）
- 服务完成超时任务（确定资源 - 服务完成）
其中服务完成超时任务，可以用分布式调度器做定时扫表处理。
- 订单推到终态的时间节点很难把控，如果根据服务到期时间去把控这个超时任务，会导致任务量级特别庞大。
- 基于业务，系统商大部分都有核销回调的能力，订单未处于终态的订单不会特别多，用定时任务去处理，非常合适。
场景
- 柔性事务补偿方案
- MQ消息丢失补偿方案
