今天就跟大家聊聊有關(guān)微服務架構(gòu)怎么保證數(shù)據(jù)一致性，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

堅守“ 做人真誠 · 做事靠譜 · 口碑至上 · 高效敬業(yè) ”的價值觀，專業(yè)網(wǎng)站建設(shè)服務10余年為成都辦公窗簾小微創(chuàng)業(yè)公司專業(yè)提供成都定制網(wǎng)站營銷網(wǎng)站建設(shè)商城網(wǎng)站建設(shè)手機網(wǎng)站建設(shè)小程序網(wǎng)站建設(shè)網(wǎng)站改版，從內(nèi)容策劃、視覺設(shè)計、底層架構(gòu)、網(wǎng)頁布局、功能開發(fā)迭代于一體的高端網(wǎng)站建設(shè)服務。

1. 傳統(tǒng)應用的事務管理

1.1 本地事務

傳統(tǒng)單機應用使用一個RDBMS作為數(shù)據(jù)源，應用開啟事務，進行CRUD，提交或回滾事務，統(tǒng)統(tǒng)發(fā)生在本地事務中，由資源管理器（RM）直接提供事務支持。數(shù)據(jù)的一致性在一個本地事務中得到保證。

1.2 分布式事務

1.2.1 兩階段提交（2PC）

當應用逐漸擴展，出現(xiàn)一個應用使用多個數(shù)據(jù)源的情況，這個時候本地事務已經(jīng)無法滿足數(shù)據(jù)一致性的要求。由于多個數(shù)據(jù)源的同時訪問，事務需要跨多個數(shù)據(jù)源管理，分布式事務應運而生。其中最流行的就是兩階段提交（2PC），分布式事務由事務管理器（TM）統(tǒng)一管理。

兩階段提交分為準備階段和提交階段。

兩階段提交-rollback

然而兩階段提交也不能完全保證數(shù)據(jù)一致性問題，并且有同步阻塞的問題，所以其優(yōu)化版本三階段提交（3PC）被發(fā)明了出來。

1.2.2 三階段提交（3PC）

三階段提交

然而3PC也只能保證絕大多數(shù)情況下的數(shù)據(jù)一致性。

具體分布式事務2PC和3PC的詳細介紹請見  關(guān)于分布式事務、兩階段提交協(xié)議、三階提交協(xié)議
。分布式事務不是本文的重點，故不展開。

2. 微服務下的事務管理

那么，分布式事務2PC或者3PC是否適合于微服務下的事務管理呢？答案是否定的，原因有三點：

1. 由于微服務間無法直接進行數(shù)據(jù)訪問，微服務間互相調(diào)用通常通過RPC（dubbo）或Http API（SpringCloud）進行，所以已經(jīng)無法使用TM統(tǒng)一管理微服務的RM。

2. 不同的微服務使用的數(shù)據(jù)源類型可能完全不同，如果微服務使用了NOSQL之類不支持事務的數(shù)據(jù)庫，則事務根本無從談起。

3. 即使微服務使用的數(shù)據(jù)源都支持事務，那么如果使用一個大事務將許多微服務的事務管理起來，這個大事務維持的時間，將比本地事務長幾個數(shù)量級。如此長時間的事務及跨服務的事務，將為產(chǎn)生很多鎖及數(shù)據(jù)不可用，嚴重影響系統(tǒng)性能。

由此可見，傳統(tǒng)的分布式事務已經(jīng)無法滿足微服務架構(gòu)下的事務管理需求。那么，既然無法滿足傳統(tǒng)的ACID事務，在微服務下的事務管理必然要遵循新的法則－－BASE理論。

BASE理論由eBay的架構(gòu)師Dan
Pritchett提出，BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性，應用應該可以采用合適的方式達到最終一致性。BASE是指基本可用（Basically
Available）、軟狀態(tài)（ Soft State）、最終一致性（ Eventual Consistency）。

基本可用 ：指分布式系統(tǒng)在出現(xiàn)故障的時候，允許損失部分可用性，即保證核心可用。

軟狀態(tài)
：允許系統(tǒng)存在中間狀態(tài)，而該中間狀態(tài)不會影響系統(tǒng)整體可用性。分布式存儲中一般一份數(shù)據(jù)至少會有三個副本，允許不同節(jié)點間副本同步的延時就是軟狀態(tài)的體現(xiàn)。

最終一致性 ：最終一致性是指系統(tǒng)中的所有數(shù)據(jù)副本經(jīng)過一定時間后，最終能夠達到一致的狀態(tài)。弱一致性和強一致性相反，最終一致性是弱一致性的一種特殊情況。

BASE中的 最終一致性
是對于微服務下的事務管理的根本要求，既基于微服務的事務管理無法達到強一致性，但必須保證最重一致性。那么，有哪些方法可以保證微服務下的事務管理的最終一致性呢，按照實現(xiàn)原理分主要有兩類，事件通知型和補償型，其中事件通知型又可分為可靠事件通知模式及最大努力通知模式，而補償型又可分為TCC模式、和業(yè)務補償模式兩種。這四種模式都可以達到微服務下的數(shù)據(jù)最終一致性。

3. 實現(xiàn)微服務下數(shù)據(jù)一致性的方式

3.1 可靠事件通知模式

3.1.1 同步事件

可靠事件通知模式的設(shè)計理念比較容易理解，即是主服務完成后將結(jié)果通過事件（常常是消息隊列）傳遞給從服務，從服務在接受到消息后進行消費，完成業(yè)務，從而達到主服務與從服務間的消息一致性。首先能想到的也是最簡單的就是同步事件通知，業(yè)務處理與消息發(fā)送同步執(zhí)行，實現(xiàn)邏輯見下方代碼及時序圖。

 

public void trans() {
       try {
       // 1. 操作數(shù)據(jù)庫
           bool result = dao.update(data);// 操作數(shù)據(jù)庫失敗，會拋出異常
       // 2. 如果數(shù)據(jù)庫操作成功則發(fā)送消息
           if(result){
               mq.send(data);// 如果方法執(zhí)行失敗，會拋出異常
           }
       } catch (Exception e) {
           roolback();// 如果發(fā)生異常，就回滾
       }
   }

上面的邏輯看上去天衣無縫，如果數(shù)據(jù)庫操作失敗則直接退出，不發(fā)送消息；如果發(fā)送消息失敗，則數(shù)據(jù)庫回滾；如果數(shù)據(jù)庫操作成功且消息發(fā)送成功，則業(yè)務成功，消息發(fā)送給下游消費。然后仔細思考后，同步消息通知其實有兩點不足的地方。

1. 在微服務的架構(gòu)下，有可能出現(xiàn)網(wǎng)絡IO問題或者服務器宕機的問題，如果這些問題出現(xiàn)在時序圖的第7步，使得消息投遞后無法正常通知主服務（網(wǎng)絡問題），或無法繼續(xù)提交事務（宕機），那么主服務將會認為消息投遞失敗，會滾主服務業(yè)務，然而實際上消息已經(jīng)被從服務消費，那么就會造成主服務和從服務的數(shù)據(jù)不一致。具體場景可見下面兩張時序圖。

image

1. 事件服務（在這里就是消息服務）與業(yè)務過于耦合，如果消息服務不可用，會導致業(yè)務不可用。應該將事件服務與業(yè)務解耦，獨立出來異步執(zhí)行，或者在業(yè)務執(zhí)行后先嘗試發(fā)送一次消息，如果消息發(fā)送失敗，則降級為異步發(fā)送。

3.1.2 異步事件

3.1.2.1 本地事件服務

為了解決3.1.1中描述的同步事件的問題，異步事件通知模式被發(fā)展了出來，既業(yè)務服務和事件服務解耦，事件異步進行，由單獨的事件服務保證事件的可靠投遞。

異步事件通知－外部事件服務

業(yè)務服務在提交前，向事件服務發(fā)送事件，事件服務只記錄事件，并不發(fā)送。業(yè)務服務在提交或回滾后通知事件服務，事件服務發(fā)送事件或者刪除事件。不用擔心業(yè)務系統(tǒng)在提交或者會滾后宕機而無法發(fā)送確認事件給事件服務，因為事件服務會定時獲取所有仍未發(fā)送的事件并且向業(yè)務系統(tǒng)查詢，根據(jù)業(yè)務系統(tǒng)的返回來決定發(fā)送或者刪除該事件。

外部事件雖然能夠?qū)I(yè)務系統(tǒng)和事件系統(tǒng)解耦，但是也帶來了額外的工作量：外部事件服務比起本地事件服務來說多了兩次網(wǎng)絡通信開銷（提交前、提交／回滾后），同時也需要業(yè)務系統(tǒng)提供單獨的查詢接口給事件系統(tǒng)用來判斷未發(fā)送事件的狀態(tài)。

3.1.2.3 可靠事件通知模式的注意事項

可靠事件模式需要注意的有兩點，1. 事件的正確發(fā)送；2. 事件的重復消費。
通過異步消息服務可以確保事件的正確發(fā)送，然而事件是有可能重復發(fā)送的，那么就需要消費端保證同一條事件不會重復被消費，簡而言之就是保證事件消費的 冪等性
。

如果事件本身是具備冪等性的狀態(tài)型事件，如訂單狀態(tài)的通知（已下單、已支付、已發(fā)貨等），則需要判斷事件的順序。一般通過時間戳來判斷，既消費過了新的消息后，當接受到老的消息直接丟棄不予消費。如果無法提供全局時間戳，則應考慮使用全局統(tǒng)一的序列號。

對于不具備冪等性的事件，一般是動作行為事件，如扣款100，存款200，則應該將事件id及事件結(jié)果持久化，在消費事件前查詢事件id，若已經(jīng)消費則直接返回執(zhí)行結(jié)果；若是新消息，則執(zhí)行，并存儲執(zhí)行結(jié)果。

3.2 最大努力通知模式

相比可靠事件通知模式，最大努力通知模式就容易理解多了。最大努力通知型的特點是，業(yè)務服務在提交事務后，進行有限次數(shù)（設(shè)置最大次數(shù)限制）的消息發(fā)送，比如發(fā)送三次消息，若三次消息發(fā)送都失敗，則不予繼續(xù)發(fā)送。所以有可能導致消息的丟失。同時，主業(yè)務方需要提供查詢接口給從業(yè)務服務，用來恢復丟失消息。最大努力通知型對于時效性保證比較差（既可能會出現(xiàn)較長時間的軟狀態(tài)），所以對于數(shù)據(jù)一致性的時效性要求比較高的系統(tǒng)無法使用。這種模式通常使用在不同業(yè)務平臺服務或者對于第三方業(yè)務服務的通知，如銀行通知、商戶通知等，這里不再展開。

3.3 業(yè)務補償模式

接下來介紹兩種補償模式，補償模式比起事件通知模式最大的不同是，補償模式的上游服務依賴于下游服務的運行結(jié)果，而事件通知模式上游服務不依賴于下游服務的運行結(jié)果。首先介紹業(yè)務補償模式，業(yè)務補償模式是一種純補償模式，其設(shè)計理念為，業(yè)務在調(diào)用的時候正常提交，當一個服務失敗的時候，所有其依賴的上游服務都進行業(yè)務補償操作。舉個例子，小明從杭州出發(fā)，去往美國紐約出差，現(xiàn)在他需要定從杭州去往上海的火車票，以及從上海飛往紐約的飛機票。如果小明成功購買了火車票之后發(fā)現(xiàn)那天的飛機票已經(jīng)售空了，那么與其在上海再多待一天，小明還不如取消去上海的火車票，選擇飛往北京再轉(zhuǎn)機紐約，所以小明就取消了去上海的火車票。這個例子中購買杭州到上海的火車票是服務a，購買上海到紐約的飛機票是服務b，業(yè)務補償模式就是在服務b失敗的時候，對服務a進行補償操作，在例子中就是取消杭州到上海的火車票。

補償模式要求每個服務都提供補償借口，且這種補償一般來說是 不完全補償
，既即使進行了補償操作，那條取消的火車票記錄還是一直存在數(shù)據(jù)庫中可以被追蹤（一般是有相信的狀態(tài)字段“已取消”作為標記），畢竟已經(jīng)提交的線上數(shù)據(jù)一般是不能進行物理刪除的。

業(yè)務補償模式最大的缺點是軟狀態(tài)的時間比較長，既數(shù)據(jù)一致性的時效性很低，多個服務常?？赡芴幱跀?shù)據(jù)不一致的情況。

3.4 TCC/Try Confirm Cancel模式

TCC模式是一種優(yōu)化了的業(yè)務補償模式，它可以做到 完全補償
，既進行補償后不留下補償?shù)募o錄，就好像什么事情都沒有發(fā)生過一樣。同時，TCC的軟狀態(tài)時間很短，原因是因為TCC是一種兩階段型模式（已經(jīng)忘了兩階段概念的可以回顧一下1.2.1），只有在所有的服務的第一階段（try）都成功的時候才進行第二階段確認（Confirm）操作，否則進行補償(Cancel)操作，而在try階段是不會進行真正的業(yè)務處理的。

TCC模式

TCC模式的具體流程為兩個階段：

1. Try，業(yè)務服務完成所有的業(yè)務檢查，預留必需的業(yè)務資源

2. 如果Try在所有服務中都成功，那么執(zhí)行Confirm操作，Confirm操作不做任何的業(yè)務檢查（因為try中已經(jīng)做過），只是用Try階段預留的業(yè)務資源進行業(yè)務處理；否則進行Cancel操作，Cancel操作釋放Try階段預留的業(yè)務資源。

這么說可能比較模糊，下面我舉一個具體的例子，小明在線從招商銀行轉(zhuǎn)賬100元到廣發(fā)銀行。這個操作可看作兩個服務，服務a從小明的招行賬戶轉(zhuǎn)出100元，服務b從小明的廣發(fā)銀行帳戶匯入100元。

服務a（小明從招行轉(zhuǎn)出100元）:

 

try: update cmb_account set balance=balance-100, freeze=freeze+100 where
acc_id=1 and balance>100;

confirm: update cmb_account set freeze=freeze-100 where acc_id=1;

cancel: update cmb_account set balance=balance+100, freeze=freeze-100 where
acc_id=1;

服務b（小明往廣發(fā)銀行匯入100元）:

 

try: update cgb_account set freeze=freeze+100 where acc_id=1;

confirm: update cgb_account set balance=balance+100, freeze=freeze-100 where
acc_id=1;

cancel: update cgb_account set freeze=freeze-100 where acc_id=1;

具體說明：

• a的try階段，服務做了兩件事，1：業(yè)務檢查，這里是檢查小明的帳戶里的錢是否多余100元；2:預留資源，將100元從余額中劃入凍結(jié)資金。

• a的confirm階段，這里不再進行業(yè)務檢查，因為try階段已經(jīng)做過了，同時由于轉(zhuǎn)賬已經(jīng)成功，將凍結(jié)資金扣除。

• a的cancel階段，釋放預留資源，既100元凍結(jié)資金，并恢復到余額。

• b的try階段進行，預留資源，將100元凍結(jié)。

• b的confirm階段，使用try階段預留的資源，將100元凍結(jié)資金劃入余額。

• b的cancel階段，釋放try階段的預留資源，將100元從凍結(jié)資金中減去。

從上面的簡單例子可以看出，TCC模式比純業(yè)務補償模式更加復雜，所以在實現(xiàn)上每個服務都需要實現(xiàn)Cofirm和Cancel兩個接口。

3.5 總結(jié)

下面的表格對這四種常用的模式進行了比較：

看完上述內(nèi)容，你們對微服務架構(gòu)怎么保證數(shù)據(jù)一致性有進一步的了解嗎？如果還想了解更多知識或者相關(guān)內(nèi)容，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。

網(wǎng)頁名稱：微服務架構(gòu)怎么保證數(shù)據(jù)一致性
文章轉(zhuǎn)載：http://jinyejixie.com/article16/gcecgg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、搜索引擎優(yōu)化、定制開發(fā)、軟件開發(fā)、網(wǎng)站設(shè)計、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)