分散式事務

什麼是分散式事務？

事務提供了一種機制，將包含一系列操作的工作序列納入到一個不可分割的執行單元，只有所有操作都被正確執行才能提交事務，任意一個操作失敗都會導致整個事務回滾到之前狀態。

簡單的說，事務提供了一種機制，使得工作要麼全部都不做，要麼全部被執行，即all or nothing。

分散式事務，就是在分散式系統中運行的事務，由多個本地事務組合而成，在分散式場景下，對事務的處理操作可能來自不同的機器，甚至是來自不同的操作系統。

什麼是ACID？

ACID是事務具有的四大基本特征：

• A：原子性（Atomicity），即事物最終的狀態只有兩種，全部執行成功或全部不執行，不會停留在中間某個環節。
• C：一致性（Consistency），指事務操作前和操作後，數據滿足完整性約束，資料庫保持一致性狀態。
• I：隔離性（Isolation），指當系統內有多個事務併發執行時，多個事務同時使用相同的數據時，不會相互干擾，每個事務都有一個完整的數據空間，對其他事務時隔離的。
• D：持久性（Durability），指一個事物被執行後，那麼它對資料庫所做的更新就永久地保存下來了。

什麼是BASE理論？

ACID中的C是強一致性，也就是說所有操作都執行成功才能提交最終結果，以保證數據一致性或完整性。隨著分散式系統規模不斷擴大，複雜度急劇上升，達成強一致所需時間周期較長，限定了複雜業務的處理。

為瞭解決這一挑戰，提出了BASE理論，關鍵點在於採用最終一致性來取代強一致性：

• 基本可用（Basically Available）：分散式系統出現故障時，允許損失一部分功能的可用性，保證核心功能可用。
• 柔性狀態（Soft State）：在柔性事務中，允許系統存在中間狀態，且這個中間狀態不影響系統整體可用性。
• 最終一致性（Eventually Consistency）：事務在操作過程中可能會由於同步延遲等問題導致不一致，但最終狀態下，所有的數據都是一致的。

ACID和BASE是對一致性和可用性的不同權衡所產生的不同結果，但二者都保證了數據的持久性。ACID選擇了強一致性而放棄了系統的可用性，BASE理論則保證了系統的可用性，允許數據在一段時間內可以不一致，最終達到一致狀態即可。

什麼是剛性事務和柔性事務？

• 剛性事務：遵循ACID原則，具有強一致性。
• 柔性事務：根據不同的業務場景使用不同的方法實現最終一致性，它允許數據在一定時間內不一致，但要求最終一致。

如何實現分散式事務？

常用的分散式事務有3種基本方法：

• 基於XA協議的二階段提交協議方法
• 三階段提交協議方法
• 基於消息的最終一致性方法

基於XA協議的二階段提交方法

基於XA協議的二階段提交方法中，二階段提交協議（Two-phase Commit Protocol，2PC）是用於保證分散式系統中事務提交時的數據一致性，是XA在全局事務中用於協調多個資源的機制。

它引入了一個協調者來管理所有的節點，並確保這些節點正確提交操作結果，如果提交失敗則放棄事務。

二階段提交協議的執行過程分為投票（Voting）和提交（Commit）兩個階段：

• 投票階段：協調者（Coordinator）向事務參與者（Cohort）發起執行操作的CanCommit請求，並等待參與者的響應。參與者收到請求後，會執行請求中的事務操作，將操作信息記錄到事務日誌中但不提交（不會修改資料庫中的數據），待參與者執行成功，則向協調者發送“Yes”消息，表示同意操作，若不成功，則發送“No”消息，表示終止操作。
• 提交階段：協調者受到所有參與者的消息後，根據受到的消息，向所有參與者發送DoCommit或者DoAbort消息，規則如下：
  • 如果協調者受到的都是“Yes”，那麼它會向所有參與者發送“DoCommit”消息，參與者收到消息後，完成剩餘操作（比如修改資料庫中的數據）並釋放資源，然後向協調者發送“HaveCommitted”消息。
  • 如果協調者收到的消息中包含“No”，那麼它會向所有參與者發送“DoAbort”消息，此時在投票階段發送“Yes”消息的參與者，會根據之前執行操作時的事務日誌對操作進行回滾，之後所有參與者會向協調者發送“HaveCommitted”消息。
  • 協調者接收到所有參與者的“HaveCommitted”消息後，就意味著整個事務結束了。

二階段提交的演算法思路可以概括為：協調者向參與者下發請求事務操作，參與者接收到請求後，進行相關操作並將操作結果通知協同者，協同者根據所有參與者的反饋結果決定各參與者是要提交操作還是撤銷操作。

基於XA的二階段提交演算法存在的問題：

• 同步阻塞問題，二階段提交演算法在執行過程中，所有參與者都是事務阻塞型的，這樣它不支持高併發場景。
• 單點故障問題，演算法類似於集中式演算法，一旦事務管理器發生故障，整個系統都處於停滯狀態。尤其是在提交階段一旦事務管理器發生故障，資源管理器會由於等待管理器的消息，而一直鎖定事務資源，導致整個系統被阻塞。
• 數據不一致問題，在提交階段，當協調者向所有參與者發送“DoCommit”請求時，如果發生了局部網路異常，或者在發送提交請求的過程中協調者發生了故障，就會導致只有一部分參與者接收到了提交請求並執行提交操作，但其他未接收到提交請求的那部分參與者則無法執行事務提交，這樣會造成數據不一致。

三階段提交方法

三階段提交協議（Three-phase Commit Protocol，3PC）是對二階段提交（2PC）的改進，它引入了超時機制和準備階段。

• 3PC引入了超時機制，如果協調者或參與者在規定時間內沒有收到來自其他節點的消息，就會根據當前的狀態選擇提交或者終止整個事務，從而減少整個集群的阻塞時間。
• 3PC在2PC的第一階段和第二階段中間引入了一個準備階段，或者說把2PC的投票階段一分為二，在提交階段之前，加入了一個預提交階段。

三階段提交協議有CanCommit、PreCommit和DoCommit三個階段：

• CanCommit階段：協調者向參與者發送請求操作（CanCommit請求），詢問參與者是否可以執行事務提交操作，然後等待參與者響應，參與者收到CanCommit請求後，回覆Yes表示可以順利執行事務，否則回覆No。需要註意這時參與者不會將操作信息記錄到事務日誌中。
• PreCommit階段：協調者根據參與者的回覆消息，決定是否可以進行PreCommit操作：
  • 如果所有參與者回覆的都是Yes，那麼協調者就會執行事務的預執行。
  • 協調者向參與者發送PreCommit請求，進入預提交階段。
  • 參與者收到PreCommit請求後執行事務操作，並將Undo和Redo信息記錄到事務日誌中。
  • 如果參與者成功執行了事務操作，則返回ACK響應，同時開始等待最終指令。
  • 假如任何一個參與者向協調者發送了“No”消息，或者等待超時後，協調者都沒有收到參與者的響應，就執行中斷事務的操作。
  • 協調者向所有參與者發送“Abort”消息。
  • 參與者收到“Abort”消息後，或超時後仍未收到協調者的消息，執行中斷事務操作。
• DoCommit階段：執行真正的事務提交，根據PreCommit階段協調者發送的消息，進入執行提交階段或者中斷事務階段。
  • 執行提交階段：
    • 如果協調者接收到所有參與者的ACK響應，則向所有參與者發送DoCommit消息，開始執行階段。
    • 參與者接收到DoCommit消息後，正式提交事務，完成事務提交後，釋放所有鎖住的資源，並向協調者發送ACK響應。
    • 協調者接收到所有參與者的ACK響應後，完成事務。
  • 中斷事務階段：
    • 協調者向所有參與者發送Abort請求。
    • 參與者接收到Abort消息後，利用其在PreCommit階段記錄的Undo信息執行事務的回滾操作，釋放所有鎖住的資源，並向協調者發送ACK消息。
    • 協調者接收到所有參與者發送的ACK響應，執行事務中斷操作，並結束事務。

3PC協議在協調者和參與者都引入了超時機制，當參與者在預提交階段向協調者發送ACK消息後，如果長時間沒有得到協調者的響應，在預設情況下，參與者會自動降超時事務進行提交，從而減少整個集群的阻塞時間。

三階段提交仍然會存在數據不一致的情況。

基於分散式消息的最終一致性方案

2PC和3PC的核心思想都是以集中式的方式實現分散式事務，它有兩個缺點：

• 同步執行，性能差
• 數據不一致問題

我們解決一致性問題的核心思想：將需要分散式處理的事務通過消息或者日誌的方式非同步執行，消息或日誌可以存到本地文件、資料庫或者消息隊列中，再通過業務規則進行失敗重試。

基於分散式消息的最終一致性方案的事務處理，引入了一個消息中間件，用於在多個應用之間進行消息傳遞。

這種方案採用消息傳遞機制，並使用非同步通信的方式，避免了通信阻塞，從而增加系統的吞吐量，同時它還可以屏蔽不同系統的協議規範，使其可以直接交互。

在不需要請求立即返回結果的場景下，這些特性就帶來了明顯的通信優勢，並且通過引入消息中間件，實現了消息生成方本地事務和消息發送的原子性，採用最終一致性方式，只需保證數據最終一致即可，一定程度上解決了2PC和3PC因為強一致性而在某些情況下導致數據不一致的問題。

針對上述三種不同的分散式事務方法，詳細的比較如下表所示。