今天小编带来的是分享课题是分布式事务。小编是在一家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来优化订单业务，效果很完美。升职加薪，迎娶白富美，不再是梦。
