从双11业务看分布式事务满足Saga和异步场景的示例分析

这篇文章给大家介绍从双11业务看分布式事务满足Saga和异步场景的示例分析，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

在双11的时候，很多电商都在搞促销，包括京东。

我们以大魏的书举例，例如双11的时候，买书除了打折好有红包，这样，买书的时候双重优惠，如下图所示：

那么，在双11的场景中，买书的一次请求，就包括同步和异步的场景，如下图所示。

同步场景采用Saga、异步场景采取事务消息（Sagas+本地事务消息表）。也就是说，分布式事务的设计要能同时满足同步和异步两种场景：

那么，我们看一次成功的双11购物请求。

下图的1、2、3、4是的是步骤，分别调用上图的A、B、C、D应用模块。

在上图中，我们从App发起请求，请求被分配到任意一个网关层，再被分配到任意一个业余逻辑层。

1.业务逻辑层会先调用商品数据源访问层进行减库存（访问DB)

2.第1步成功后，业务逻辑层访问订单数据访问层，进行创建订单本地事务(访问

DB)，在下订单的同时，业务逻辑层会向MQ发送延迟订单支付消息，即事务消息。

3.第2步执行成功后，业务逻辑层调用红包数据访问层，进行减红包操

(访问DB）。成功后，红包数据访问会返回成功信息给交易逻辑层、交易逻辑层返回成功信息给网网关层、网关层返回信息给App。

4.App页面自动跳转到支付页面，即业务逻辑层调用支付数据访问层，进行前台支付。

然后，整个操作完成。

那么，MQ中的订单支付消息呢？当延迟支付消息到了超时时间后（京东是24小时），MQ的订单延迟支付消息会被发到到业务逻辑层（因为业务逻辑层订阅了MQ的Topic），然后业务逻辑层根据事务组表，判断订单有没有支付，如果支付了，则直接删除延迟消息。如果订单未支付，则将事务组表中的state由1改成3（失败）：

然后TM根据事务调用表，TM触发事务补偿：将红包加回去、订单+1、删除订单。

最后，Proxy将事务组表中的state由1改成4（补偿成功）

那么，我们审视一下上图的架构，在超高请求到来时，可能的瓶颈点在哪？

从技术架构来看，网关、交易业务逻辑层、数据访问层都是无状态的，可以横向扩展，不存在瓶颈。对于DB而言，可以做数据分表。对于MQ而言，可以做分片。看起来也不存在性能瓶颈。

那么，为什么双11的时候，在京东购物，还会发生购物失败的情况呢？

原因是存在热点数据，也就是特别抢手的货物，例如：

如果要解决热点数据问题，就需要做热点数据预测。要做热点数据预测，要先做异步化。也就是说，对于热点紧俏商品的购买请求，直接先发到MQ中。然后再依次执行业务逻辑。

在这时，热点就会被压在MQ上。这时候，我们就需要对MQ做分片，但对于一个商品的一条记录，我们如何对它做分片呢？可以加一列Type，把数据一行变多行：

然后我们可以把每一行记录存在一个MQ的Topic中，就能消除热点数据。

既然技术上热点数据能够消除，为啥双11京东购物还有失败呢？因为采购服务器是要花钱的，双11电商会保证交易成功率，但这个成功率不会是100%，这是从ROI的角度去考虑的问题。

总结：在设计业务架构时，考虑到超高并发流量请求，我们需要注重架构如下三个方面：

关于从双11业务看分布式事务满足Saga和异步场景的示例分析就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。