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

求贤若渴礼贤下士 2019-07-01

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

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

接单系统特点与要求

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

技术实现

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

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

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

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

2.对于稳定性要求

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

为什么要有状态机呢,接单系统的业务逻辑一般都很复杂,在接单的过程中可能由于各种原因导致异常,这时候状态机的作用就凸显,

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

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

绝大多数情况是依赖的某个微服务短时间存在不可用或者不稳定,待它稳定后需要进行重试。重试如果还有问题就再重试。

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

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

相关推荐

tuniumobile / 0评论 2018-12-26
陶赫Qt开发学习 / 0评论 2018-12-26