忘川彼岸|我只是下了个订单，鬼知道我在微服务里经历了什么？( 五 ) 【51CTO.com原创稿件】面试的时候

在分布式系统中，我们往往追求的是可用性，它的重要性比一致性要高，那么如何实现高可用，这里又有一个理论，就是 BASE 理论，它给 CAP 理论做了进一步的扩充。
BASE 理论
BASE 理论指出：

Basically Available(基本可用)
Soft state(软状态)
Eventually consistent(最终一致性)

BASE 理论是对 CAP 中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。
好了，说了一大顿理论，程序员们都等急了，赶快来看看分布式事务的解决方案有哪些，可以进行接下去的 Coding...
来吧，讨论技术方案：

几个方案拿出来了，因为我们不是专门来讲解分布式事务的机制和原理，主要还是来做分布式事务的技术选型。
先排除掉我们应该不会选择的方案，一个是 XA 两阶段提交，这个在很多传统型公司会被使用，但不适合互联网微服务的分布式系统，锁定资源时间长，性能影响大，排除。
另一个是阿里的 GTS ，并没有开源，目前已经开源了 Fescar ，不过目前尚缺少调研，可能在下个阶段研究后会使用，目前先排除。
剩下的是 TCC 和 MQ 消息事务两种。
MQ 消息事务：RocketMQ
先说说 MQ 的分布式事务， RocketMQ 在 4.3 版本已经正式宣布支持分布式事务，在选择 RokcetMQ 做分布式事务请务必选择 4.3 以上的版本。
事务消息作为一种异步确保型事务，将两个事务分支通过 MQ 进行异步解耦， RocketMQ 事务消息的设计流程同样借鉴了两阶段提交理论，整体交互流程如下图所示：

这个时候我们基本可以认为，只有 MQ 发送方自己的本地事务执行完毕，那么 MQ 的订阅方必定百分百能够接收到消息，我们再对下单减库存的步骤进行改造。
这里涉及到一个异步化的改造，我们理一下，如果是同步流程中的各个步骤：