订单状态一致性维护的高鲁棒性实践——以接单系统为例

订单系统最难的就是一致性维护，关于状态机，同事有很好的总结，参见：https://www.jianshu.com/c/fcf...

接单系统做为订单系统的后路，对一致性要求更高

接单系统特色与要求

1. TPS高，要求高并发，存在峰值流量
2. 稳定性要求高，不能漏接单，须要有较高的容错性，接单系统依赖的任何服务短时挂掉都不该该影响接单，尤为是在电商系统中，到接单这一步，用户以前其实已经支付了，因此对稳定性有着异常严格的要求。

技术实现

1.对于高TPS要求，实现的套路是固定的。

消息中间件在工程实现中主要用来削峰，异步和解耦。接单接口的入口首先要用消息队列来削峰，以解决峰值高流量问题。

削峰以后收到要保证消息不堆积并支持高并发，还须要作分流，接单系统须要落日志并增删改查业务表数据，数据库性能就会成为瓶颈，数据库的分库分表就是必须的，

消息加数据库分库分表基本就能知足。

2.对于稳定性要求

须要考虑到各类异常状况。出现异常状况要有自恢复能力，状态机加延迟队列再加脚本可解决问题。

为何要有状态机呢，接单系统的业务逻辑通常都很复杂，在接单的过程当中可能因为各类缘由致使异常，这时候状态机的做用就凸显，

刚接到单，就须要数据落库，这是状态机的初始态。以后的业务逻辑流转过程当中的各类可能异常状况都须要被记录下来，这些是状态机的中间态，属于异常状况，

须要某种机制将中间态转化为最终态。技术要须要利用延迟队列，若是某个订单出现了异常，或者说出现了中间态，须要将这个异常订单扔到延迟队列中，待会重试，

绝大多数状况是依赖的某个微服务短期存在不可用或者不稳定，待它稳定后须要进行重试。重试若是还有问题就再重试。

可是重试也须要有次数限制，若是有问题，不可能一直在堆在q中，这时候补偿脚本的做用就显现了 ，脚本是最后的兜底，跟常规逻辑相比，脚本须要对业务稍微有损，是次优的，

在兜底脚本中可将部分接单过程当中不重要的接口或者功能降级掉，优先保证接单的稳定。这是跟以前的延迟队列的业务逻辑相比不一样的地方。