Rabbitmq分布式事务

  • Post author:
  • Post category:其他


今天小编带来的是分享课题是分布式事务。小编是在一家O2O公司做程序员,今天就以公司的一则订单业务来作为分享课题的场景。

业务场景:用户在APP上进行下单操作,商家接单,配送,订单结束。这里以商家接单为背景。

业务结构如下:

架构实现:

一、本地事务

一个service里面通过单数据源保证三个表的事务,完全没有问题。完美解决。

二、分布式事务

一段时间之后,公司规模扩大,一个DB已经支持不住压力了,我司规划多DB模式,结构如下:

在多DB的模式下,发现之前的单数据源事务已经无法满足当前多DB的模式了。为什么呢?因为用户订单表可能在DB1里面,而商户订单表可能在DB2里面,而骑手配送表在DB3里面。这样,就要引入分布式事务处理机制了。

关于分布式事务,我做了如下几个的调查分析:

a. 2PC

如下是小编画的草图。2PC事务是由2个参与角色来参与的。事务协调器、DB参与者。TC首先会给所有的DB发送prepare指令,收集所有TC的返回。如果返回都是yes,则会通知有所的DB执行commit指令,否则就执行rollback。

在这里小编任务,这个事务不符合小编的场景,因为TC需要等待所有的DB返回,如果存在跨库的话,那在这里会把资源锁住太长时间,同时延长接口响应时间,如果在高并发场景下,更加不够友好。

b. TCC

如下是小编画的草图。TCC是基于2PC做的一次提升,它分为三个阶段:try、confirm、cancle。

架构图:

业务场景图:

try:在该阶段,主要是做资源预留操作。比如我要通过美团买A站去C站的机票,但是没有直达,只能在B站做中转。那我在用美团买机票的时候,美团必须同时给我买2张票,我才能接受。不然,美团告诉我,只买到了从A到B站的票,但是B到C站的票没买到,那我肯定不希望这样,毕竟我来退票的话,是需要付手续费的。说了这么多就是想表达,航空公司需要给美团提供机票预留服务。

confirm:只有try阶段成功了,该阶段才会有效,也就是在try阶段美团帮我预留了2张机票,否则进入cancle阶段。但是可能因为网络波动,在给2张机票付款时,有一张机票付款超时来,这个时候美团应该帮我重试付款,直到付款成功为止,所以这里涉及到一个服务幂等性支持。

cancle:该阶段就是回滚操作,但是需要小编手动编写回滚业务。针对try阶段的预留操作。

小编综合考虑之后觉得,如果使用TCC,就要针对性的给TCC的每个阶段都开发一个接口服务,这是其一,其二还是存在同时锁住多资源,未能提高接口响应问题。

c.  RabbitMQ实现分布式事务

如下是小编画的草图。在商家接单成功之后,仅仅更新商家订单表,然后把该消息存入MQ,存入成功之后就及时通过商家接单成功。后续的用户订单表、骑手配送表通过异步的形式来保证最终一致性。前提:不要在代码里面写一些业务异常。

因为Rabbitmq本身支持事务操作,所以能够有效的保证用户订单表和奇松配送表的事务,并且小编这里的业务逻辑是可以接受一定程度的数据延迟同步。基于此模式,APP在多DB的场景下,也能很完美的保证公司业务的正常展开。如下是优化后的效果图,在经过限流、负载均衡操作之后,仍然支撑了9K的QPS压力:

修改如下:

至此,小编选择了RabbitMQ来优化订单业务,效果很完美。升职加薪,迎娶白富美,不再是梦。



版权声明:本文为qq_18991441原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。