分布式事務

什么是分布式事務？

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

簡單的說，事務提供了一種機制，使得作業要么全部都不做，要么全部被執行，即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因為強一致性而在某些情況下導致資料不一致的問題，

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

標籤：Java

上一篇：【一句話】@Configuration和@Component的區別

下一篇：Nacos配置中心 (介紹與配置)