一 分散式系統特點

現今網際網路界，分散式系統和微服務架構盛行。業界著名的CAP理論也告訴我們，在設計和實現一個分散式系統時，需要將資料一致性、系統可用性和分割槽容忍性放在一起考慮。

1、CAP理論

在分散式系統中，一致性（Consistency）、可用性（Availability）和分割槽容忍性（Partition Tolerance）3 個要素最多隻能同時滿足兩個，不可兼得。其中，分割槽容忍性又是不可或缺的。

• 一致性：分散式環境下多個節點的資料是否強一致。
• 可用性：分散式服務能一直保證可用狀態。當用戶發出一個請求後，服務能在有限時間內返回結果。
• 分割槽容忍性：特指對網路分割槽的容忍性。

舉例：Cassandra、Dynamo 等，預設優先選擇AP，弱化C；HBase、MongoDB 等，預設優先選擇CP，弱化A。

2、BASE 理論

核心思想：

• 基本可用（Basically Available）：指分散式系統在出現故障時，允許損失部分的可用性來保證核心可用。
• 軟狀態（Soft State）：指允許分散式系統存在中間狀態，該中間狀態不會影響到系統的整體可用性。
• 最終一致性（Eventual Consistency）：指分散式系統中的所有副本資料經過一定時間後，最終能夠達到一致的狀態。

二 一致性模型

資料的一致性模型可以分成以下 3 類：

1. 強一致性：資料更新成功後，任意時刻所有副本中的資料都是一致的，一般採用同步的方式實現。
2. 弱一致性：資料更新成功後，系統不承諾立即可以讀到最新寫入的值，也不承諾具體多久之後可以讀到。
3. 最終一致性：弱一致性的一種形式，資料更新成功後，系統不承諾立即可以返回最新寫入的值，但是保證最終會返回上一次更新操作的值。

分散式系統資料的強一致性、弱一致性和最終一致性可以通過Quorum NRW演算法分析。

三 分散式事務

分散式事務的目的是保障分散式儲存中資料一致性，而跨庫事務會遇到各種不可控制的問題，如個別節點宕機，像單機事務一樣的ACID是無法奢望的。

1、Two/Three Phase Commit

2PC，中文叫兩階段提交。在分散式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的元件來統一掌控所有節點（稱作參與者）的操作結果並最終指示這些節點是否要把操作結果進行真正的提交。 兩階段提交的演算法如下：

第一階段：

1. 協調者會問所有的參與者結點，是否可以執行提交操作。
2. 各個參與者開始事務執行的準備工作：如：為資源上鎖，預留資源。
3. 參與者響應協調者，如果事務的準備工作成功，則迴應“可以提交”，否則迴應“拒絕提交”。

第二階段：

• 如果所有的參與者都回應“可以提交”，那麼，協調者向所有的參與者傳送“正式提交”的命令。參與者完成正式提交，並釋放所有資源，然後迴應“完成”，協調者收集各結點的“完成”迴應後結束這個Global Transaction。
• 如果有一個參與者迴應“拒絕提交”，那麼，協調者向所有的參與者傳送“回滾操作”，並釋放所有資源，然後迴應“回滾完成”，協調者收集各結點的“回滾”迴應後，取消這個Global Transaction。

兩段提交最大的問題就是第3）項，如果第一階段完成後，參與者在第二階沒有收到決策，那麼資料結點會進入“不知所措”的狀態，這個狀態會block住整個事務。也就是說，協調者Coordinator對於事務的完成非常重要，Coordinator的可用性是個關鍵。

因些，我們引入三段提交，三段提交在Wikipedia上的描述如下，他把二段提交的第一個段break成了兩段：詢問，然後再鎖資源。最後真正提交。三段提交的核心理念是：在詢問的時候並不鎖定資源，除非所有人都同意了，才開始鎖資源。但三階段提交也存在一些缺陷，要徹底從協議層面避免資料不一致，可以採用Paxos或者Raft 演算法。

目前兩階段提交、三階段提交存在如下的侷限性，並不適合在微服務架構體系下使用：

• 所有的操作必須是事務性資源（比如資料庫、訊息佇列、EJB元件等），存在使用侷限性（微服務架構下多數使用HTTP協議），比較適合傳統的單體應用；

• 由於是強一致性，資源需要在事務內部等待，效能影響較大，吞吐率不高，不適合高併發與高效能的業務場景；

2、Try Confirm Cancel（TCC）

一個完整的TCC業務由一個主業務服務和若干個從業務服務組成，主業務服務發起並完成整個業務活動，TCC模式要求從服務提供三個介面：Try、Confirm、Cancel。

1. Try：完成所有業務檢查，預留必須業務資源。

2. Confirm：真正執行業務，不作任何業務檢查；只使用Try階段預留的業務資源；Confirm操作滿足冪等性。

3. Cancel：釋放Try階段預留的業務資源；Cancel操作滿足冪等性。

整個TCC業務分成兩個階段完成：

第一階段：主業務服務分別呼叫所有從業務的try操作，並在活動管理器中登記所有從業務服務。當所有從業務服務的try操作都呼叫成功或者某個從業務服務的try操作失敗，進入第二階段。

第二階段：活動管理器根據第一階段的執行結果來執行confirm或cancel操作。如果第一階段所有try操作都成功，則活動管理器呼叫所有從業務活動的confirm操作。否則呼叫所有從業務服務的cancel操作。

與2PC比較：

• 位於業務服務層而非資源層。
• 沒有單獨的準備（prepare）階段，Try操作兼備資源操作與準備能力。
• Try操作可以靈活選擇業務資源的鎖定粒度。
• 開發成本較高。

缺點：

• Canfirm和Cancel的冪等性很難保證。
• 這種方式缺點比較多，通常在複雜場景下是不推薦使用的，除非是非常簡單的場景，非常容易提供回滾Cancel，而且依賴的服務也非常少的情況。
• 這種實現方式會造成程式碼量龐大，耦合性高。而且非常有侷限性，因為有很多的業務是無法很簡單的實現回滾的，如果序列的服務很多，回滾的成本實在太高。

3、非同步確保最終一致性

核心思想：

本地訊息表

其基本的設計思想是將遠端分散式事務拆分成一系列的本地事務。如果不考慮效能及設計優雅，藉助關係型資料庫中的表即可實現。

舉個經典的跨行轉賬的例子來描述。

第一步虛擬碼如下，扣款100，通過本地事務保證了憑證訊息插入到訊息表中：

begin transaction:
　　update User set account = account - 100 where userId = 'A'
　　insert into message(msgId, userId, amount, status) values('123','A', 100, 1)
commit transaction

第二步，通知對方銀行賬戶上加100了。那問題來了，如何通知到對方呢？

通常採用兩種方式：

1. 採用時效性高的MQ，由對方訂閱訊息並監聽，有訊息時自動觸發事件。
2. 採用定時輪詢掃描的方式，去檢查訊息表的資料。

兩種方式其實各有利弊，僅僅依靠MQ，可能會出現通知失敗的問題。而過於頻繁的定時輪詢，效率也不是最佳的（90%是無用功）。所以，我們一般會把兩種方式結合起來使用。

解決了通知的問題，又有新的問題了。萬一這訊息有重複被消費，往使用者帳號上多加了錢，那豈不是後果很嚴重？其實我們可以訊息消費方也通過一個“消費狀態表”來記錄消費狀態。在執行“加款”操作之前，檢測下該訊息（提供標識）是否已經消費過，消費完成後，通過本地事務控制來更新這個“消費狀態表”。這樣子就避免重複消費的問題：

get msgId = '123';
check if mgsId is in message_applied(msgId);
if not applied:
    begin transaction:
        update User set account = account + 100 where userId = 'B'
        insert into message_applied(msgId) values('123')
    commit transaction

上訴的方式是一種非常經典的實現，基本避免了分散式事務，實現了“最終一致性”。但是，關係型資料庫的吞吐量和效能方面存在瓶頸，頻繁的讀寫訊息會給資料庫造成壓力。所以，在真正的高併發場景下，該方案也會有瓶頸和限制的。

MQ（非事務訊息）

通常情況下，在使用非事務訊息支援的MQ產品時，我們很難將業務操作與對MQ的操作放在一個本地事務域中管理。還是以上述提到的“跨行轉賬”為例，我們很難保證在扣款完成之後對MQ投遞訊息的操作就一定能成功。這樣一致性似乎很難保證。

我們來分析下可能的情況：

1. 操作資料庫成功，向MQ中投遞訊息也成功，皆大歡喜。
2. 操作資料庫失敗，不會向MQ中投遞訊息了。
3. 操作資料庫成功，但是向MQ中投遞訊息時失敗，向外丟擲了異常，剛剛執行的更新資料庫的操作將被回滾。

從上面分析的幾種情況來看，貌似問題都不大的。那麼我們來分析下消費者端面臨的問題：

1. 訊息出列後，消費者對應的業務操作要執行成功。如果業務執行失敗，訊息不能失效或者丟失。需要保證訊息與業務操作一致。
2. 儘量避免訊息重複消費。如果重複消費，也不能因此影響業務結果。

如何保證訊息與業務操作一致，不丟失？

主流的MQ產品都具有持久化訊息的功能。如果消費者宕機或者消費失敗，都可以執行重試機制的（有些MQ可以自定義重試次數）。

如何避免訊息被重複消費造成的問題？

1. 保證消費者呼叫業務的服務介面的冪等性。
2. 通過消費日誌或者類似狀態表來記錄消費狀態，便於判斷（建議在業務上自行實現，而不依賴MQ產品提供該特性）。

這種方式比較常見，效能和吞吐量是優於使用關係型資料庫訊息表的方案。如果MQ自身和業務都具有高可用性，理論上是可以滿足大部分的業務場景的。不過在沒有充分測試的情況下，不建議在交易業務中直接使用。

MQ（事務訊息）

舉個例子，Bob向Smith轉賬，那我們到底是先發送訊息，還是先執行扣款操作？

好像都可能會出問題。如果先發訊息，扣款操作失敗，那麼Smith的賬戶裡面會多出一筆錢。反過來，如果先執行扣款操作，後傳送訊息，那有可能扣款成功了但是訊息沒發出去，Smith收不到錢。除了上面介紹的通過異常捕獲和回滾的方式外，還有沒有其他的思路呢？

下面以阿里巴巴的RocketMQ中介軟體為例，分析下其設計和實現思路。

RocketMQ第一階段傳送Prepared訊息時，會拿到訊息的地址，第二階段執行本地事物，第三階段通過第一階段拿到的地址去訪問訊息，並修改狀態。細心的讀者可能又發現問題了，如果確認訊息傳送失敗了怎麼辦？RocketMQ會定期掃描訊息叢集中的事物訊息，這時候發現了Prepared訊息，它會向訊息傳送者確認，Bob的錢到底是減了還是沒減呢？如果減了是回滾還是繼續傳送確認訊息呢？RocketMQ會根據傳送端設定的策略來決定是回滾還是繼續傳送確認訊息。這樣就保證了訊息傳送與本地事務同時成功或同時失敗。如下圖：

各大知名的電商平臺和網際網路公司，幾乎都是採用類似的設計思路來實現“最終一致性”的。這種方式適合的業務場景廣泛，而且比較可靠。不過這種方式技術實現的難度比較大。目前主流的開源MQ（ActiveMQ、RabbitMQ、Kafka）均未實現對事務訊息的支援，所以需二次開發或者新造輪子。比較遺憾的是，RocketMQ事務訊息部分的程式碼也並未開源，需要自己去實現。

總結：

閱讀了不少這方面的文章，在此基礎上，總結一下分散式事務一致性的解決方案。分散式系統的事務一致性本身就是一個技術難題，目前沒有一種很簡單很完美的方案能夠應對所有場景。分散式系統的一個難點就是因為“網路通訊的不可靠”，只能通過“確認機制”、“重試機制”、“補償機制”等各方面來解決一些問題。在綜合考慮可用性、效能、實現複雜度等各方面的情況上，比較好的選擇是“非同步確保最終一致性”，只是具體實現方式上有一些差異。

參考：

程立：《大規模SOA系統中的分佈事務處事》