分佈式事務里的最終一致性

• 2019 年 12 月 2 日
• 筆記

本地事務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回滾的