千锋大数据开发学院 Boot整合分布式事务简介,SpringBoot2.x教程——Spring( 二 )


2.消息事务+最终一致性
业务示意图:
千锋大数据开发学院 Boot整合分布式事务简介,SpringBoot2.x教程——Spring
文章图片
具体原理如下:
千锋大数据开发学院 Boot整合分布式事务简介,SpringBoot2.x教程——Spring
文章图片
1.A系统向消息中间件发送一条预备消息;2.消息中间件保存预备消息并返回成功;3.A执行本地事务;4.A发送提交消息给消息中间件 。
通过以上4步完成了一个消息事务 。 对于以上的4个步骤 , 每个步骤都可能产生错误 , 下面一一分析:
消息事务小结:优点:实现了最终一致性 , 不需要依赖本地数据库事务 。 缺点:实现难度大 , 主流MQ不支持 , RocketMQ事务消息部分代码也未开源 。
3.本地消息表(异步确保)
原理如下:
千锋大数据开发学院 Boot整合分布式事务简介,SpringBoot2.x教程——Spring
文章图片
?虽然上面的方案能够完成A和B的操作 , 但是A和B并不是严格一致的 , 而是最终一致的 。 我们在这里牺牲了一致性 , 换来了性能的大幅度提升 。 当然 , 这种玩法也是有风险的 , 如果B一直执行不成功 , 那么一致性会被破坏 , 具体要不要玩 , 还是得看业务能够承担多少风险 。
4.补偿事务的TCC编程模式
以在线下单为例 , Try阶段会去扣库存 , Confirm阶段则是去更新订单状态 , 如果更新订单失败 , 则进入Cancel阶段 , 会去恢复库存 。 总之 , TCC就是通过代码人为实现了两阶段提交 , 不同的业务场景所写的代码都不一样 , 复杂度也不一样 , 因此 , 这种模式并不能很好地被复用 。
四.总结不控制就是不引入分布式事务 。 部分控制就是各种变种的两阶段提交 , 包括上面提到的消息事务+最终一致性、TCC模式 , 而完全控制就是完全实现两阶段提交 。 部分控制的好处是并发量和性能很好 , 缺点是数据一致性减弱了 。 完全控制则是牺牲了性能 , 保障了一致性 , 具体用哪种方式 , 最终还是取决于业务场景 。
作为技术人员 , 一定不能忘了技术是为业务服务的 , 不要为了技术而技术 , 针对不同业务进行技术选型也是一种很重要的能力!


推荐阅读