从双11业务看分布式事务

原创
04/04 20:57
阅读数 16

在双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的角度去考虑的问题。


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




本文分享自微信公众号 - 大魏分享(david-share)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部