（微服务）分布式事务-最大努力交付 && 消息最终一致性方案

小插曲

本话题已收入视频讲座《Spring Cloud分布式事务解决方案》大家不妨围观下。开源项目: CoolMQ，项目支持网站: http://rabbitmq.org.cn，最新文章或实现会更新在上面

前言

本文对比 二阶段事务、最大努力交付以及消息最终一致性，并给出部分解决方案,最终一致性方案参考阿里RockMQ事务消息：http://blog.csdn.net/chunlongyu/article/details/53844393）

一 2阶段事务

分布式系统最终一致性有N种方案，比如2PC（2阶段事务） ，以及三段提交等等，但开销较大，实现起来复杂，比如2阶段事务为例，需要引入一个协调者（Coordinator）来统一掌控所有参与者（Participant）的操作结果

以开会为例：
甲乙丙丁四人要组织一个会议，需要确定会议时间，不妨设甲是协调者，乙丙丁是参与者。
投票阶段：
（1）甲发邮件给乙丙丁，周二十点开会是否有时间；
（2）甲回复有时间；
（3）乙回复有时间；
（4）丙迟迟不回复，此时对于这个活动，甲乙丙均处于阻塞状态，算法无法继续进行；
（5）丙回复有时间（或者没有时间）；
提交阶段：
（1）协调者甲将收集到的结果反馈给乙丙丁（什么时候反馈，以及反馈结果如何，在此例中取决与丙的时间与决定）；
（2）乙收到；
（3）丙收到；
（4）丁收到；
不仅要锁住参与者的所有资源，而且要锁住协调者资源，开销大。一句话总结就是：2PC效率很低，分布式事务很难做。

在对事实性要求没有那么高的情况下，可以用基于最大努力交付 && 消息队列以及消息存储来解决最终一致性。

二 消息最大努力交付

所谓最大努力交付，就是俺反正用最大努