| 解决方案 | 协议 | 优缺点 | 优缺点 | 应用场景 |
强一致性 | 两阶段提交协议(2PC) | XA协议,由Tuxedo提出 | 1、 同步阻塞问题; 2、 单点故障; | 1、极端情况下数据的不一致性; 2、引入事务管理者(协调者),单点故障; 3、系统可伸缩性存在问题; 4、全局事务结束才能释放资源,性能问题; | 在高并发场景下很少使用。 |
三阶段提交协议(3PC) | 1、超时机制解决同步阻塞问题; 2、预备阶段尽可能提早发现问题; | ||||
最终一致性 | TCC 模式(Try、Confirm、Cancel)可以理解为SQL事务中的 Lock、Commit、Rollback | 阿里提出 | 1、对于事务恢复,基于 Quartz调度,按照一定频率进行重试。2、要按具体业务来实现,业务耦合度较高,提高了开发成本。 | 部分控制的好处是并发量和性能很好,缺点是数据一致性减弱了,完全控制则是牺牲了性能,保障了一致性,具体用哪种方式,最终还是取决于业务场景。作为技术人员,一定不能忘了技术是为业务服务的,不要为了技术而技术,针对不同业务进行技术选型也是一种很重要的能力! 世界上解决一个计算机问题最简单的方法:“恰好”不需要解决它!如果系统要实现回滚流程的话,有可能系统复杂度将大大提升,且很容易出现 Bug,估计出现 Bug 的概率会比需要事务回滚的概率大很多。可以考虑当出现这个概率很小的问题,能否采用人工解决的方式。 | tcc-transaction 框架,@Compensable 注解 |
补偿模式 | | 1、重试机制:同步通知、消息队列、定时任务。2、每次更新的时候进行自我恢复和修正。3、定时校对:未完成的定时重试、定时核对。 | | ||
可靠事件模式 | | 1、正向发送消息:消息持久化到本地数据库,标志状态:待发送、结束、已发送、完成等。2、正向接受消息:ACK机制。3、逆向消息:弥补消息主动丢弃。4、补偿机制:定时任务扫描“未完成”的消息并重新投递。 缺点:1、一次消息发送需要两次网络请求(half 消息+ commit/ rollback消息) 。2、业务处理服务需要实现消息状态回查接口。 | |
共性点:
1、 如果最终多次重试失败可以根据相关日志并主动通知开发人员进行手工介入。
2、 业务处理逻辑需要保证幂等。
开源项目的应用:
1、 Apache RocketMQ,(1)解决了消息发送与本地事务执行的原子性问题,方式一、发送预执行消息 -> 执行本地事务 -> 正式投递消息/删除之前的预执行消息;方式二、RocketMQ 主动询问生产者,对该消息发起消息回查。(2)引入了 ACK 机制,如果消费者因宕机等原因没有发送 ACK,消息队列会将消息重新发送,保证消息的可靠性。
2、 ServiceComb Saga,ServiceComb包含代码框架生成、微服务框架,其中Saga 是一个最终一致性解决方案。Saga 比 TCC 少了一个 Try 操作。因此,Saga 会直接提交到数据库,然后出现失败的时候,进行补偿操作。Saga 拆分分布式事务为多个本地事务。Saga 有两种恢复的策略:向前恢复和向后恢复。添加@EnableOmega、@SagaStart、@Compensable 等注解。
3、 LCN,其本身并不创建事务,而是基于对本地事务的协调从而达到事务一致性的效果。有3种模式,分别是LCN模式,TCC模式,TXC模式。
参考文献:
[2] https://www.cnblogs.com/monkeyblog/p/10449363.html?from=singlemessage&isappinstalled=0