小插曲
本话题已收入视频讲座《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效率很低,分布式事务很难做。
在对事实性要求没有那么高的情况下,可以用基于最大努力交付 && 消息队列以及消息存储来解决最终一致性。
二 消息最大努力交付
所谓最大努力交付,就是俺反正用最大努力做