微盟WOS交易中台分布式事务的架构实战

原创陈东文微盟技术中心

一、前言

在分布式系统架构下，分布式事务是一个不可忽视的话题。目前市面上有很多成熟的分布式事务解决方案，如何将这些解决方案应用于具体的应用场景就涉及到了分布式事务的实战问题。本文主要介绍了微盟WOS交易中台下的分布式事务架构实战。

二、背景

微盟 WOS 体系下的交易中台承担了微盟多条业务线的下单流程，该流程涉及到多种资源的提交（通常称为“提交”，包括映射业务上的资源扣减、冻结等），以及回滚（通常称为“回滚”，包括映射业务上资源解冻、释放、回补等）。例如，当买家使用一张满减券和10积分购买一件商品时，在买家点击提交订单之后，生成订单之前，交易中台需要冻结一张满减券、10积分以及该商品的库存。由于这些资源的维护分散在不同的服务中，并且这些服务可能分布在不同的机器上，如何确保这些资源的提交和回滚能够要么全部成功，要么全部失败（实现最终一致性）是交易下单流程中的分布式事务问题。

微盟WOS体系的交易下单流程具有以下几个特点：

•长事务：交易协调了多种资源（如库存、限购、券码、礼品卡、积分、余额等多达十几种资源），在一次下单行为中完成。

•长链路：从交易发起资源的提交到对应服务完成资源的提交并不是点对点的直接调用，中间可能涉及多个服务。

•产品融合体系：通过OpenAPI、开放消息、SPI和iPaaS平台实现不同产品的融合。

三、技术方案

技术方案的选择经过多次考量，主要受以下几个因素影响：

1.方案设计初期明确了“最终一致性”是主要目标，即要解决的问题是“保证下单流程涉及的资源要么全部提交成功，要么全部失败”。

2.下单流程对性能要求较高，因此不采用性能较低的2PC和3PC等方案。

3.下单流程涉及的资源不完全存储在微盟内部的数据库，不采用以数据库为核心的方案（例如seata的AT和XA模式）。

4.产品融合体系意味着资源的持有方可能不是微盟内部的系统，资源的提交和回滚只能通过调用接口来实现，以消息为核心的方案不易落地。

5.接口调用超时问题：超时情况下，资源最终状态对交易来说是未知的，但反查每种资源的状态会增加交易的压力。

6.集成的外部系统提供的接口不一定能解决悬挂、空回滚、幂等、部分成功部分失败等问题。

7.长链路意味着最终负责处理资源提交请求的服务无法保证能将资源的最终状态正确地透传给交易。

基于上述因素，形成了微盟 WOS 体系下的交易中台分布式事务解决方案，如下图所示：

四、核心组件和概念介绍

全局事务管理器

负责协调十几种资源的提交、持久化和删除对应的事务记录，并抛出回滚事件以触发回滚。由交易中台承担全局事务管理器的责任。

回滚事件监听器

监听回滚事件，执行分支事务的回滚。由于下单流程触发的回滚和阶梯定时任务触发的回滚流程上是一致的，引入事件机制保证同一套回滚代码可被不同的场景复用。

阶梯定时任务

由任务调度中心触发，执行时间呈阶梯式的定时任务（1min、10min、30min、1h、6h、12h、24h），定时捞取回滚失败的事务记录进行重试。阶梯式的设计能够保证事务参与者故障恢复后能够自动回滚掉已提交的资源。

分布式锁

在分布式环境下，同一条事务记录可能会被集群中的多个服务节点捞取，为避免并发问题，引入分布式锁来确保只有一个节点可以处理该事务记录。

主事务

用户的一次提交订单行为涉及的所有资源提交和回滚称为主事务。

分支事务

一次下单行为涉及的每一种资源的提交流程称为分支事务，如库存的冻结、优惠券的锁定、限购的扣减等。

事务参与者

分支事务对应的资源提供方即事务参与者。

普通资源

交易发起提交请求，到事务参与者处理提交请求是点到点的接口调用。提交只在接口调用超时的情况下才进行回滚和回滚重试，因为超时的情况下上游的全局事务管理器无法确定资源的最终状态（成功或失败）。

特殊资源

与普通资源相反，从发起提交请求到处理提交请求并不是直接点到点的接口调用，中间间隔了其他服务。特殊资源在微盟的产品融合体系下，事务参与者是未知的，例如负责处理冻结积分请求的 CRM 系统可能不是微盟内部的 CRM 系统，可能是通过 iPaaS 集成进来的商家自研的 CRM 系统或 ISV 的 CRM 系统。全局事务管理器没有收到明确表示资源冻结成功的返回结果，都会进行回滚以及回滚重试。

核心资源

即订单，订单作为聚合其他子域的聚合根，在整条下单流程中处于核心地位，在这套分布式事务架构设计里，订单的创建是在所有资源提交成功之后再进行的。

事务记录

一条主事务和关联的分支事务的上下文组成一条事务记录，以订单号作为主键。类似 MySQL的undo log，作为下单失败后的资源回滚，以及回滚失败后的重试的依据。事务记录包含了目标资源的接口名，回滚接口的请求参数，下次回滚时间，回滚次数，事务状态等信息。

主事务执行流程

1.买家提交订单，全局事务管理器开始工作，提前生成此次下单关联的所有资源的回滚请求参数（事务记录），并持久化到DB，这里生成的事务记录设置下次执行时间为1H后，防止交易服务突发不可用导致流程中断，资源被无效的冻结但是订单又没有生成，后续服务恢复正常后也可由阶梯定时任务自动将错误冻结的资源回滚掉，同时设置1H也可以防止该事务记录生成后立刻就被拉定时任务捞取到然后回滚。

2.并行执行分支事务的提交。

3.判断所有分支事务是否提交成功，若是则发起创建订单请求，否则将状态为“提交完成”的分支事务和当前的主事务一起包装成一笔回滚事件，由回滚事件监听器异步执行资源的回滚。

4.发起创建订单请求，创建成功则删除第一步生成的事务记录，创建失败将所有分支事务和当前的主事务一起包装成一笔回滚事件，同样由回滚事件监听器执行资源回滚。

全局事务管理器正向提交流程伪代码如下：

全局事务管理器逆向回滚流程伪代码如下：

分支事务提交流程

1.将分支事务标记为“开始提交”。

2.调用事务参与者提供的资源提交接口。

3.根据接口的返回结果，将分支事务标记成不同的状态。接口返回提交成功或者捕捉到超时异常则将分支事务标记成“提交完成”（这里跟主事务执行流程的步骤三发生联动），否则标记成提交失败，状态为“开始提交”和“提交失败”的分支事务不会被回滚

分支事务的正向提交流程伪代码如下：

回滚事件监听器回滚流程

1.接收到回滚事件，开始执行分支事务的回滚。

2.根据事务记录关联的订单号查询订单，判断订单是否已生成。这一步的目的是因为在主事务执行流程的步骤四中，创建订单可能会超时，超时情况下，订单是否创建成功是未知的。如果订单已生成，则说明分支事务无需回滚。

3.如果订单未生成，则逐一执行每个分支事务的回滚。如果回滚成功，则删除相应的分支事务记录；否则继续回滚下一个分支事务。

4.判断是否还存在未回滚成功的分支事务，如果存在，则更新事务记录状态为“待重试”，同时设置下次执行时间；否则更新事务记录状态为“回滚成功”，并清空下次执行时间。

阶梯定时任务执行流程

1.获取分布式锁，获取失败表示其他服务节点正在执行重试任务，当前轮定时任务可跳过。

2.获取成功后，分批拉取下次执行时间大于或等于当前时间的事务记录。每一轮定时任务触发时，只需处理符合条件的事务记录。之后，任务调度中心随机调度一个服务节点执行下一轮定时任务。

3.拉取到的事务记录被包装成回滚事件，并行抛出。

4.释放分布式锁。

超时问题

不管是资源的提交还是回滚，接口调用超时都是不可避免的。超时意味着资源的最终状态对全局事务管理器来说是未知的，未知情况应被视为失败处理，提交超时需要回滚，回滚超时需要重试。

幂等问题

幂等性问题涉及两个方面：一是事务参与者内部对资源处理操作（如扣减、冻结）是否幂等，二是对外暴露的接口是否幂等（多次调用返回结果是否一致）。前者必须保证，而后者如果能保证幂等，对全局事务管理器来说会更加友好。

空回滚问题

前文提到，超时情况下一律视为失败处理，因此容易出现空回滚问题。空回滚指的是资源未提交就发生回滚，在提交接口超时情况下，资源的最终状态是未提交。这类问题难以避免，但从全局事务管理器的视角来看，无需重试空回滚，因为无效的重试对任何一方都是资源浪费。因此，资源提供方在涉及回滚接口时最好与上游全局事务管理器约定不需要重试的返回码。

悬挂问题

在发生空回滚后，资源提供方开始处理资源提交请求，理论上不应提交成功。为防止这类问题，资源提供方一般在处理提交请求前检查资源状态（是否可提交）。不论是提交还是回滚，资源提供方最好记录每笔资源的操作历史。

性能优化

为保证下单流程的高性能，整套方案进行了一些性能优化：

1. 分支事务并行提交

充分发挥多核机器的优势，实现资源的并行提交。

2. 异常流程异步

异常情况下异步执行补偿操作，提高用户体验和下单接口性能。

3. 定时任务扫描单个分片的事务记录

在分库分表场景下，每轮定时任务只需扫描单个分片的记录，避免全分片扫描。

4. 分支事务并行回滚

资源的提交和回滚属于典型的生产者消费者模型，全局事务管理器生产数据，回滚事件监听器消费数据。回滚事件监听器执行资源回滚时也可以并行处理，提高回滚效率。