概述
本地事务ACID大家应该都知道了,统一提交,失败回滚,严格保证了同一事务内数据的一致性!而分布式事务不能实现这种ACID,它只能实现CAP原则里的某两个,CAP也是分布式事务的一个广泛被应用的原型,CAP(Consistency, Availability, Partition Tolerance), 阐述了一个分布式系统的三个主要方面, 只能同时择其二进行实现. 常见的有CP系统, AP系统。
应用于CP和AP的原则在业界出现了一些框架:
CP系统就有二阶段提交(强一致性)

AP系统就有TCC(补偿型事务)

其中最近接触的aspnetcore.cap就是一个满足最终一致性的异步消息方案实现的,其中它为mysql,sqlserver都提供了解决方案,消息队列可以有kafka和rabbitmq两种选择,根据自己的需要去安装,源代码在github上有开源,nuget上也有对应的包包!
对消息确保型-最终一致性的分布式事务的理解:
- 服务A提交数据
- 向消息中心发送消息
- 消息中心向订阅方推送消息
- 订阅方处理自己的业务逻辑
- 失败去反复去重试,直到成功,而不是向强一致性那样,把A回滚的
关注我,后续更多干货奉上!
最后
以上就是彩色烤鸡为你收集整理的一致 先验分布 后验分布_分布式事务里的最终一致性关注我,后续更多干货奉上!的全部内容,希望文章能够帮你解决一致 先验分布 后验分布_分布式事务里的最终一致性关注我,后续更多干货奉上!所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
发表评论 取消回复