微服务~分布式事务里的最终一致性

Posted 敢于对过去告一个段落,才有信心掀开新的篇章!

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微服务~分布式事务里的最终一致性相关的知识,希望对你有一定的参考价值。

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

应用于CP和AP的原则在业界出现了一些框架:

CP系统就有二阶段提交(强一致性)

 

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

 

其中最近接触的aspnetcore.cap就是一个满足最终一致性的异步消息方案实现的,其中它为mysql,sqlserver都提供了解决方案,消息队列可以有kafka和rabbitmq两种选择,根据自己的需要去安装,源代码在github上有开源,nuget上也有对应的包包!

对消息确保型-最终一致性的分布式事务的理解

  1. 服务A提交数据
  2. 向消息中心发送消息
  3. 消息中心向订阅方推送消息
  4. 订阅方处理自己的业务逻辑
  5. 失败去反复去重试,直到成功,而不是向强一致性那样,把A回滚的

同时也感谢cap作者杨晓东的细心解答!(http://www.cnblogs.com/savorboard

Github开源地址:https://github.com/dotnetcore/CAP

感谢!

以上是关于微服务~分布式事务里的最终一致性的主要内容,如果未能解决你的问题,请参考以下文章

亿级分布式事务架构思维模型,微服务下如何保证最终一致性?

字节跳动面试官问:微服务下如何保证分布式事务的最终一致性?

面试官问:微服务下有几种保证分布式事务最终一致性的方案?

.Net Core with 微服务 - 可靠消息最终一致性分布式事务

微服务架构下处理分布式事务,你必须知道的事儿

微服务架构下处理分布式事务的典型方案