微服務~分布式事務裏的最終一致性
阿新 • • 發佈：2017-10-10
tco 強一致 ons 發送消息 安裝 log ext 出現 ole 
本地事務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回滾的
同時也感謝cap作者楊曉東的細心解答！（http://www.cnblogs.com/savorboard）
Github開源地址：https://github.com/dotnetcore/CAP
感謝！
微服務~分布式事務裏的最終一致性