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

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

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

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

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

當(dāng)這個(gè)功能上線以后，公司非常滿意，客戶也非常高興。

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

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

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

Sagas

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

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

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

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

Saga的運(yùn)行原理

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

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

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

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

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

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

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

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

Saga的恢復(fù)方式

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

向后恢復(fù) 補(bǔ)償所有已完成的事務(wù)，如果任一子事務(wù)失敗

向前恢復(fù) 重試失敗的事務(wù)，假設(shè)每個(gè)子事務(wù)最終都會(huì)成功

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

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

使用Saga的條件

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

• Saga只允許兩個(gè)層次的嵌套，頂級(jí)的Saga和簡單子事務(wù) [1]

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

  也就是說，sagas可能會(huì)看到其他sagas的部分結(jié)果 [1]

• 每個(gè)子事務(wù)應(yīng)該是獨(dú)立的原子行為 [2]

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

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

補(bǔ)償也有需考慮的事項(xiàng)：

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

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

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

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

Saga Log

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

• Saga收到事務(wù)請(qǐng)求，但尚未開始。

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

• 一些子事務(wù)已經(jīng)完成。

  重啟后，Saga必須接著上次完成的事務(wù)恢復(fù)。

• 子事務(wù)已開始，但尚未完成。

  由于遠(yuǎn)程服務(wù)可能已完成事務(wù)，也可能事務(wù)失敗，甚至服務(wù)請(qǐng)求超時(shí)，saga只能重新發(fā)起之前未確認(rèn)完成的子事務(wù)。

  這意味著子事務(wù)必須冪等。

• 子事務(wù)失敗，其補(bǔ)償事務(wù)尚未開始。

  Saga必須在重啟后執(zhí)行對(duì)應(yīng)補(bǔ)償事務(wù)。

• 補(bǔ)償事務(wù)已開始但尚未完成。

  解決方案與上一個(gè)相同。

  這意味著補(bǔ)償事務(wù)也必須是冪等的。

• 所有子事務(wù)或補(bǔ)償事務(wù)均已完成，與第一種情況相同。

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

• Saga started event 保存整個(gè)saga請(qǐng)求，其中包括多個(gè)事務(wù)/補(bǔ)償請(qǐng)求

• Transaction started event 保存對(duì)應(yīng)事務(wù)請(qǐng)求

• Transaction ended event 保存對(duì)應(yīng)事務(wù)請(qǐng)求及其回復(fù)

• Transaction aborted event 保存對(duì)應(yīng)事務(wù)請(qǐng)求和失敗的原因

• Transaction compensated event 保存對(duì)應(yīng)補(bǔ)償請(qǐng)求及其回復(fù)

• Saga ended event 標(biāo)志著saga事務(wù)請(qǐng)求的結(jié)束，不需要保存任何內(nèi)容

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

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

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

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

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

Parallel Saga

如上所述，航班預(yù)訂，租車和酒店預(yù)訂可以并行處理。但是這樣做會(huì)造成另一個(gè)問題：如果航班預(yù)訂失敗，而租車正在處理怎么辦？我們不能一直等待租車服務(wù)回應(yīng)， 因?yàn)椴恢佬枰榷嗑谩?

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

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

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

ACID and Saga

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

• 原子性（Atomicity）

• 一致性（Consistency）

• 隔離性（Isolation）

• 持久性（Durability）

Saga不提供ACID保證，因?yàn)樵有院透綦x性不能得到滿足。原論文描述如下：

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解析請(qǐng)求JSON并構(gòu)建請(qǐng)求圖

• TaskRunner 用任務(wù)隊(duì)列確保請(qǐng)求的執(zhí)行順序

• TaskConsumer 處理Saga任務(wù)，將事件寫入saga log，并將請(qǐng)求發(fā)送到遠(yuǎn)程服務(wù)

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

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

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

2PC包含兩個(gè)階段：

• 投票階段 協(xié)調(diào)器向所有服務(wù)發(fā)起投票請(qǐng)求，服務(wù)回答yes或no。

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

  
  

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

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

  
  

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

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

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

Try-Confirm/Cancel (TCC)

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

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

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

  如果任何服務(wù)失敗或超時(shí)，協(xié)調(diào)器將在下一階段發(fā)送取消請(qǐng)求。

  
  

• 確認(rèn)階段 將服務(wù)設(shè)為確認(rèn)狀態(tài)。

  確認(rèn)請(qǐng)求將確認(rèn)客戶預(yù)訂的座位，這時(shí)服務(wù)已可向客戶收取機(jī)票費(fèi)用。

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

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

  
  

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

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

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

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

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

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

因?yàn)樵诓迦胗涗浐蠓?wù)可能崩潰，我們無法確定是否新事件已發(fā)送，所以每個(gè)服務(wù)還需要額外的事件表來跟蹤當(dāng)前長活事務(wù)處于哪一步。

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

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

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

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

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

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

非集中式saga沒有專職的協(xié)調(diào)器。啟動(dòng)下一個(gè)服務(wù)調(diào)用的服務(wù)就是當(dāng)前的協(xié)調(diào)器。例如，

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

• A完成其子事務(wù)，并將請(qǐng)求傳遞給事務(wù)中的下一個(gè)服務(wù)，服務(wù)B.

• B完成其子事務(wù)，并將請(qǐng)求傳遞給C，依此類推。

• 如果C處理請(qǐng)求失敗，B有責(zé)任啟動(dòng)補(bǔ)償事務(wù)，并要求A回滾。

  
  

與集中式相比，非集中式的實(shí)現(xiàn)具有服務(wù)自治的優(yōu)勢。但每個(gè)服務(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è)計(jì)。

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

Summary

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

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