蘑菇街交易创建过程中的分布式一致性方案

**

蘑菇街交易创建过程中的分布式一致性方案

**

交易创建的一般性流程
我们把交易创建流程抽象出一系列可扩展的功能点，每个功能点都可以有多个实现(具体的实 现之间有组合/互斥关系)。把各个功能点按照一定流程串起来，就完成了交易创建的过程。

面临的问题
每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了，不能确定到底有没有锁券成功，该如何处理?再比如锁券成功了，但是扣减库存失败了，该如何处理?

方案选型
1. 服务依赖过多，会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10个服务，9个都执行成功了，最后一个执行失败了，那么是不是前面9个都要回滚掉? 这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下，对于非实 时、非强一致性的关联业务写入，在本地事务执行成功后，我们选择发消息通知、关联 事务异步化执行的方案。
2. 消息通知往往不能保证100%成功;且消息通知后，接收方业务是否能执行成功还是未 知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。但是事务消息框架 本身会给业务代码带来侵入性和复杂性，所以我们选择基于DB事件变化通知到MQ的方 式做系统间解耦，通过订阅方消费MQ消息时的ACK机制，保证消息一定消费成功，达 到最终一致性。由于消息可能会被重发，消息订阅方业务逻辑处理要做好幂等保证。
3. 所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中， 锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致，乍一看，必须要 引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来 复杂性的急剧上升;在电商领域，绝对的强一致是过于理想化的，我们可以选择准实时 的最终一致性。我们在交易创建流程中，首先创建一个不可见订单，然后在同步调用锁 券和扣减库存时，针对调用异常(失败或者超时)，发出废单消息到MQ。如果消息发 送失败，本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后，会进行 判断是否需要做业务回滚，这样就准实时地保证了多个本地事务的最终一致性。

流程概述