微服務架構下的數據一致性保證（一）

你們好，今天我給你們分享的題目是微服務架構下的數據一致性保證。

 

 

今天分享第一篇，主要內容包括：

 

1.傳統使用本地事務和分佈式事務保證一致性。

2.傳統分佈式事務不是微服務中一致性的最佳選擇。

3.微服務架構中應知足數據最終一致性原則。

4.微服務架構實現最終一致性的三種模式。

5.對帳是最後的終極防線。

 

 

1、傳統使用本地事務和分佈式事務保證一致性

 

 

傳統單機應用通常都會使用一個關係型數據庫，好處是應用可使用 ACID transactions。爲保證一致性咱們只須要：開始一個事務，改變（插入，刪除，更新）不少行，而後提交事務（若是有異常時回滾事務）。更進一步，藉助開發平臺中的數據訪問技術和框架（如Spring），咱們須要作的事情更少，只須要關注數據自己的改變。

 

隨着組織規模不斷擴大，業務量不斷增加，單機應用和數據庫已經不足以支持龐大的業務量和數據量，這個時候須要對應用和數據庫進行拆分，就出現了一個應用須要同時訪問兩個或兩個以上的數據庫狀況。開始咱們用分佈式事務來保證一致性，也就是咱們常說的兩階段提交協議（2PC）。

 

 

本地事務和分佈式事務如今已經很是成熟，相關介紹很豐富，此處很少做討論。

 

2、傳統分佈式事務不是微服務中一致性的最佳選擇

 

 

首先，對於微服務架構來講，數據訪問變得更加複雜，這是由於數據都是微服務私有的，惟一可訪問的方式就是經過API。這種打包數據訪問方式使得微服務之間鬆耦合，而且彼此之間獨立很是容易進行性能擴展。

 

其次，不一樣的微服務常用不一樣的數據庫。應用會產生各類不一樣類型的數據，關係型數據庫並不必定是最佳選擇。

 

例如，某個產生和查詢字符串的應用採用Elasticsearch的字符搜索引擎；某個產生社交圖片數據的應用能夠採用圖數據庫，例如，Neo4j；

 

基於微服務的應用通常都使用SQL和NoSQL結合的模式。可是這些非關係型數據大多數並不支持2PC。

 

可見在微服務架構中已經不能選擇分佈式事務了。

 

3、微服務架構中應知足數據最終一致性原則

 

 

依據CAP理論，必須在可用性（availability）和一致性（consistency）之間作出選擇。若是選擇提供一致性須要付出在知足一致性以前阻塞其餘併發訪問的代價。這可能持續一個不肯定的時間，尤爲是在系統已經表現出高延遲時或者網絡故障致使失去鏈接時。

 

依據目前的成功經驗，可用性通常是更好的選擇，可是在服務和數據庫之間維護數據一致性是很是根本的需求，微服務架構中選擇知足最終一致性。

 

 

固然選擇了最終一致性，就要保證到最終的這段時間要在用戶可接受的範圍以內。

 

那麼咱們怎麼實現最終一致性呢？

 

4、微服務架構實現最終一致性的三種模式

 

 

從一致性的本質來看，是要保證在一個業務邏輯中包含的服務要麼都成功，要麼都失敗。那咱們怎麼選擇方向呢？保證成功仍是保證失敗呢？

咱們說業務模式決定了咱們的選擇。實現最終一致性有三種模式：可靠事件模式、業務補償模式、TCC模式。

 

1) 可靠事件模式

 

可靠事件模式屬於事件驅動架構，當某件重要事情發生時，例如更新一個業務實體，微服務會向消息代理髮佈一個事件。消息代理會向訂閱事件的微服務推送事件，當訂閱這些事件的微服務接收此事件時，就能夠完成本身的業務，也可能會引起更多的事件發佈。

 

1. 如訂單服務建立一個待支付的訂單，發佈一個「建立訂單」的事件。

 

 

2.支付服務消費「建立訂單」事件，支付完成後發佈一個「支付完成」事件。

 

 

3.訂單服務消費「支付完成」事件，訂單狀態更新爲待出庫。

 

 

從而就實現了完成的業務流程。

 

這個過程可能致使出現不一致的地方在於：某個微服務在更新了業務實體後發佈事件卻失敗；雖然微服務發佈事件成功，可是消息代理未能正確推送事件到訂閱的微服務；接受事件的微服務重複消費了事件。

 

可靠事件模式在於保證可靠事件投遞和避免重複消費，可靠事件投遞定義爲（a）每一個服務原子性的業務操做和發佈事件（b）消息代理確保事件傳遞至少一次。

 

避免重複消費要求服務實現冪等性，如支付服務不能由於重複收到事件而屢次支付。

 

2) 補償模式

 

爲了描述方便，這裏先定義兩個概念：

 

業務異常：業務邏輯產生錯誤的狀況，好比帳戶餘額不足、商品庫存不足等。

技術異常：非業務邏輯產生的異常，如網絡鏈接異常、網絡超時等。

 

補償模式使用一個額外的協調服務來協調各個須要保證一致性的微服務，協調服務按順序調用各個微服務，若是某個微服務調用異常（包括業務異常和技術異常）就取消以前全部已經調用成功的微服務。

 

補償模式建議僅用於不能避免出現業務異常的狀況，若是有可能應該優化業務模式，以免要求補償事務。如帳戶餘額不足的業務異常可經過預先凍結金額的方式避免，商品庫存不足可要求商家準備額外的庫存等。

咱們經過一個實例來講明補償模式，一家旅行公司提供預訂行程的業務，能夠經過公司的網站提早預訂飛機票、火車票、酒店等。

 

假設一位客戶規劃的行程是，（1）上海-北京6月19日9點的某某航班，（2）某某酒店住宿3晚，（3）北京-上海6月22日17點火車。在客戶提交行程後，旅行公司的預訂行程業務按順序串行的調用航班預訂服務、酒店預訂服務、火車預訂服務。最後的火車預訂服務成功後整個預訂業務纔算完成。

 

 

若是火車票預訂服務沒有調用成功，那麼以前預訂的航班、酒店都得取消。取消以前預訂的酒店、航班即爲補償過程。

 

 

須要注意的是酒店的取消預訂、航班的取消預訂一樣不能保證必定成功，因此補償過程每每也一樣須要實現最終一致性，須要保證取消服務至少被調用一次和取消服務必須實現冪等性。

 

咱們應該儘量經過設計避免採用補償方式，好比上面的例子中，在預訂火車票失敗的時候能夠提示客戶更改其餘的時間。

 

 3) 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操做具備冪等性。

 

5、對帳是最後的終極防線

 

若是有些業務因爲瞬時的網絡故障或調用超時等問題，經過上文所講的3種模式通常都能獲得很好的解決。可是在當今雲計算環境下，不少服務是依賴於外部系統的可用性狀況，在一些重要的業務場景下還須要週期性的對帳來保證真實的一致性。好比支付系統和銀行之間天天日終是都會有對帳過程。

 

以上就是今天分享的內容，主要介紹的是微服務架構中須要知足最終一致性原則以及實現最終一致性的3種模式。關於每種模式的實現方法以及可能遇到的問題會在從此逐步和你們分享。

 

謝謝你們！