订单最终一致性解决方案

背景

整体的交易架构主要由两部分组成：C端交易平台 - B端交易平台

由于组织架构的特殊性，并没有采用两阶段提交、三阶段提交这种刚性分布式事务的方案。

主要采用了基于TCC思想的TOC柔性事务补偿方案。

柔性事务：遵循BASE原则，最终一致性 ，允许在一定时间内，不同节点数据不一致。

TOC

TOC：Time out control（超时控制中心）

TOC有三大功能：注册超时任务、取消超时任务、超时任务回调

节点A驱动节点B，节点A完成之后，注册一个超时任务，如果如期到达节点B，则取消超时任务，否则TOC会回调该超时任务。

举个例子：
创单完成之后，会注册支付超时任务，随后会驱动系统进行支付，如果创单之后，因为种种原因（用户一直未支付或系统故障），没有执行支付功能，则TOC回调支付超时任务，系统进行关单处理。

任务

具体的超时任务要根据各个交易环节制定。

1. 创单超时任务（预下单 - 创单）
2. 支付超时任务（创单 - 支付）
3. 预定资源超时任务（支付 - 预定资源）
4. 确定资源超时任务（预定资源 - 确定资源）
5. 服务完成超时任务（确定资源 - 服务完成）

其中服务完成超时任务，可以用分布式调度器做定时扫表处理。

1. 订单推到终态的时间节点很难把控，如果根据服务到期时间去把控这个超时任务，会导致任务量级特别庞大。
2. 基于业务，系统商大部分都有核销回调的能力，订单未处于终态的订单不会特别多，用定时任务去处理，非常合适。

场景

1. 柔性事务补偿方案
2. MQ消息丢失补偿方案