- 如何实现最终一致性分布式事务
- 二阶段提交
- 概念:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情况决定各个参与者是否要提交操作或者终止操作
- 作用:主要保证了分布式事务的原子性,第一阶段为准备阶段,第二阶段为提交阶段
- 缺点:不仅要锁住参与者的所有资源,而且要锁住协调者资源,开销大,一句话总结就是2PC效率很低,对高并发很不友好
- 三阶段提交:
- 概念:三阶段提交协议在协调者和参与者中都引入了超时机制,并且把两阶段提交协议的第一阶段拆分成了两步:询问,然后再锁资源,最后真正提交,这样三阶段提交就有CanCommit,PreCommit,DoComiit三个阶段。
- 协调者询问各个参与者是否可以正常执行
- 参与者集群预估判断是否可以执行
- 正常执行,进入pre-commit,不满足或者等待超时,abort
- 协调者询问各个参与者是否可以正常执行
- 参与者集群执行事务但是不提交
- 协调者接受反馈,正常执行则commit,失败或者等待超时则rollback
- 协调者向所有参与者发起事务提交通知
- 参与者集群收到通知或超时提交
- 参与者集群反馈事务提交结果
- 参与者超时提交,出现不一致
- 缺点:如果进入pre-commit后,协调者发出的是abort请求,假设只有一个参与者收到并进行了abort操作,而其他对于系统状态未知的参与者选择继续提交commit,此时系统状态发生不一致
- 概念:三阶段提交协议在协调者和参与者中都引入了超时机制,并且把两阶段提交协议的第一阶段拆分成了两步:询问,然后再锁资源,最后真正提交,这样三阶段提交就有CanCommit,PreCommit,DoComiit三个阶段。
- 柔性事务
- 概念:所谓柔性事务是相对强制缩表的刚性事务而言,流程如下:
- 服务器A的事务如果执行顺利,那么事务A就先行提交,如果事务B也执行顺利,则事务B也提交,整个事务就算完成,
- 但是如果事务B执行失败,事务B本身回滚,这时事务A已经提交,所以需要执行一个补偿操作,将已经提交的事务A执行的操作进行反操作,恢复到未执行前事务A的状态
- 缺点:业务侵入性太强,还要补偿操作,缺乏普遍性,没法大规模推广
- 概念:所谓柔性事务是相对强制缩表的刚性事务而言,流程如下:
- 消息最终一致性解决方案之RabbitMQ实现:
- 实现:发送方确认+消息持久化+消费者确认
- 二阶段提交