微服務系統所設計的系統是分布式系統。分布式系統有一個著名的CAP理論，即同時滿足“一致性”“可用性”和“分區容錯”是一件不可能的事。CAP理論是由Eric Brewer在2000年PODC會議上提出的，該理論在兩年后被證明成立。CAP理論告訴架構師不要妄想設計出同時滿足三者的系統，應該有所取舍，設計出適合業務的系統。CAP理論示意圖

• Consistency：指數據的強一致性。每次的讀操作，都是讀取的最新數據。即如果寫入某個數據成功，之后讀取，讀到的都是新寫入的數據；如果寫入失敗，之后讀取的都不是寫入失敗的數據。
• Availability：指服務的可用性。即每個請求都能在合理的時間內獲得符合預期的響應。
• Partition-tolerance：指分區容錯性。當節點之間的網絡出現問題之后，系統依然能正常提供服務。

在分布式系統中，P是基本要求，而單體服務是CA系統。微服務系統通常是一個AP系統，即同時滿足了可用性和分區容錯。這就有了一個難題：在分布式系統中如何保證數據的一致性？這就是大家經常討論的分布式事務。

在微服務系統中，每個服務都是獨立的進程單元，每個服務都有自己的數據庫。通常情況下，只有關系型數據庫在特定的數據引擎下才支持事務，而大多數非關系型數據庫是不支持事務的，例如 MongDB 是不支持事務的，而 Redis 是支持事務的。在微服務架構中，分布式事務一直都是一個難以解決的問題，業界給出的解決辦法通常是兩階段提交。

網上購物在日常生活中是一個非常普通的場景，假設我在淘寶上購買了一部手機，需要從我的賬戶中扣除1000元錢，同時手機的庫存數量需要減1。當然需要在賣方的賬戶中加1000元錢，為了使案例簡化，暫時不用考慮。

如果這是一個單體應用，并且使用支持事務的MySQL數據庫（InnoDB數據庫引擎才支持事務），我們可能這樣寫代碼：

@Transactional public void updata() throws RuntimeException{updateAccountTable(); //更新賬戶表updateGoodsTable(); //更新商品表 }

兩階段提交

如果是微服務架構，賬戶是一個服務，而商品是一個服務，這時不能用數據庫自帶的事務，因為這兩個數據表不在一個數據庫中。因此常常用到兩階段提交，兩階段提交的過程如圖所示

第一階段，service-account 發起一個分布式事務，交給事務協調器TC處理，事務協調器TC向所有參與的事務的節點發送處理事務操作的準備操作。所有的參與節點執行準備操作，將 Undo 和 Redo 信息寫進日志，并向事務管理器返回準備操作是否成功。

第二階段，事務管理器收集所有節點的準備操作是否成功，如果都成功，則通知所有的節點執行提交操作；如果有一個失敗，則執行回滾操作。

兩階段提交，將事務分成兩部分能夠大大提高分布式事務成功的概率。如果在第一階段都成功了，而執行第二階段的某一節點失敗，仍然導致數據的不準確，這時一般需要人工去處理，這就是當初在第一步記錄日志的原因。另外，如果分布式事務涉及的節點很多，某一個節點的網絡出現異常會導致整個事務處于阻塞狀態，大大降低數據庫的性能。所以一般情況下，盡量少用分布式事務。

三階段提交

三階段提交在兩階段提交的步驟中間加了一層預提交事務階段，具體來說，包括以下三個階段
1.CanCommit階段
這個階段和光彥說的兩階段提交的準備階段類似，不同的地方就是并沒有進行諸如將 Undo 和 Redo 信息寫進事務日志的其它操作。
2.PreCommit階段
這個階段是一個緩沖，目的是推遲commit決定，只有保證所有參與者都知道了commit決定后，才真正發出commit決定。所有的參與者都會在這個階段記錄Undo和Redo信息，并且當協調者發生故障后，所有的參與者還能互相通信確定事務是提交還是終止。
3.DoCommit階段
這個階段就是事務的真正提交。如果所有的參與者都向協調者發送了ACK響應，那么協調者就會完成事務，否則中斷事務。

三階段提交的方案引入對參與者的超時機制，相比兩階段提交只有協調者擁有超時機制，三階段提交解決了協調者突然掛掉引起的參與者一直阻塞的問題。

本質上來說，三階段提交避免了狀態停滯！在兩階段提交中有可能因為各種原因，產生狀態停滯。最明顯的就像元太所說，協調者突然宕機。但在三階段提交中會讓狀態繼續下去，就算協調者宕機，參與者們也會互相通信確定事務是提交還是終止，從而使狀態繼續下去，哪怕，這是錯的！

轉載于:https://www.cnblogs.com/yueshutong/p/10251441.html

總結

以上是生活随笔為你收集整理的CAP理论与分布式事务解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。