本文由華為微服務(wù)引擎技術(shù)團隊&&ServiceComb社區(qū)授權(quán)發(fā)布。

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

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

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

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

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

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

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

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

Sagas

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

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

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

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

Saga的運行原理

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

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

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

• 子事務(wù)序列 T1, T2, …, Tn得以完成 (最佳情況)
• 或者序列 T1, T2, …, Tj, Cj, …, C2, C1, 0 < j < n, 得以完成

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

• 所有的預(yù)訂都被執(zhí)行成功，如果任何一個失敗，都會被取消
• 如果最后一步付款失敗，所有預(yù)訂也將被取消

Saga的恢復(fù)方式

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

• 向后恢復(fù) 補償所有已完成的事務(wù)，如果任一子事務(wù)失敗
• 向前恢復(fù) 重試失敗的事務(wù)，假設(shè)每個子事務(wù)最終都會成功

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

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

使用Saga的條件

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

• Saga只允許兩個層次的嵌套，頂級的Saga和簡單子事務(wù) [1]
• 在外層，全原子性不能得到滿足。也就是說，sagas可能會看到其他sagas的部分結(jié)果 [1]
• 每個子事務(wù)應(yīng)該是獨立的原子行為 [2]
  在我們的業(yè)務(wù)場景下，航班預(yù)訂、租車、酒店預(yù)訂和付款是自然獨立的行為，而且每個事務(wù)都可以用對應(yīng)服務(wù)的數(shù)據(jù)庫保證原子操作。

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

補償也有需考慮的事項：

• 補償事務(wù)從語義角度撤消了事務(wù)Ti的行為，但未必能將數(shù)據(jù)庫返回到執(zhí)行Ti時的狀態(tài)。（例如，如果事務(wù)觸發(fā)導(dǎo)彈發(fā)射， 則可能無法撤消此操作）

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

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

Saga Log

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

• Saga收到事務(wù)請求，但尚未開始。因子事務(wù)對應(yīng)的微服務(wù)狀態(tài)未被Saga修改，我們什么也不需要做。

• 一些子事務(wù)已經(jīng)完成。重啟后，Saga必須接著上次完成的事務(wù)恢復(fù)。

• 子事務(wù)已開始，但尚未完成。由于遠程服務(wù)可能已完成事務(wù)，也可能事務(wù)失敗，甚至服務(wù)請求超時，saga只能重新發(fā)起之前未確認完成的子事務(wù)。這意味著子事務(wù)必須冪等。
• 子事務(wù)失敗，其補償事務(wù)尚未開始。Saga必須在重啟后執(zhí)行對應(yīng)補償事務(wù)。
• 補償事務(wù)已開始但尚未完成。解決方案與上一個相同。這意味著補償事務(wù)也必須是冪等的。
• 所有子事務(wù)或補償事務(wù)均已完成，與第一種情況相同。

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

• Saga started event 保存整個saga請求，其中包括多個事務(wù)/補償請求
• Transaction started event 保存對應(yīng)事務(wù)請求
• Transaction ended event 保存對應(yīng)事務(wù)請求及其回復(fù)
• Transaction aborted event 保存對應(yīng)事務(wù)請求和失敗的原因
• Transaction compensated event 保存對應(yīng)補償請求及其回復(fù)
• Saga ended event 標志著saga事務(wù)請求的結(jié)束，不需要保存任何內(nèi)容

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

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

Saga請求的數(shù)據(jù)結(jié)構(gòu)

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

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

Parallel Saga

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

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

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

因此，服務(wù)的實現(xiàn)必須保證補償請求執(zhí)行以后，再次收到的對應(yīng)事務(wù)請求無效。 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 架構(gòu)

最后，我們的Saga架構(gòu)如下：

• Saga Execution Component解析請求JSON并構(gòu)建請求圖
• TaskRunner 用任務(wù)隊列確保請求的執(zhí)行順序
• TaskConsumer 處理Saga任務(wù)，將事件寫入saga log，并將請求發(fā)送到遠程服務(wù)

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

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

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

2PC包含兩個階段：

• 投票階段 協(xié)調(diào)器向所有服務(wù)發(fā)起投票請求，服務(wù)回答yes或no。如果有任何服務(wù)回復(fù)no以拒絕或超時，協(xié)調(diào)器則在下一階段發(fā)送中止消息。
  

• 決定階段 如果所有服務(wù)都回復(fù)yes，協(xié)調(diào)器則向服務(wù)發(fā)送commit消息，接著服務(wù)告知事務(wù)完成或失敗。如果任何服務(wù)提交失敗， 協(xié)調(diào)器將啟動額外的步驟以中止該事務(wù)。
  

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

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

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

Try-Confirm/Cancel (TCC)

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

• 嘗試階段 將服務(wù)置于待處理狀態(tài)。例如，收到嘗試請求時，航班預(yù)訂服務(wù)將為客戶預(yù)留一個座位，并在數(shù)據(jù)庫插入客戶預(yù)訂記錄，將記錄設(shè)為預(yù)留狀態(tài)。 如果任何服務(wù)失敗或超時，協(xié)調(diào)器將在下一階段發(fā)送取消請求。
  
• 確認階段 將服務(wù)設(shè)為確認狀態(tài)。確認請求將確認客戶預(yù)訂的座位，這時服務(wù)已可向客戶收取機票費用。數(shù)據(jù)庫中的客戶預(yù)訂記錄也會被更新為確認狀態(tài)。 如果任何服務(wù)無法確認或超時，協(xié)調(diào)器將重試確認請求直到成功，或在重試了一定次數(shù)后采取回退措施，比如人工干預(yù)。
  

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

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

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

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

事件驅(qū)動的架構(gòu)

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

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

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

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

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

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

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

這個Saga系列的文章討論的都是集中式的saga設(shè)計。但saga也可用非集中式的方案來實現(xiàn)。那么非集中式的版本有什么不同？
非集中式saga沒有專職的協(xié)調(diào)器。啟動下一個服務(wù)調(diào)用的服務(wù)就是當前的協(xié)調(diào)器。例如，

• 服務(wù)A收到要求服務(wù)A，B和C之間的數(shù)據(jù)一致性的事務(wù)請求。
• A完成其子事務(wù)，并將請求傳遞給事務(wù)中的下一個服務(wù)，服務(wù)B.
• B完成其子事務(wù)，并將請求傳遞給C，依此類推。
• 如果C處理請求失敗，B有責任啟動補償事務(wù)，并要求A回滾。
  

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

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

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

圖片來源: http://www.slideshare.net/BruceWong3/the-case-for-chaos (s12)

同時，在長活事務(wù)中定位問題也變得更加復(fù)雜，因為服務(wù)日志遍布群集節(jié)點。

Summary

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

References

https://en.wikipedia.org/wiki/Two-phase_commit_protocol
https://cs.nyu.edu/courses/spring03/G22.2631-001/lecture8.pdf
http://courses.cs.vt.edu/~cs5204/fall00/distributedDBMS/duckett/tpcp.html
https://www.infoq.com/presentations/Transactions-HTTP-REST
https://www.nginx.com/blog/event-driven-data-management-microservices/
Original Paper on Sagas by By Hector Garcia-Molina & Kenneth Salem
Original Paper on Sagas by By Hector Garcia-Molina & Kenneth Salem
Gifford, David K and James E Donahue, “Coordinating Independent Atomic Actions”, Proceedings of IEEE COMPCON, San Francisco, CA, February, 1985
Chris Richardson: http://www.chrisrichardson.net/
ServiceComb Saga Project: https://github.com/ServiceComb/saga
ServiceComb官方網(wǎng)站
ServiceComb Github

總結(jié)

以上是生活随笔為你收集整理的ServiceComb中的数据最终一致性方案的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。