分布式事務簡介

• • 事務
  • • BASE理論
    • 2PC
    • • 第一階段：投票階段
      • 第二階段：提交/執行階段（成功流程）
      • 第二階段失敗回滾流程
      • 2pc可能出現的三種問題
      • 3PC
    • TCC
    • 悲觀鎖與樂觀鎖
  • 參考鏈接

---

事務

BASE理論

BASE 理論是 Basically Available(基本可用)，Soft State（軟狀態）和Eventually Consistent（最終一致性）三個短語的縮寫。

基本可用（Basically Available）：指分布式系統在出現不可預知故障的時候，允許損失部分可用性。

軟狀態（Soft State）：指允許系統中的數據存在中間狀態，并認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。

最終一致（Eventual Consistency）：強調的是所有的數據更新操作，在經過一段時間的同步之后，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。

其核心思想是：

即使無法做到強一致性（Strong consistency），但每個應用都可以根據自身的業務特點，采用適當的方式來使系統達到最終一致性（Eventual consistency）

2PC

兩階段提交又稱2PC,2PC是一個非常經典的強一致、中心化的原子提交協議。這里所說的中心化是指協議中有兩類節點：一個是中心化協調者節點（coordinator）和N個參與者節點（partcipant）。

分為投票階段和提交/執行階段。舉例 訂單服務A，需要調用 支付服務B 去支付，支付成功則處理購物訂單為待發貨狀態，否則就需要將購物訂單處理為失敗狀態。

第一階段：投票階段

事務詢問協調者 向所有的 參與者 發送事務預處理請求，稱之為Prepare，并開始等待各 參與者 的響應。

執行本地事務各個 參與者 節點執行本地事務操作,但在執行完成后并不會真正提交數據庫本地事務，而是先向 協調者 報告說：“我這邊可以處理了/我這邊不能處理”。

各參與者向協調者反饋事務詢問的響應如果 參與者 成功執行了事務操作,那么就反饋給協調者 Yes 響應,表示事務可以執行,如果沒有 參與者 成功執行事務,那么就反饋給協調者 No 響應,表示事務不可以執行。第一階段執行完后，會有兩種可能。

所有都返回Yes。

有一個或者多個返回No。–> 失敗，不進行第二階段

第二階段：提交/執行階段（成功流程）

所有的參與者反饋給協調者的信息都是Yes,那么就會執行事務提交。協調者向所有參與者節點發出Commit請求.

事務提交：參與者收到Commit請求之后,就會正式執行本地事務Commit操作,并在完成提交之后釋放整個事務執行期間占用的事務資源。

第二階段失敗回滾流程

發送回滾請求：協調者向所有參與者節點發出 RoollBack 請求.

事務回滾：參與者接收到RoollBack請求后,會回滾本地事務。

2pc可能出現的三種問題

作者：歐陽豐 鏈接：https://zhuanlan.zhihu.com/p/91263461 來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

協調者正常,參與者宕機?：由于 協調者 無法收集到所有 參與者 的反饋，會陷入阻塞情況。?

解決方案:引入超時機制,如果協調者在超過指定的時間還沒有收到參與者的反饋,事務就失敗,向所有節點發送終止事務請求。

協調者宕機,參與者正常?：無論處于哪個階段，由于協調者宕機，無法發送提交請求，所有處于執行了操作但是未提交狀態的參與者都會陷入阻塞情況.?

解決方案:引入協調者備份,同時協調者需記錄操作日志.當檢測到協調者宕機一段時間后，協調者備份取代協調者，并讀取操作日志，向所有參與者詢問狀態。

協調者和參與者都宕機：

發生在第一階段： 因為第一階段，所有參與者都沒有真正執行commit，所以只需重新在剩余的參與者中重新選出一個協調者，新的協調者在重新執行第一階段和第二階段就可以了。

發生在第二階段 并且 掛了的參與者在掛掉之前沒有收到協調者的指令。也就是上面的第4步掛了，這是可能協調者還沒有發送第4步就掛了。這種情形下，新的協調者重新執行第一階段和第二階段操作。

發生在第二階段 并且 有部分參與者已經執行完commit操作。就好比這里訂單服務A和支付服務B都收到協調者 發送的commit信息，開始真正執行本地事務commit,但突發情況，Acommit成功，B確掛了。這個時候目前來講數據是不一致的。雖然這個時候可以再通過手段讓他和協調者通信，再想辦法把數據搞成一致的，但是，這段時間內他的數據狀態已經是不一致的了！
2PC 無法解決這個問題。

3PC

三階段提交協議（3PC）主要是為了解決兩階段提交協議的阻塞問題，2pc存在的問題是當協作者崩潰時，參與者不能做出最后的選擇。因此參與者可能在協作者恢復之前保持阻塞。三階段提交（Three-phase commit），是二階段提交（2PC）的改進版本。

除了引入超時機制之外，3PC把2PC的準備階段再次一分為二，這樣三階段提交就有CanCommit、PreCommit、DoCommit三個階段。

拋開三階段提交糟糕的性能（并且其也沒有解決2pc丟數據的問題），超時也不是一種可靠的故障檢測機制，因為即使沒有節點崩潰，請求也可能由于網絡問題而超時。出于這個原因，兩階段提交仍然被廣泛使用，盡管存在協調者失效的問題。

所以，因為特性需要（一致性），分布式事務最終會走向分布式共識。

TCC

TCC (Try、Commit、Cancel) 是一種補償型事務，該模型要求應用的每個服務提供 try、confirm、cancel 三個接口，它的核心思想是通過對資源的預留（提供中間態），盡早釋放對資源的加鎖，如果事務可以提交，則完成對預留資源的確認，如果事務要回滾，則釋放預留的資源。

TCC 也是一種兩階段提交協議，可以看作 2PC/XA 的一種變種，但是不會長時間持有資源鎖。

TCC 模型將事務的提交劃分為兩個階段：

階段 1

• 完成業務檢查（一致性）、預留業務資源（準隔離性），即 TCC 中的 try。

階段 2

• 如果 try 階段所有業務資源都預留成功，則執行 confirm 操作，否則執行 cancel 操作：
  • confirm：不做任何業務檢查，僅僅使用預留的資源執行業務操作，如果失敗會一直重試。
  • cancel：取消執行業務操作，釋放預留的資源，如果失敗會一直重試。

TCC 模式中，事務的發起者和參與者都需要記錄事務日志，事務的發起者需要記錄全局事務和各個分支事務的狀態和信息；事務的參與者需要記錄分支事務的狀態。

TCC 事務在執行過程中的任意環節，均可能發生宕機、重啟、網絡中斷等異常情況，此時事務處于非原子狀態和非最終一致狀態，此時就需要根據主事務記錄和分支事務記錄的日志，去完成剩余分支事務的提交或者回滾，使整個分布式事務內所有參展達到最終一致的狀態，實現事務的原子性。

悲觀鎖與樂觀鎖

鎖的一種宏觀分類方式是悲觀鎖和樂觀鎖。悲觀鎖與樂觀鎖并不是特指某個鎖（Java中沒有哪個Lock實現類就叫PessimisticLock或OptimisticLock），而是在并發情況下的兩種不同策略。

• 悲觀鎖（Pessimistic Lock）, 就是很悲觀，每次去拿數據的時候都認為別人會修改。所以每次在拿數據的時候都會上鎖。這樣別人想拿數據就被擋住，直到悲觀鎖被釋放。
• 樂觀鎖（Optimistic Lock）, 就是很樂觀，每次去拿數據的時候都認為別人不會修改。所以不會上鎖，不會上鎖！但是如果想要更新數據，則會在更新前檢查在讀取至更新這段時間別人有沒有修改過這個數據。如果修改過，則重新讀取，再次嘗試更新，循環上述步驟直到更新成功（當然也允許更新失敗的線程放棄操作）。

悲觀鎖阻塞事務，樂觀鎖回滾重試，它們各有優缺點，不要認為一種一定好于另一種。像樂觀鎖適用于寫比較少的情況下，即沖突真的很少發生的時候，這樣可以省去鎖的開銷，加大了系統的整個吞吐量。但如果經常產生沖突，上層應用會不斷的進行重試，這樣反倒是降低了性能，所以這種情況下用悲觀鎖就比較合適。

參考鏈接

分布式開放消息系統(RocketMQ)的原理與實踐

面試必備的分布式事物方案

XA 事務處理

如何選擇分布式事務解決方案？ 阿里技術的文章

強一致性、順序一致性、弱一致性和共識

Raft 算法原理及其在 CMQ 中的應用（上）

通俗易懂 悲觀鎖、樂觀鎖、可重入鎖、自旋鎖、偏向鎖、輕量/重量級鎖、讀寫鎖、各種鎖及其Java實現！

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

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

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