數(shù)據(jù)一致性是構建業(yè)務系統(tǒng)需要考慮的重要問題 ， 以往我們是依靠數(shù)據(jù)庫來保證數(shù)據(jù)的一致性。但是在微服務架構以及分布式環(huán)境下實現(xiàn)數(shù)據(jù)一致性是一個很有挑戰(zhàn)的的問題。ServiceComb作為開源的微服務框架致力解決微服務開發(fā)過程中的問題。我們最近發(fā)起的ServiceComb-Saga項目來解決分布式環(huán)境下的數(shù)據(jù)最終一致性問題。本文將向大家介紹為什么數(shù)據(jù)一致性如此重要？Saga又是什么？

單體應用的數(shù)據(jù)一致性

想象一下如果我們經營著一家大型企業(yè)，下屬有航空公司、租車公司、和連鎖酒店。我們?yōu)榭蛻籼峁┮徽臼降穆糜涡谐桃?guī)劃服務，這樣客戶只需要提供出行目的地， 我們幫助客戶預訂機票、租車、以及預訂酒店。從業(yè)務的角度，我們必須保證上述三個服務的預訂都完成才能滿足一個成功的旅游行程，否則不能成行。

我們的單體應用要滿足這個需求非常簡單，只需將這個三個服務請求放到同一個數(shù)據(jù)庫事務中，數(shù)據(jù)庫會幫我們保證全部成功或者全部回滾。

當這個功能上線以后，公司非常滿意，客戶也非常高興。

微服務場景下的數(shù)據(jù)一致性

這幾年中，我們的行程規(guī)劃服務非常成功，企業(yè)蒸蒸日上，用戶量也翻了數(shù)十倍。企業(yè)的下屬航空公司、租車公司、和連鎖酒店也相繼推出了更多服務以滿足客戶需求， 我們的應用和開發(fā)團隊也因此日漸龐大。如今我們的單體應用已變得如此復雜，以至于沒人了解整個應用是怎么運作的。更糟的是新功能的上線現(xiàn)在需要所有研發(fā)團隊合作， 日夜奮戰(zhàn)數(shù)周才能完成?？粗袌稣加新拭繘r愈下，公司高層對研發(fā)部門越來越不滿意。

經過數(shù)輪討論，我們最終決定將龐大的單體應用一分為四：機票預訂服務、租車服務、酒店預訂服務、和支付服務。服務各自使用自己的數(shù)據(jù)庫，并通過HTTP協(xié)議通信。負責各服務的團隊根據(jù)市場需求按照自己的開發(fā)節(jié)奏發(fā)版上線。如今我們面臨新的挑戰(zhàn)：如何保證最初三個服務的預訂都完成才能滿足一個成功的旅游行程， 否則不能成行的業(yè)務規(guī)則？現(xiàn)在服務有各自的邊界，而且數(shù)據(jù)庫選型也不盡相同，通過數(shù)據(jù)庫保證數(shù)據(jù)一致性的方案已不可行。

Sagas

幸運的是我們在互聯(lián)網(wǎng)找到一篇精彩的論文，文中提出的數(shù)據(jù)一致性解決方案Saga恰好滿足我們的業(yè)務要求。

Saga是一個長活事務，可被分解成可以交錯運行的子事務集合。其中每個子事務都是一個保持數(shù)據(jù)庫一致性的真實事務。

在我們的業(yè)務場景下，一個行程規(guī)劃的事務就是一個Saga，其中包含四個子事務：機票預訂、租車、酒店預訂、和支付。

Chris Richardson在他的文章Pattern: Saga中對Saga有所描述。Caitie McCaffrey也在她的演講中提到如何在微軟的光暈 4游戲中如何應用saga解決數(shù)據(jù)一致性問題。

Saga的運行原理

Saga中的事務相互關聯(lián)，應作為（非原子）單位執(zhí)行。任何未完全執(zhí)行的Saga是不滿足要求的，如果發(fā)生，必須得到補償。要修正未完全執(zhí)行的部分， 每個saga子交易T1應提供對應補償事務C1

我們根據(jù)上述規(guī)則定義以下事務及其相應的事務補償：

當每個saga子事務 T1, T2, …, Tn 都有對應的補償定義 C1, C2, …, Cn-1, 那么saga系統(tǒng)可以保證 [1]

• 子事務序列 T1, T2, …, Tn得以完成 (最佳情況)

• 或者序列 T1, T2, …, Tj, Cj, …, C2, C1, 0 < j < n, 得以完成

換句話說，通過上述定義的事務/補償，saga保證滿足以下業(yè)務規(guī)則：

• 所有的預訂都被執(zhí)行成功，如果任何一個失敗，都會被取消

• 如果最后一步付款失敗，所有預訂也將被取消

Saga的恢復方式

原論文中描述了兩種類型的Saga恢復方式：

向后恢復 補償所有已完成的事務，如果任一子事務失敗

向前恢復 重試失敗的事務，假設每個子事務最終都會成功

顯然，向前恢復沒有必要提供補償事務，如果你的業(yè)務中，子事務（最終）總會成功，或補償事務難以定義或不可能，向前恢復更符合你的需求。

理論上補償事務永不失敗，然而，在分布式世界中，服務器可能會宕機，網(wǎng)絡可能會失敗，甚至數(shù)據(jù)中心也可能會停電。在這種情況下我們能做些什么？最后的手段是提供回退措施，比如人工干預。

使用Saga的條件

Saga看起來很有希望滿足我們的需求。所有長活事務都可以這樣做嗎？這里有一些限制：

• Saga只允許兩個層次的嵌套，頂級的Saga和簡單子事務 [1]

• 在外層，全原子性不能得到滿足。

  也就是說，sagas可能會看到其他sagas的部分結果 [1]

• 每個子事務應該是獨立的原子行為 [2]

• 在我們的業(yè)務場景下，航班預訂、租車、酒店預訂和付款是自然獨立的行為，而且每個事務都可以用對應服務的數(shù)據(jù)庫保證原子操作。

我們在行程規(guī)劃事務層面也不需要原子性。一個用戶可以預訂最后一張機票，而后由于信用卡余額不足而被取消。同時另一個用戶可能開始會看到已無余票， 接著由于前者預訂被取消，最后一張機票被釋放，而搶到最后一個座位并完成行程規(guī)劃。

補償也有需考慮的事項：

• 補償事務從語義角度撤消了事務Ti的行為，但未必能將數(shù)據(jù)庫返回到執(zhí)行Ti時的狀態(tài)。

  （例如，如果事務觸發(fā)導彈發(fā)射， 則可能無法撤消此操作）

但這對我們的業(yè)務來說不是問題。其實難以撤消的行為也有可能被補償。例如，發(fā)送電郵的事務可以通過發(fā)送解釋問題的另一封電郵來補償。

現(xiàn)在我們有了通過Saga來解決數(shù)據(jù)一致性問題的方案。它允許我們成功地執(zhí)行所有事務，或在任何事務失敗的情況下，補償已成功的事務。雖然Saga不提供ACID保證，但仍適用于許多數(shù)據(jù)最終一致性的場景。那我們如何設計一個Saga系統(tǒng)？

Saga Log

Saga保證所有的子事務都得以完成或補償，但Saga系統(tǒng)本身也可能會崩潰。Saga崩潰時可能處于以下幾個狀態(tài)：

• Saga收到事務請求，但尚未開始。

  因子事務對應的微服務狀態(tài)未被Saga修改，我們什么也不需要做。

• 一些子事務已經完成。

  重啟后，Saga必須接著上次完成的事務恢復。

• 子事務已開始，但尚未完成。

  由于遠程服務可能已完成事務，也可能事務失敗，甚至服務請求超時，saga只能重新發(fā)起之前未確認完成的子事務。

  這意味著子事務必須冪等。

• 子事務失敗，其補償事務尚未開始。

  Saga必須在重啟后執(zhí)行對應補償事務。

• 補償事務已開始但尚未完成。

  解決方案與上一個相同。

  這意味著補償事務也必須是冪等的。

• 所有子事務或補償事務均已完成，與第一種情況相同。

為了恢復到上述狀態(tài)，我們必須追蹤子事務及補償事務的每一步。我們決定通過事件的方式達到以上要求，并將以下事件保存在名為saga log的持久存儲中：

• Saga started event 保存整個saga請求，其中包括多個事務/補償請求

• Transaction started event 保存對應事務請求

• Transaction ended event 保存對應事務請求及其回復

• Transaction aborted event 保存對應事務請求和失敗的原因

• Transaction compensated event 保存對應補償請求及其回復

• Saga ended event 標志著saga事務請求的結束，不需要保存任何內容

通過將這些事件持久化在saga log中，我們可以將saga恢復到上述任何狀態(tài)。

由于Saga只需要做事件的持久化，而事件內容以JSON的形式存儲，Saga log的實現(xiàn)非常靈活，數(shù)據(jù)庫（SQL或NoSQL），持久消息隊列，甚至普通文件可以用作事件存儲， 當然有些能更快得幫saga恢復狀態(tài)。

Saga請求的數(shù)據(jù)結構

在我們的業(yè)務場景下，航班預訂、租車、和酒店預訂沒有依賴關系，可以并行處理，但對于我們的客戶來說，只在所有預訂成功后一次付費更加友好。那么這四個服務的事務關系可以用下圖表示：

將行程規(guī)劃請求的數(shù)據(jù)結構實現(xiàn)為有向非循環(huán)圖恰好合適。圖的根是saga啟動任務，葉是saga結束任務。

Parallel Saga

如上所述，航班預訂，租車和酒店預訂可以并行處理。但是這樣做會造成另一個問題：如果航班預訂失敗，而租車正在處理怎么辦？我們不能一直等待租車服務回應， 因為不知道需要等多久。

最好的辦法是再次發(fā)送租車請求，獲得回應，以便我們能夠繼續(xù)補償操作。但如果租車服務永不回應，我們可能需要采取回退措施，比如手動干預。

超時的預訂請求可能最后仍被租車服務收到，這時服務已經處理了相同的預訂和取消請求。

因此，服務的實現(xiàn)必須保證補償請求執(zhí)行以后，再次收到的對應事務請求無效。Caitie McCaffrey在她的演講Distributed Sagas: A Protocol for Coordinating Microservices中把這個稱為可交換的補償請求 (commutative compensating request)。

ACID and Saga

ACID是具有以下屬性的一致性模型:

• 原子性（Atomicity）

• 一致性（Consistency）

• 隔離性（Isolation）

• 持久性（Durability）

Saga不提供ACID保證，因為原子性和隔離性不能得到滿足。原論文描述如下：

full atomicity is not provided. That is, sagas may view the partial results of other sagas [1]

通過saga log，saga可以保證一致性和持久性。

Saga 架構

最后，我們的Saga架構如下：

• Saga Execution Component解析請求JSON并構建請求圖

• TaskRunner 用任務隊列確保請求的執(zhí)行順序

• TaskConsumer 處理Saga任務，將事件寫入saga log，并將請求發(fā)送到遠程服務

在上文中，我談到了ServiceComb下的Saga是怎么設計的。然而，業(yè)界還有其他數(shù)據(jù)一致性解決方案，如兩階段提交（2PC）和Try-Confirm / Cancel（TCC）。那saga相比之下有什么特別？

兩階段提交 Two-Phase Commit (2PC)

兩階段提交協(xié)議是一種分布式算法，用于協(xié)調參與分布式原子事務的所有進程，以保證他們均完成提交或中止（回滾）事務。

2PC包含兩個階段：

• 投票階段 協(xié)調器向所有服務發(fā)起投票請求，服務回答yes或no。

  如果有任何服務回復no以拒絕或超時，協(xié)調器則在下一階段發(fā)送中止消息。

  
  

• 決定階段 如果所有服務都回復yes，協(xié)調器則向服務發(fā)送commit消息，接著服務告知事務完成或失敗。

  如果任何服務提交失敗， 協(xié)調器將啟動額外的步驟以中止該事務。

  
  

在投票階段結束之后與決策階段結束之前，服務處于不確定狀態(tài)，因為他們不確定交易是否繼續(xù)進行。當服務處于不確定狀態(tài)并與協(xié)調器失去連接時， 它只能選擇等待協(xié)調器的恢復，或者咨詢其他在確定狀態(tài)下的服務來得知協(xié)調器的決定。在最壞的情況下， n個處于不確定狀態(tài)的服務向其他n-1個服務咨詢將產生O(n2)個消息。

另外，2PC是一個阻塞協(xié)議。服務在投票后需要等待協(xié)調器的決定，此時服務會阻塞并鎖定資源。由于其阻塞機制和最差時間復雜度高， 2PC不能適應隨著事務涉及的服務數(shù)量增加而擴展的需要。

有關2PC實現(xiàn)的更多細節(jié)可參考2和3。

Try-Confirm/Cancel (TCC)

TCC也是補償型事務模式，支持兩階段的商業(yè)模型。

• 嘗試階段 將服務置于待處理狀態(tài)。

  例如，收到嘗試請求時，航班預訂服務將為客戶預留一個座位，并在數(shù)據(jù)庫插入客戶預訂記錄，將記錄設為預留狀態(tài)。

  如果任何服務失敗或超時，協(xié)調器將在下一階段發(fā)送取消請求。

  
  

• 確認階段 將服務設為確認狀態(tài)。

  確認請求將確認客戶預訂的座位，這時服務已可向客戶收取機票費用。

  數(shù)據(jù)庫中的客戶預訂記錄也會被更新為確認狀態(tài)。

  如果任何服務無法確認或超時，協(xié)調器將重試確認請求直到成功，或在重試了一定次數(shù)后采取回退措施，比如人工干預。

  
  

與saga相比，TCC的優(yōu)勢在于，嘗試階段將服務轉為待處理狀態(tài)而不是最終狀態(tài)，這使得設計相應的取消操作輕而易舉。

例如，電郵服務的嘗試請求可將郵件標記為準備發(fā)送，并且僅在確認后發(fā)送郵件，其相應的取消請求只需將郵件標記為已廢棄。但如果使用saga， 事務將發(fā)送電子郵件，及其相應的補償事務可能需要發(fā)送另一封電子郵件作出解釋。

TCC的缺點是其兩階段協(xié)議需要設計額外的服務待處理狀態(tài)，以及額外的接口來處理嘗試請求。另外，TCC處理事務請求所花費的時間可能是saga的兩倍， 因為TCC需要與每個服務進行兩次通信，并且其確認階段只能在收到所有服務對嘗試請求的響應后開始。

有關TCC的更多細節(jié)可參考Transactions for the REST of Us.

事件驅動的架構

和TCC一樣，在事件驅動的架構中，長活事務涉及的每個服務都需要支持額外的待處理狀態(tài)。接收到事務請求的服務會在其數(shù)據(jù)庫中插入一條新的記錄， 將該記錄狀態(tài)設為待處理并發(fā)送一個新的事件給事務序列中的下一個服務。

因為在插入記錄后服務可能崩潰，我們無法確定是否新事件已發(fā)送，所以每個服務還需要額外的事件表來跟蹤當前長活事務處于哪一步。

一旦長活事務中的最后一個服務完成其子事務，它將通知它在事務中的前一個服務。接收到完成事件的服務將其在數(shù)據(jù)庫中的記錄狀態(tài)設為完成。

如果仔細比較，事件驅動的架構就像非集中式的基于事件的TCC實現(xiàn)。如果去掉待處理狀態(tài)而直接把服務記錄設為最終狀態(tài)，這個架構就像非集中式的基于事件的saga實現(xiàn)。去中心化能達到服務自治，但也造成了服務之間更緊密的的耦合。假設新的業(yè)務需求在服務B和C之間的增加了新的流程D。在事件驅動架構下，服務B和C必須改動代碼以適應新的流程D。

Saga則正好相反，所有這些耦合都在saga系統(tǒng)中，當在長活事務中添加新流程時，現(xiàn)有服務不需要任何改動。

更多細節(jié)可參考Event-Driven Data Management for Microservices.

集中式與非集中式實現(xiàn)

這個Saga系列的文章討論的都是集中式的saga設計。但saga也可用非集中式的方案來實現(xiàn)。那么非集中式的版本有什么不同？

非集中式saga沒有專職的協(xié)調器。啟動下一個服務調用的服務就是當前的協(xié)調器。例如，

• 服務A收到要求服務A，B和C之間的數(shù)據(jù)一致性的事務請求。

• A完成其子事務，并將請求傳遞給事務中的下一個服務，服務B.

• B完成其子事務，并將請求傳遞給C，依此類推。

• 如果C處理請求失敗，B有責任啟動補償事務，并要求A回滾。

  
  

與集中式相比，非集中式的實現(xiàn)具有服務自治的優(yōu)勢。但每個服務都需要包含數(shù)據(jù)一致性協(xié)議，并提供其所需的額外持久化設施。

我們更傾向于自治的業(yè)務服務，但服務還關聯(lián)很多應用的復雜性，如數(shù)據(jù)一致性，服務監(jiān)控和消息傳遞， 將這些棘手問題集中處理，能將業(yè)務服務從應用的復雜性中釋放，專注于處理復雜的業(yè)務，因此我們采用了集中式的saga設計。

另外，隨著長活事務中涉及的服務數(shù)量增長，服務之間的關系變得越來越難理解，很快便會呈現(xiàn)下圖的死星形狀。

Summary

本文將saga與其他數(shù)據(jù)一致性解決方案進行了比較。Saga比兩階段提交更易擴展。在事務可補償?shù)那闆r下， 相比TCC，saga對業(yè)務邏輯幾乎沒有改動的需要，而且性能更高。集中式的saga設計解耦了服務與數(shù)據(jù)一致性邏輯及其持久化設施， 并使排查事務中的問題更容易。

免責聲明：本文內容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！