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

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