傳統應用使用本地事務和分佈式事務保證數據一致性，但是在微服務架構中數據都是服務私有的，需要通過服務提供的API來訪問，所以分佈式事務不再適用微服務架構。那麼微服務架構又該如何保證數據一致性呢？本文就來談談這個話題。
-
傳統分佈式事務不是微服務中數據一致性的最佳選擇
-
微服務架構中應滿足數據最終一致性原則
-
微服務架構實現最終一致性的三種模式
-
對賬是最後的終極防線
傳統分佈式事務
我們先來看下第一部分，傳統使用本地事務和分佈式事務保證一致性。
傳統單機應用一般都會使用一個關係型數據庫，好處是應用可以使用ACID。爲保證一致性我們只需要：開始一個事務，改變（插入，刪除，更新）很多行，然後提交事務（如果有異常時回滾事務）。更進一步，藉助開發平臺中的數據訪問技術和框架（如 spring），我們需要做的事情更少，只需要關注數據本身的改變。
隨着組織規模不斷擴大，業務量不斷增長，單機應用和數據庫已經不足以支持龐大的業務量和數據量，這個時候需要對應用和數據庫進行拆分，這就出現了一個應用需要同時訪問兩個或兩個以上的數據庫情況。開始我們用分佈式事務來保證一致性，也就是我們常說的兩階段提交協議（2PC）。
本地事務和分佈式事務現在已經非常成熟，相關介紹很豐富，此處不再討論。我們下面來談談爲什麼分佈式事務不適用於微服務架構。
首先，對於微服務架構來說，數據訪問變得更加複雜，這是因爲數據都是微服務私有的，唯一可訪問的方式就是通過 API。這種打包數據訪問方式使得微服務之間鬆耦合，並且彼此之間獨立，更容易進行性能擴展。
其次，不同的微服務經常使用不同的數據庫。應用會產生各種不同類型的數據，關係型數據庫並不一定是最佳選擇。
例如，某個產生和查詢字符串的應用採用 Elasticsearch 的字符搜索引擎；某個產生社交圖片數據的應用可以採用圖數據庫，例如Neo4j。
基於微服務的應用一般都使用 SQL 和 NoSQL 結合的模式。但是這些非關係型數據大多數並不支持 2PC。
可見在微服務架構中已經不能選擇分佈式事務了。
最終一致性原則
依據 CAP 理論，必須在可用性（availability）和一致性（consistency）之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他併發訪問的代價。這可能持續一個不確定的時間，尤其是在系統已經表現出高延遲時或者網絡故障導致失去連接時。
依據目前的成功經驗，可用性一般是更好的選擇，但是在服務和數據庫之間維護數據一致性是非常根本的需求，微服務架構中應選擇滿足最終一致性。
最終一致性是指系統中的所有數據副本經過一定時間後，最終能夠達到一致的狀態。
當然選擇了最終一致性，就要保證到最終的這段時間要在用戶可接受的範圍之內。那麼我們怎麼實現最終一致性呢？
從一致性的本質來看，是要保證在一個業務邏輯中包含的服務要麼都成功，要麼都失敗。那我們怎麼選擇方向呢？保證成功還是保證失敗呢？
我們說業務模式決定了我們的選擇。實現最終一致性有三種模式：可靠事件模式、業務補償模式、TCC 模式。
可靠事件模式
可靠事件模式屬於事件驅動架構，當某件重要事情發生時，例如更新一個業務實體，微服務會向消息代理髮佈一個事件。消息代理會向訂閱事件的微服務推送事件，當訂閱這些事件的微服務接收此事件時，就可以完成自己的業務，也可能會引發更多的事件發佈。
1. 如訂單服務創建一個待支付的訂單，發佈一個“創建訂單”的事件。
2. 支付服務消費“創建訂單”事件，支付完成後發佈一個“支付完成”事件。
3. 訂單服務消費“支付完成”事件，訂單狀態更新爲待出庫。
從而就實現了完成的業務流程。但是這並不是一個完美的流程。
這個過程可能導致出現不一致的地方在於：某個微服務在更新了業務實體後發佈事件卻失敗；雖然微服務發佈事件成功，但是消息代理未能正確推送事件到訂閱的微服務；接受事件的微服務重複消費了事件。
可靠事件模式在於保證可靠事件投遞和避免重複消費，可靠事件投遞定義爲：
-
每個服務原子性的業務操作和發佈事件。
-
消息代理確保事件傳遞至少一次。
避免重複消費要求服務實現冪等性，如支付服務不能因爲重複收到事件而多次支付。
因爲現在流行的消息隊列都實現了事件的持久化和 at least once 的投遞模式，『消息代理確保事件投遞至少一次』已經滿足，今天不做展開。
下面分享的內容主要從可靠事件投遞和實現冪等性兩方面來討論，我們先來看可靠事件投遞。
首先我們來看一個實現的代碼片段，這是從某生產系統上截取下來的。
根據上述代碼及註釋，初看可能出現 3 種情況：
-
操作數據庫成功，向消息代理投遞事件也成功。
-
操作數據庫失敗，不會向消息代理中投遞事件了。
-
操作數據庫成功，但是向消息代理中投遞事件時失敗，向外拋出了異常，剛剛執行的更新數據庫的操作將被回滾。
從上面分析的幾種情況來看，貌似沒有問題。但是仔細分析不難發現缺陷所在，在上面的處理過程中存在一段隱患時間窗口。
-
微服務 A 投遞事件的時候可能消息代理已經處理成功，但是返回響應的時候網絡異常，導致 append 操作拋出異常。最終結果是事件被投遞，數據庫卻被回滾。
![]()
-
在投遞完成後到數據庫 commit 操作之間如果微服務 A 宕機也將造成數據庫操作因爲連接異常關閉而被回滾。最終結果還是事件被投遞，數據庫卻被回滾。這個實現往往運行很長時間都沒有出過問題，但是一旦出現了將會讓人感覺莫名，很難發現問題所在。
下面給出兩種可靠事件投遞的實現方式。
1. 本地事件表
本地事件表方法將事件和業務數據保存在同一個數據庫中，使用一個額外的“事件恢復”服務來恢復事件，由本地事務保證更新業務和發佈事件的原子性。考慮到事件恢復可能會有一定的延時，服務在完成本地事務後可立即向消息代理髮佈一個事件。
-
微服務在同一個本地事務中記錄業務數據和事件。
-
微服務實時發佈一個事件立即通知關聯的業務服務，如果事件發佈成功立即刪除記錄的事件。
-
事件恢復服務定時從事件表中恢復未發佈成功的事件，重新發布，重新發布成功才刪除記錄的事件。
其中第Ⅱ條的操作主要是爲了增加發布事件的實時性，由第三條保證事件一定被髮布。
本地事件表方式業務系統和事件系統耦合比較緊密，額外的事件數據庫操作也會給數據庫帶來額外的壓力，可能成爲瓶頸。
2. 外部事件表
外部事件表方法將事件持久化到外部的事件系統，事件系統需提供實時事件服務以接受微服務發佈事件，同時事件系統還需要提供事件恢復服務來確認和恢復事件。
-
業務服務在事務提交前，通過實時事件服務向事件系統請求發送事件，事件系統只記錄事件並不真正發送。
-
業務服務在提交後，通過實時事件服務向事件系統確認發送，事件得到確認後事件系統才真正發佈事件到消息代理。
-
業務服務在業務回滾時，通過實時事件向事件系統取消事件。
-
如果業務服務在發送確認或取消之前停止服務了怎麼辦呢？事件系統的事件恢復服務會定期找到未確認發送的事件向業務服務查詢狀態，根據業務服務返回的狀態決定事件是要發佈還是取消。
該方式將業務系統和事件系統獨立解耦，都可以獨立伸縮。但是這種方式需要一次額外的發送操作，並且需要發佈者提供額外的查詢接口。
介紹完了可靠事件投遞再來說一說冪等性的實現，有些事件本身是冪等的，有些事件卻不是。
本身具有冪等性的事件需要考慮執行順序
如果事件本身描述的是某個時間點的固定值（如賬戶餘額爲 100），而不是描述一條轉換指令（如餘額增加 10），那麼這個事件是冪等的。
我們要意識到事件可能出現的次數和順序是不可預測的，需要保證冪等事件的順序執行，否則結果往往不是我們想要的。
如果我們先後收到兩條事件，（1）賬戶餘額更新爲100，（2）賬戶餘額更新爲120。
1. 微服務收到事件（1）
2. 微服務收到事件（2）
3. 微服務再次收到事件（1）
顯然結果是錯誤的，所以我們需要保證事件（2）一旦執行事件（1）就不能再處理，否則賬戶餘額仍不是我們想要的結果。
爲保證事件的順序一個簡單的做法是在事件中添加時間戳，微服務記錄每類型的事件最後處理的時間戳，如果收到的事件的時間戳早於我們記錄的，丟棄該事件。如果事件不是在同一個服務器上發出的，那麼服務器之間的時間同步是個難題，更穩妥的做法是使用一個全局遞增序列號替換時間戳。
對於本身不具有冪等性的操作，主要思想是爲每條事件存儲執行結果，當收到一條事件時我們需要根據事件的 ID 查詢該事件是否已經執行過，如果執行過直接返回上一次的執行結果，否則調度執行事件。
在這個思想下我們需要考慮重複執行一條事件和查詢存儲結果的開銷。
重複處理開銷小的事件
如果重複處理一條事件開銷很小，或者可預見只有非常少的事件會被重複接收，可以選擇重複處理一次事件，在將事件數據持久化時由數據庫拋出唯一性約束異常。
重複處理開銷大事件使用事件存儲過濾重複事件
如果重複處理一條事件的開銷相比額外一次查詢的開銷要高很多，使用一個過濾服務來過濾重複的事件，過濾服務使用事件存儲存儲已經處理過的事件和結果。
當收到一條事件時，過濾服務首先查詢事件存儲，確定該條事件是否已經被處理過，如果事件已經被處理過，直接返回存儲的結果；否則調度業務服務執行處理，並將處理完的結果存儲到事件存儲中。
一般情況下上面的方法能夠運行得很好，如果我們的微服務是 RPC 類的服務我們需要更加小心，可能出現的問題在於，（1）過濾服務在業務處理完成後纔將事件結果存儲到事件存儲中，但是在業務處理完成前有可能就已經收到重複事件，由於是 RPC 服務也不能依賴數據庫的唯一性約束；（2）業務服務的處理結果可能出現位置狀態，一般出現在正常提交請求但是沒有收到響應的時候。
對於問題（1）可以按步驟記錄事件處理過程，比如事件的記錄事件的處理過程爲“接收”、“發送請求”、“收到應答”、“處理完成”。好處是過濾服務能及時的發現重複事件，進一步還能根據事件狀態作不同的處理。
對於問題（2）可以通過一次額外的查詢請求來確定事件的實際處理狀態，要注意額外的查詢會帶來更長時間的延時，更進一步可能某些 RPC 服務根本不提供查詢接口。此時只能選擇接收暫時的不一致，時候採用對賬和人工接入的方式來保證一致性。
補償模式
爲了描述方便，這裏先定義兩個概念：
-
業務異常：業務邏輯產生錯誤的情況，比如賬戶餘額不足、商品庫存不足等。
-
技術異常：非業務邏輯產生的異常，如網絡連接異常、網絡超時等。
補償模式使用一個額外的協調服務來協調各個需要保證一致性的微服務，協調服務按順序調用各個微服務，如果某個微服務調用異常（包括業務異常和技術異常）就取消之前所有已經調用成功的微服務。
補償模式建議僅用於不能避免出現業務異常的情況，如果有可能應該優化業務模式，以避免要求補償事務。如賬戶餘額不足的業務異常可通過預先凍結金額的方式避免，商品庫存不足可要求商家準備額外的庫存等。
我們通過一個實例來說明補償模式，一家旅行公司提供預訂行程的業務，可以通過公司的網站提前預訂飛機票、火車票、酒店等。
假設一位客戶規劃的行程是:
-
上海-北京6月19日9點的某某航班。
-
某某酒店住宿3晚。
-
北京-上海6月22日17點火車。
在客戶提交行程後，旅行公司的預訂行程業務按順序串行的調用航班預訂服務、酒店預訂服務、火車預訂服務。最後的火車預訂服務成功後整個預訂業務纔算完成。
如果火車票預訂服務沒有調用成功，那麼之前預訂的航班、酒店都得取消。取消之前預訂的酒店、航班即爲補償過程。
爲了降低開發的複雜性和提高效率，協調服務實現爲一個通用的補償框架。補償框架提供服務編排和自動完成補償的能力。
要實現補償過程，我們需要做到兩點：
首先要確定失敗的步驟和狀態，從而確定需要補償的範圍。
在上面的例子中我們不僅要知道第 3 個步驟（預訂火車）失敗，還要知道失敗的原因。如果是因爲預訂火車服務返回無票，那麼補償過程只需要取消前兩個步驟就可以了；但是如果失敗的原因是因爲網絡超時，那麼補償過程除前兩個步驟之外還需要包括第 3 個步驟。
其次要能提供補償操作使用到的業務數據。
比如一個支付微服務的補償操作要求參數包括支付時的業務流水 id、賬號和金額。理論上說實際完成補償操作可以根據唯一的業務流水 id 就可以，但是提供更多的要素有益於微服務的健壯性，微服務在收到補償操作的時候可以做業務的檢查，比如檢查賬戶是否相等，金額是否一致等等。
做到上面兩點的辦法是記錄完整的業務流水，可以通過業務流水的狀態來確定需要補償的步驟，同時業務流水爲補償操作提供需要的業務數據。
當客戶的一個預訂請求達到時，協調服務（補償框架）爲請求生成一個全局唯一的業務流水號，並在調用各個工作服務的同時記錄完整的狀態。
-
記錄調用 bookFlight 的業務流水，調用 bookFlight 服務，更新業務流水狀態。
-
記錄調用 bookHotel 的業務流水，調用 bookHotel 服務，更新業務流水狀態。
-
記錄調用 bookTrain 的業務流水，調用 bookTrain 服務，更新業務流水狀態。
當調用某個服務出現異常時，比如第 3 步驟（預訂火車）異常。
協調服務（補償框架）同樣會記錄第 3 步的狀態，同時會另外記錄一條事件，說明業務出現了異常。然後就是執行補償過程了，可以從業務流水的狀態中知道補償的範圍，補償過程中需要的業務數據從記錄的業務流水中獲取。
對於一個通用的補償框架來說，預先知道微服務需要記錄的業務要素是不可能的。那麼就需要一種方法來保證業務流水的可擴展性，這裏介紹兩種方法：大表和關聯表。
大表顧明思議就是設計時除必須的字段外，還需要預留大量的備用字段，框架可以提供輔助工具來幫助將業務數據映射到備用字段中。
關聯表，分爲框架表和業務表，技術表中保存爲實現補償操作所需要的技術數據，業務表保存業務數據，通過在技術表中增加業務表名和業務表主鍵來建立和業務數據的關聯。
大表對於框架層實現起來簡單，但是也有一些難點，比如預留多少字段合適，每個字段又需要預留多少長度。另外一個難點是如果向從數據層面來查詢數據，很難看出備用字段的業務含義，維護過程不友好。
關聯表在業務要素上更靈活，能支持不同的業務類型記錄不同的業務要素；但是對於框架實現上難度更高，另外每次查詢都需要複雜的關聯動作，性能方面會受影響。
有了上面的完整的流水記錄，協調服務就可以根據工作服務的狀態在異常時完成補償過程。但是補償由於網絡等原因，補償操作並不一定能保證 100%成功，這時候我們還要做更多一點。
補償過程作爲一個服務調用過程同樣存在調用不成功的情況，這個時候需要通過重試的機制來保證補償的成功率。當然這也就要求補償操作本身具備冪等性。
關於冪等性的實現在前面做過討論。
如果只是一味的失敗就立即重試會給工作服務造成不必要的壓力，我們要根據服務執行失敗的原因來選擇不同的重試策略。
1) 如果失敗的原因不是暫時性的，由於業務因素導致（如業務要素檢查失敗）的業務錯誤，這類錯誤是不會重發就能自動恢復的，那麼應該立即終止重試。
2) 如果錯誤的原因是一些罕見的異常，比如因爲網絡傳輸過程出現數據丟失或者錯誤，應該立即再次重試，因爲類似的錯誤一般很少會再次發生。
3) 如果錯誤的原因是系統繁忙（比如 HTTP 協議返回的 500 或者另外約定的返回碼）或者超時，這個時候需要等待一些時間再重試。
重試操作一般會指定重試次數上線，如果重試次數達到了上限就不再進行重試了。這個時候應該通過一種手段通知相關人員進行處理。
對於等待重試的策略如果重試時仍然錯誤，可逐漸增加等待的時間，直到達到一個上限後，以上限作爲等待時間。
如果某個時刻聚集了大量需要重試的操作，補償框架需要控制請求的流量，以防止對工作服務造成過大的壓力。
另外關於補償模式還有幾點補充說明。
-
微服務實現補償操作不是簡單的回退到業務發生時的狀態，因爲可能還有其他的併發的請求同時更改了狀態。一般都使用逆操作的方式完成補償。
-
補償過程不需要嚴格按照與業務發生的相反順序執行，可以依據工作服務的重用程度優先執行，甚至是可以併發的執行。
-
有些服務的補償過程是有依賴關係的，被依賴服務的補償操作沒有成功就要及時終止補償過程。
-
如果在一個業務中包含的工作服務不是都提供了補償操作，那我們編排服務時應該把提供補償操作的服務放在前面，這樣當後面的工作服務錯誤時還有機會補償。
-
設計工作服務的補償接口時應該以協調服務請求的業務要素作爲條件，不要以工作服務的應答要素作爲條件。因爲還存在超時需要補償的情況，這時補償框架就沒法提供補償需要的業務要素。
TCC模式（Try-Confirm-Cancel）
一個完整的 TCC 業務由一個主業務服務和若干個從業務服務組成，主業務服務發起並完成整個業務活動，TCC 模式要求從服務提供三個接口：Try、Confirm、Cancel。
1. Try
完成所有業務檢查
預留必須業務資源
2. Confirm
真正執行業務
不作任何業務檢查
只使用 Try 階段預留的業務資源
Confirm 操作滿足冪等性
3. Cancel：
釋放 Try 階段預留的業務資源
Cancel 操作滿足冪等性
整個 TCC 業務分成兩個階段完成。
第一階段：主業務服務分別調用所有從業務的 try 操作，並在活動管理器中登記所有從業務服務。當所有從業務服務的 try 操作都調用成功或者某個從業務服務的 try 操作失敗，進入第二階段。
第二階段：活動管理器根據第一階段的執行結果來執行 confirm 或 cancel 操作。
如果第一階段所有 try 操作都成功，則活動管理器調用所有從業務活動的 confirm操作。否則調用所有從業務服務的 cancel 操作。
需要注意的是第二階段 confirm 或 cancel 操作本身也是滿足最終一致性的過程，在調用 confirm 或 cancel 的時候也可能因爲某種原因（比如網絡）導致調用失敗，所以需要活動管理支持重試的能力，同時這也就要求 confirm 和 cancel 操作具有冪等性。
在補償模式中一個比較明顯的缺陷是，沒有隔離性。從第一個工作服務步驟開始一直到所有工作服務完成（或者補償過程完成），不一致是對其他服務可見的。另外最終一致性的保證還充分的依賴了協調服務的健壯性，如果協調服務異常，就沒法達到一致性。
TCC模式在一定程度上彌補了上述的缺陷，在TCC模式中直到明確的confirm動作，所有的業務操作都是隔離的（由業務層面保證）。另外工作服務可以通過指定 try 操作的超時時間，主動的 cancel 預留的業務資源，從而實現自治的微服務。
TCC模式和補償模式一樣需要需要有協調服務和工作服務，協調服務也可以作爲通用服務一般實現爲框架。與補償模式不同的是 TCC 服務框架不需要記錄詳細的業務流水，完成 confirm 和 cancel 操作的業務要素由業務服務提供。
在第4步確認預訂之前，訂單只是pending狀態，只有等到明確的confirm之後訂單才生效。
如果3個服務中某個服務try操作失敗，那麼可以向TCC服務框架提交cancel，或者什麼也不做由工作服務自己超時處理。
TCC 模式也不能百分百保證一致性，如果業務服務向 TCC 服務框架提交 confirm後，TCC 服務框架向某個工作服務提交 confirm 失敗（比如網絡故障），那麼就會出現不一致，一般稱爲 heuristic exception。
需要說明的是爲保證業務成功率，業務服務向 TCC 服務框架提交 confirm 以及TCC 服務框架向工作服務提交 confirm/cancel 時都要支持重試，這也就要confirm/cancel 的實現必須具有冪等性。如果業務服務向 TCC 服務框架提交confirm/cancel 失敗，不會導致不一致，因爲服務最後都會超時而取消。
另外 heuristic exception 是不可杜絕的，但是可以通過設置合適的超時時間，以及重試頻率和監控措施使得出現這個異常的可能性降低到很小。如果出現了heuristic exception 是可以通過人工的手段補救的。
對賬是最後的終極防線
如果有些業務由於瞬時的網絡故障或調用超時等問題，通過上文所講的 3 種模式一般都能得到很好的解決。但是在當今雲計算環境下，很多服務是依賴於外部系統的可用性情況，在一些重要的業務場景下還需要週期性的對賬來保證真實的一致性。比如支付系統和銀行之間每天日終是都會有對賬過程。
