微服務架構(gòu)下的數(shù)據(jù)一致性方案

微服務架構(gòu)下的數(shù)據(jù)一致性方案隨著微服務架構(gòu)的推廣，越來越多的公司采用微服務架構(gòu)來構(gòu)建自己的業(yè)務平臺。就像前邊的文章說的，微服務架構(gòu)為業(yè)務開發(fā)帶來了諸多好處的同時，例如單一職責、獨立開發(fā)部署、功能復用和系統(tǒng)容錯等等，也帶來一些問題。例如上手難度變大，運維變得更復雜，模塊之間的依賴關(guān)系更復雜，數(shù)據(jù)一致性難以保證，等等。但是辦法總是比問題多，本篇文章就來介紹一下我們是如何保障微服務架構(gòu)的數(shù)據(jù)一致性的。

微服務架構(gòu)的數(shù)據(jù)一致性問題以電商平臺為例，當用戶下單并支付后，系統(tǒng)需要修改訂單的狀態(tài)并且增加用戶積分。由于系統(tǒng)采用的是微服務架構(gòu)，分離出了支付服務、訂單服務和積分服務，每個服務都有獨立數(shù)據(jù)庫做數(shù)據(jù)存儲。當用戶支付成功后，無論是修改訂單狀態(tài)失敗還是增加積分失敗，都會造成數(shù)據(jù)的不一致。為了解決例子中的數(shù)據(jù)一致性問題，一個最直接的辦法就是考慮數(shù)據(jù)的強一致性。那么如何保證數(shù)據(jù)的強一致性呢？我們從關(guān)系型數(shù)據(jù)庫的ACID理論說起。ACID關(guān)系型數(shù)據(jù)庫具有解決復雜事務場景的能力，關(guān)系型數(shù)據(jù)庫的事務滿足ACID的特性。Atomicity：原子性（要么都做，要么都不做）Consistency：一致性（數(shù)據(jù)庫只有一個狀態(tài)，不存在未確定狀態(tài)）Isolation：隔離性（事務之間互不干擾）Durability：永久性（事務一旦提交，數(shù)據(jù)庫記錄永久不變）具有ACID特性的數(shù)據(jù)庫支持數(shù)據(jù)的強一致性，保證了數(shù)據(jù)本身不會出現(xiàn)不一致。然而微服務架構(gòu)下，每個微服務都有自己的數(shù)據(jù)庫，導致微服務架構(gòu)的系統(tǒng)不能簡單地滿足ACID，我們就需要尋找微服務架構(gòu)下的數(shù)據(jù)一致性解決方案。微服務架構(gòu)的系統(tǒng)本身是一種分布式系統(tǒng)，而本文討論的問題其實也就是分布式事務之數(shù)據(jù)一致性的問題，我們來聊聊分布式系統(tǒng)的CAP理論和BASE理論。CAPCAP是指在一個分布式系統(tǒng)下，包含三個要素：Consistency（一致性）、Availability（可用性）、Partitiontolerance（分區(qū)容錯性），并且三者不可得兼。C：Consistency，一致性，所有數(shù)據(jù)變動都是同步的。A：Availability，可用性，即在可以接受的時間范圍內(nèi)正確地響應用戶請求。P：Partitiontolerance，分區(qū)容錯性，即某節(jié)點或網(wǎng)絡分區(qū)故障時，系統(tǒng)仍能夠提供滿足一致性和可用性的服務。關(guān)系型數(shù)據(jù)庫單節(jié)點保證了數(shù)據(jù)強一致性（C）和可用性（A），但是卻無法保證分區(qū)容錯性（P）。然而在分布式系統(tǒng)下，為了保證模塊的分區(qū)容錯性（P），只能在數(shù)據(jù)強一致性（C）和可用性（A）之間做平衡。具體表現(xiàn)為在一定時間內(nèi)，可能模塊之間數(shù)據(jù)是不一致的，但是通過自動或手動補償后能夠達到最終的一致。BASEBASE理論主要是解決CAP理論中分布式系統(tǒng)的可用性和一致性不可兼得的問題。BASE理論包含以下三個要素：BA：BasicallyAvailable，基本可用。S：SoftState，軟狀態(tài)，狀態(tài)可以有一段時間不同步。E：EventuallyConsistent，最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時時保持強一致。BASE模型與ACID不同，滿足CAP理論，通過犧牲強一致性來保證系統(tǒng)可用性。由于犧牲了強一致性，系統(tǒng)在處理請求的過程中，數(shù)據(jù)可以存在短時的不一致。系統(tǒng)在處理業(yè)務時，記錄每一步的臨時狀態(tài)。當出現(xiàn)異常時，根據(jù)狀態(tài)判斷是否繼續(xù)處理請求或者退回原始狀態(tài)，從而達到數(shù)據(jù)的最終一致。例如，在上面的案例中，支付成功，訂單也成功，但增加積分失敗，此時，不應回滾支付和訂單，而應通過一些補償方法來讓積分得以正確地增加。后面會講到具體的實現(xiàn)方法。在分享我們的分布式事務實踐方案之前，先看看早期解決分布式事務問題的二階段提交協(xié)議。二階段提交協(xié)議X/OpenDTP（DistributedTransactionProcess）是一個分布式事務模型，此模型主要使用二階段提交（2PC，Two-Phase-Commit）來保證分布式事務的完整性。在這個模型里面，有三個角色：AP：Application，應用程序，業(yè)務層。RM：ResourceManager，資源管理器，關(guān)系型數(shù)據(jù)庫或支持XA接口（XA規(guī)范是X/Open組織定義的分布式事務規(guī)范）的組件。TM：TransactionManager，事務管理器，負責各個RM的提交和回滾。當應用程序（AP）調(diào)用了事務管理器（TM）的提交方法時，事務的提交分為兩個階段實行。第一階段（準備階段）TM通知所有參與事務的各個RM，給每個RM發(fā)送prepare消息。RM接收到消息后進入準備階段后，要么直接返回失敗，要么創(chuàng)建并執(zhí)行本地事務，寫本地事務日志（redo和undo日志），但是不提交（此處只保留最后一步耗時最少的提交操作給第二階段執(zhí)行）。第二階段（提交/回滾階段）TM收到RM準備階段的失敗消息或者獲取RM返回消息超時，則直接給RM發(fā)送回滾（rollback）消息，否則發(fā)送提交（commit）消息。RM根據(jù)TM的指令執(zhí)行提交或者回滾，執(zhí)行完成后釋放所有事務處理過程中使用的鎖（最后階段釋放鎖）。二階段提交的利弊優(yōu)點2PC提供了一套完整的分布式事務的解決方案，遵循事務嚴格的ACID特性。缺點TM通過XA接口與各個RM之間進行數(shù)據(jù)交互，從第一階段的準備階段，業(yè)務所涉及的數(shù)據(jù)就被鎖定，并且鎖定跨越整個提交流程。在高并發(fā)和涉及業(yè)務模塊較多的情況下對數(shù)據(jù)庫的性能影響較大。二階段是反可伸縮模式的，業(yè)務規(guī)模越大，涉及模塊越多，局限性越大，系統(tǒng)可伸縮性越差。在技術(shù)棧比較雜的分布式應用中，存儲組件有很多不支持XA協(xié)議。二階段的諸多弊端，導致分布式系統(tǒng)下無法直接使用此方案來解決數(shù)據(jù)一致性問題，但它提供了解決分布式系統(tǒng)下數(shù)據(jù)一致性問題的思路。下面就通過案例來分享我們是如何保證微服務架構(gòu)的數(shù)據(jù)一致性的。可靠消息最終一致性可靠消息最終一致性方案本質(zhì)上是利用MQ組件實現(xiàn)的二階段提交。此方案涉及3個模塊：上游應用，執(zhí)行業(yè)務并發(fā)送MQ消息。可靠消息服務和MQ消息組件，協(xié)調(diào)上下游消息的傳遞，并確保上下游數(shù)據(jù)的一致性。下游應用，監(jiān)聽MQ的消息并執(zhí)行自身業(yè)務。上游應用執(zhí)行業(yè)務并發(fā)送MQ消息（第一階段）上游應用將本地業(yè)務執(zhí)行和消息發(fā)送綁定在同一個本地事務中，保證要么本地操作成功并發(fā)送MQ消息，要么兩步操作都失敗并回滾。上游應用和可靠消息之間的業(yè)務交互圖如下：上游應用發(fā)送待確認消息到可靠消息系統(tǒng)可靠消息系統(tǒng)保存待確認消息并返回上游應用執(zhí)行本地業(yè)務上游應用通知可靠消息系統(tǒng)確認業(yè)務已執(zhí)行并發(fā)送消息?？煽肯⑾到y(tǒng)修改消息狀態(tài)為發(fā)送狀態(tài)并將消息投遞到MQ中間件。以上每一步都可能出現(xiàn)失敗情況，分析一下這5步出現(xiàn)異常后上游業(yè)務和消息發(fā)送是否一致：上游應用執(zhí)行完成，下游應用尚未執(zhí)行或執(zhí)行失敗時，此事務即處于BASE理論的SoftState狀態(tài)。下游應用監(jiān)聽MQ消息并執(zhí)行業(yè)務（第二階段）下游應用監(jiān)聽MQ消息并執(zhí)行業(yè)務，并且將消息的消費結(jié)果通知可靠消息服務。可靠消息的狀態(tài)需要和下游應用的業(yè)務執(zhí)行保持一致，可靠消息狀態(tài)不是已完成時，確保下游應用未執(zhí)行，可靠消息狀態(tài)是已完成時，確保下游應用已執(zhí)行。下游應用和可靠消息服務之間的交互圖如下：下游應用監(jiān)聽MQ消息組件并獲取消息下游應用根據(jù)MQ消息體信息處理本地業(yè)務下游應用向MQ組件自動發(fā)送ACK確認消息被消費下游應用通知可靠消息系統(tǒng)消息被成功消費，可靠消息將該消息狀態(tài)更改為已完成。以上每一步都可能出現(xiàn)失敗情況，分析一下這4步出現(xiàn)異常后下游業(yè)務和消息狀態(tài)是否一致：通過分析以上兩個階段可能失敗的情況，為了確保上下游數(shù)據(jù)的最終一致性，在可靠消息系統(tǒng)中，需要開發(fā)消息狀態(tài)確認和消息重發(fā)兩個功能以實現(xiàn)BASE理論的EventuallyConsistent特性。消息狀態(tài)確認可靠消息服務定時監(jiān)聽消息的狀態(tài)，如果存在狀態(tài)為待確認并且超時的消息，則表示上游應用和可靠消息交互中的步驟4或者5出現(xiàn)異常?？煽肯t攜帶消息體內(nèi)的信息向上游應用發(fā)起請求查詢該業(yè)務是否已執(zhí)行。上游應用提供一個可查詢接口供可靠消息追溯業(yè)務執(zhí)行狀態(tài)，如果業(yè)務執(zhí)行成功則更改消息狀態(tài)為已發(fā)送，否則刪除此消息確保數(shù)據(jù)一致。具體流程如下：可靠消息查詢超時的待確認狀態(tài)的消息向上游應用查詢業(yè)務執(zhí)行的情況業(yè)務未執(zhí)行，則刪除該消息，保證業(yè)務和可靠消息服務的一致性。業(yè)務已執(zhí)行，則修改消息狀態(tài)為已發(fā)送，并發(fā)送消息到MQ組件。消息重發(fā)消息已發(fā)送則表示上游應用已經(jīng)執(zhí)行，接下來則確保下游應用也能正常執(zhí)行?？煽肯⒎瞻l(fā)現(xiàn)可靠消息服務中存在消息狀態(tài)為已發(fā)送并且超時的消息，則表示可靠消息服務和下游應用中存在異常的步驟，無論哪個步驟出現(xiàn)異常，可靠消息服務都將此消息重新投遞到MQ組件中供下游應用監(jiān)聽。下游應用監(jiān)聽到此消息后，在保證冪等性的情況下重新執(zhí)行業(yè)務并通知可靠消息服務此消息已經(jīng)成功消費，最終確保上游應用、下游應用的數(shù)據(jù)最終一致性。具體流程如下：可靠消息服務定時查詢狀態(tài)為已發(fā)送并超時的消息可靠消息將消息重新投遞到MQ組件中下游應用監(jiān)聽消息，在滿足冪等性的條件下，重新執(zhí)行業(yè)務。下游應用通知可靠消息服務該消息已經(jīng)成功消費。通過消息狀態(tài)確認和消息重發(fā)兩個功能，可以確保上游應用、可靠消息服務和下游應用數(shù)據(jù)的最終一致性。當然在實際接入過程中，需要引入人工干預功能。比如引入重發(fā)次數(shù)限制，超過重發(fā)次數(shù)限制的將消息修改為死亡消息，等待人工干預。代入開篇案例，通過可靠消息最終一致性方案，第一階段，訂單狀態(tài)更改之前，訂單服務向可靠消息服務請求保存待確認消息?？煽肯⒎毡４嫦⒉⒎祷亍Ｓ唵畏战邮盏椒祷匦畔⒑髨?zhí)行本地業(yè)務并通知可靠消息服務業(yè)務已執(zhí)行。消息服務更改消息狀態(tài)并將消息投遞到MQ中間件。第二階段，積分系統(tǒng)監(jiān)聽到MQ消息，查看積分是否已增加，如果沒有增加則修改積分，然后請求可靠消息服務?？煽肯⒎战邮盏椒e分系統(tǒng)的請求，將消息狀態(tài)更改為已完成。到這里，已經(jīng)介紹完如何通過可靠消息服務來保證數(shù)據(jù)的一致性。但由于引入了可靠消息服務和消息隊列，帶來了一定的復雜性，所以，它更適用于跨平臺技術(shù)棧不統(tǒng)一的場景。下面再來介紹在技術(shù)棧統(tǒng)一的情況下，如何通過TCC來解決數(shù)據(jù)一致的方法。TCC（Try-Confirm-Cancel）TCC方案是二階段提交的另一種實現(xiàn)方式，它涉及3個模塊，主業(yè)務、從業(yè)務和活動管理器（協(xié)作者）。下面這張圖是互聯(lián)網(wǎng)上關(guān)于TCC比較經(jīng)典的圖示：第一階段：主業(yè)務服務分別調(diào)用所有從業(yè)務服務的try操作，并在活動管理器中記錄所有從業(yè)務服務。當所有從業(yè)務服務try成功或者某個從業(yè)務服務try失敗時，進入第二階段。第二階段：活動管理器根據(jù)第一階段從業(yè)務服務的try結(jié)果來執(zhí)行confirm或cancel操作。如果第一階段所有從業(yè)務服務都try成功，則協(xié)作者調(diào)用所有從業(yè)務服務的confirm操作，否則，調(diào)用所有從業(yè)務服務的cancel操作。在第二階段中，confirm和cancel同樣存在失敗情況，所以需要對這兩種情況做異常處理以保證數(shù)據(jù)一致性。Confirm失敗：則回滾所有confirm操作并執(zhí)行cancel操作。Cancel失?。簭臉I(yè)務服務需要提供自動cancel機制，以保證cancel成功。目前有很多基于RPC的TCC框架，但是不適用于微服務架構(gòu)下基于HTTP協(xié)議的交互模式。我們這次只討論基于HTTP協(xié)議的TCC實現(xiàn)。具體的實現(xiàn)流程如下：主業(yè)務服務調(diào)用從業(yè)務服務的try操作，并獲取confirm/cancel接口和超時時間。如果從業(yè)務都try成功，主業(yè)務服務執(zhí)行本地業(yè)務，并將獲取的confirm/cancel接口發(fā)送給活動管理器，活動管理器會順序調(diào)用從業(yè)務1和從業(yè)務2的confirm接口并記錄請求狀態(tài)，如果請求成功，則通知主業(yè)務服務提交本地事務。如果confirm部分失敗，則活動管理器會順序調(diào)用從業(yè)務1和從業(yè)務2的cancel接口來取消try的操作。如果從業(yè)務部分或全部try失敗，則主業(yè)務直接回滾并結(jié)束，而try成功的從業(yè)務服務則通過定時任務來處理處于try完成但超時的數(shù)據(jù)，將這些數(shù)據(jù)做回滾處理保證主業(yè)務服務和從業(yè)務服務的數(shù)據(jù)一致。代入開篇提到的案例，通過TCC方案，訂單服務在訂單狀態(tài)修改之前執(zhí)行預增積分操作（try），并從積分服務獲取confirm/cancel預增積分的請求地址。如果預增積分（try）成功，則訂單服務更改訂單狀態(tài)并通知活動管理器，活動管理器請求積分模塊的confirm接口來增加積分。如果預增積分（try）失敗，則訂單服務業(yè)務回滾。積分服務通過定時任務刪除預增積分（try）超時的數(shù)據(jù)。另外如果活動管理器調(diào)用積分服務的confirm接口失敗，則活動管理器調(diào)用積分服務cancel接口來取消預增積分，從而，保證訂單和積分數(shù)據(jù)的最終一致性。通過上面的對可靠消息服務和TCC方案的描述，我們解決了技術(shù)棧一致和不一致的兩種情況下的數(shù)據(jù)一致性問題。但是，通常在這些核心業(yè)務上有很多附加業(yè)務，比如當用戶支付完成后，需要通過短信通知用戶支付成功。這一類業(yè)務的成功或者失敗不會影響核心業(yè)務，甚至很多大型互聯(lián)網(wǎng)平臺在并高并發(fā)的情況下會主動關(guān)閉這一類業(yè)務以保證核心業(yè)務的順利執(zhí)行。那么怎么處理這類情況呢，我們來看看最大努力通知方案。最大努力通知最大努力通知方案涉及三個模塊：上游應用，發(fā)消息到MQ隊列。下游應用（例如短信服務、郵件服務），接受請求，并返回通知結(jié)果。最大努力通知服務，監(jiān)聽消息隊列，將消息存儲到數(shù)據(jù)庫中，并按照通知規(guī)則調(diào)用下游應用的發(fā)送通知接口。具體流程如下：上游應用發(fā)送MQ消息到MQ組件內(nèi)，消息內(nèi)包含通知規(guī)則和通知地址最大努力通知服務監(jiān)聽到MQ內(nèi)的消息，解析通知規(guī)則并放入延時隊列等待觸發(fā)通知最大努力通知服務調(diào)用下游的通知地址，如果調(diào)用成功，則該消息標記為通知成功，如果失敗則在滿足通知規(guī)則（例如5分鐘發(fā)一次，