各位志同道合的朋友们大家好，我是一个一直在一线互联网踩坑十余年的编码爱好者，现在将我们的各种经验以及架构实战分享出来，如果大家喜欢，就关注我，一起将技术学深学透，我会每一篇分享结束都会预告下一专题

上一篇中我们详细分析了分布式事务，以及分布式事务的两种实现方案，二阶段提交和三阶段提交(「分布式技术」分布式事务真实解决方案，上篇)。他们都是满足了事务的ACID特性。但是，他们都有共同的缺点：同步阻塞，系统性能低以及没有解决数据不一致的问题。那今天我们来看学另一种方案，基于消息的实现方式。

基于分布式消息的最终一致性方案

在eBay分布式系统中，架构师们解决一致性问题的核心方法论是：将需要分布式处理的事务通过消息的方式进行异步处理，然后根据业务规则自行进行失败重试。现在，我们知道了需要有个核心组件，那就消息中间件，通过消息中间件进行分布式系统中各个消息的传递动作如下图：

现在我将我们用户电商购物下单怎么实现分布式最终一致性整个开发流程做个讲解，期间涉及到订单系统、支付系统、仓库系统，他们彼此的协作时序图如下：

然后，我们看看它基于消息的最终一致性方案，整个流程是这样的：

1. 订单系统将要处理订单的消息发送到消息中间件MQ中，消息状态为“待确认”。
2. 消息中间件MQ将订单系统发来的消息进行持久化存储操作，即在MQ中增加一个“待发送”的消息。
3. 消息中间件MQ将持久化结果返回给订单系统，如果成功，订单系统则进行创建订单操作，失败则放弃本次创单操作。
4. 订单系统完成订单的相关操作后，将结果(成功或者失败)再发给消息中间件MQ。
5. 消息中间件收到上面消息后，则进行相应的处理，如果失败消息，则终止本次交易，删除MQ消息；如果是成功则更新MQ中消息状态为可发送，就会将消息发送到支付系统。
6. 支付系统收到消息还是按照上面传递步骤进行同样的操作进行支付。
7. 支付系统将支付消息发给MQ，然后MQ将消息发给订单系统，订单系统进行调用库存系统业务。

所以，基于分布式消息最终一致性方案，一样是依据分布式系统中所有事务均成功则整个交易流程才成功的原则。其实，在我们大部分互联网项目中在应对分布式事务的时候，都会先牺牲下少许的数据不一致，来做成最终数据一致性的方案，遵从的是BASE理论。

什么是BASE理论

既然说到了消息最终一致性遵从BASE理论，我觉得有必要将BASE理论科普下。

BASE：全称是，Basically Avaliable(基本可用)，Soft state(软状态)，Eventually consistent(最终一致性)三个短语的缩写，来自eBay的架构师提出。

• Basically Avaliable：就是在分布式系统环境中，允许牺牲掉部分不影响主流程的功能的不可用，将其降级以确保核心服务的正常可用。

• Soft state：就是指在事务中，我们允许系统存在中间状态，且并不影响我们这个系统。就拿数据库的主从复制来说，是完全允许复制的时候有延时的发生的。

• Eventually consistent：还是以数据库主从复制为例说，虽然主从复制有小延迟，但是很快最终就数据保持一致了。

三种方案比较：

现在我们将上篇「分布式技术」分布式事务真实解决方案，上篇 中的二阶段提交、三阶段提交以及今天所说的基于分布式消息的最终一致性方案，基于其各自相关特点做一比较。

最后，我们再整体回顾下分布式事务的三种实现方式，整理个思维导图，帮助大家根据自己的业务进行合理的选择哪一种方案来实现自己公司的分布式事务：

总结，今天分享了分布式事务基于分布式消息最终一致性的方案，该方案是遵从BASE理论，并将BASE理论做了科普，然后对比了上篇将的二阶段提交和三阶段提交，这三种方案均是可以被用在生产的，看自己的项目进行选择，二阶段和三阶段是强制性算法，所以，你的项目如果对于一致性比较严格就才去这这方案；而消息最终一致性是可以容忍系统的部分不一致的，但是最终是一致的，比如上面我讲的我们公司的案例就是这样的使用了最终一致性方案。

如果大家喜欢，就关注我，我会一直分享业界以及我们自己的真实实战经验

下一篇预告：就是把我们的分布式锁的开发方案给大家分享，敬请期待哈