引言
在互聯網系統(tǒng)中，理想的情況下，肯定是希望系統(tǒng)能夠同時滿足“一致性”、“可用性”和“分區(qū)容忍性”。 但是基于熟悉的CAP定律也好，還是BASE理論， 我們知道，在實際情況中是不可能實現的。而在金融領域，一致性是最為關注的特性，任何情況下都必須滿足一致性。關于CAP定律和BASE理論，本文不再介紹，有興趣的同學可以自行百度一下。本文重點來闡述下關于一致性的方案，包括強一致性和最終一致性。 而在互聯網領域， 很多情況下都是犧牲強一致性，來達到高可用性，系統(tǒng)往往只需要保證“最終一致性”，只要這個最終時間是在用戶可以接受的范圍內即可。
數據庫本地事務
數據庫事務肯定是強一致性的方案，而且是一致性最簡單的方案，因為一致性是數據庫的事務來保證的，業(yè)務層不需要關心細節(jié)。比較典型的應用是在返現場景下，針對帶有返現的交易的退款，需要一次性退兩筆交易單，采用的就是通過數據庫本地事務來完成的。具體如下：
用戶A花了100元購買商戶B的商品，購買結束后返現給用戶A 2元。 這是兩筆交易，原始交易是100元，返現交易是2元。 那么發(fā)生退款時，需要保證兩筆交易同時都退款。這個就是直接采用數據庫本地事務實現的，即一次退款請求，兩筆交易同時退款。
總結： 數據庫事務的優(yōu)點是簡單，業(yè)務層關心的很少。但是對于一個可用性很高的系統(tǒng)來說，所有的業(yè)務都揉在數據庫事務執(zhí)行，會讓事務非常的復雜，不利于系統(tǒng)的擴展和維護。
兩階段提交
除了數據庫能夠保證本地的一致性，對于互聯網系統(tǒng)來說，更多是分布式系統(tǒng)。提到分布式系統(tǒng)，必然提到分布式事務。而分布式事務中，就不得不介紹兩階段提交協(xié)議(2pc)。 而在核心系統(tǒng)，兩階段提交的方案主要應用在分布式數據庫NesioDB和交易賬務分離的柔性事務中。
分布式數據庫NesioDB是由百度DBA和百度錢包聯合開發(fā)的，支持分布式事務的數據庫，目前已經應用在百度錢包的核心交易業(yè)務上，并穩(wěn)定運行兩年。該數據庫的設計要求是讓使用者能夠像使用單機數據庫一樣的使用分布式數據庫，因此實現的分布式事務，滿足單機事務的ACID原則。關于分布式事務的一致性，采用的就是兩階段提交的方式來實現的，并且滿足分布式事務模型。如下圖所示。
第一階段是準備階段。
DTM 通知所有參與事務的各個 RM，給每個 RM 發(fā)送 prepare 消息。RM 接收到消息后進入準備階段后，要么直接返回失敗，要么創(chuàng)建并執(zhí)行本地事務，寫本地事務日志（redo 和 undo 日志），但是 不提交（此處只保留最后一步耗時最少的提交操作給第二階段執(zhí)行）。
第二階段是提交/回滾階段。
DTM 收到 RM 準備階段的失敗消息或者獲取 RM 返回消息超時，則直接給 RM 發(fā)送回滾（rollback）消息，否則發(fā)送提交（commit）消息。RM 根據 TM 的指令執(zhí)行提交或者回滾，執(zhí)行完成后釋放所有事務處理過程中使用的鎖（最后階段釋放鎖）。
數據庫層面的兩階段提交，可以用來保證分布式事務的一致性，使得使用者使用分布式事務和單機事務一樣方便。而兩階段提交的另外一種實現，即TCC(Try-Confirm-Cancel)， 也就是業(yè)務層面的柔性事務。 交易和賬務分離的一致性實現，就是采用這種柔性事務來完成的。首先來說說柔性事務，它涉及 3 個模塊，主業(yè)務、從業(yè)務 和 活動管理器（協(xié)作者）。
下面這張圖是有關柔性事務一張經典的圖。
第一階段：主業(yè)務服務分別調用所有從業(yè)務服務的 try 操作，并在活動管理器中記錄所有從業(yè)務服務。當所有從業(yè)務服務 try 成功或者某個從業(yè)務服務 try 失敗時，進入第二階段。
第二階段：活動管理器根據第一階段從業(yè)務服務的 try 結果來執(zhí)行 confirm 或 cancel 操作。如果第一階段所有從業(yè)務服務都 try 成功，則協(xié)作者調用所有從業(yè)務服務的 confirm 操作，否則，調用所有從業(yè)務服務的 cancel 操作。
在第二階段中，confirm 和 cancel 同樣存在失敗情況，所以需要對這兩種情況做 異常處理以保證數據一致性。
1.Confirm 失�。簞t回滾所有 confirm 操作并執(zhí)行 cancel 操作。
2.Cancel 失�。簭臉I(yè)務服務需要提供自動 cancel 機制，以保證 cancel 成功。
如果對應到交易和賬務分離的項目中，流程如下：
第一階段： 主業(yè)務服務調用交易和賬務執(zhí)行try的操作，交易開啟事務，做業(yè)務上的判斷和寫入，但是不提交事務。賬務層面做資源的鎖定。
第二階段： 賬務資源鎖定成功，交易提交事務成功，然后發(fā)送confirm 給賬務。 如果交易提交失敗，則發(fā)送cancel對資源進行釋放。如果在confirm或者cancel出現異常情況下，同樣需要對異常進行處理來保證數據一致性。
總結： 這種方式實現難度不算太高，比較適合傳統(tǒng)的單體應用，在同一個方法中存在跨庫操作的情況。
回滾機制
在分布式架構中，功能 X，需要去協(xié)調后端的 A、B 甚至更多的原子服務。那么問題來了，假如 A 和 B 其中一個調用失敗了，那可怎么辦呢？ 這個時候，可以用回滾機制來保證一致性。 該機制應用在錢包配合信貸做的聯合放貸項目中。 該項目中總共有兩個原子操作，如下圖所示。
兩個原子操作，分別是資金歸集和資金到卡。所謂資金歸集，是將商戶A的錢和商戶B的錢歸集到中間商戶C。而資金到卡，是將中間商戶C的錢，通過銀行系統(tǒng)打入到D用戶的銀行卡。這兩個操作要滿足一致性，即資金歸集成功，然后打款到用戶的卡成功�；蛘呤巧虘鬉和B的錢沒變化，資金到卡失敗。 總而言之，是不允許資金停留在中間商戶C的。
針對這種情況，通過回滾機制，提供一個強大的回滾操作來實現上述的一致性。比如資金歸集成功，而資金到卡失敗，那么對歸集的資金操作做回滾處理，也就是資金從中間商戶C分別回到商戶A和B中。
總結： 這種方式缺點比較多，通常在復雜場景下是不推薦使用的，除非是非常簡單的場景，非常容易提供回滾，而且依賴的服務也非常少的情況。這種實現方式會造成代碼量龐大，耦合性高。而且非常有局限性，因為有很多的業(yè)務是無法很簡單的實現回滾的，如果串行的服務很多，回滾的成本實在太高。
本地消息表
這種實現方式的思路，其實是源于 ebay，后來通過支付寶等公司的布道，在業(yè)內廣泛使用。其基本的設計思想是將遠程分布式事務拆分成一系列的本地事務。如果不考慮性能及設計優(yōu)雅，借助關系型數據庫中的表即可實現。本地消息的方式，在應用在錢包非核心業(yè)務異步化改造項目中。該項目當時改造的方案如下：
1.核心業(yè)務實時寫入交易表
2.非核心業(yè)務非實時異步寫入交易表按照用戶維度的交易查詢表。
交易表是交易維度的，而為了滿足用戶的查詢性能，需要備份復制相同的按照用戶維度的交易查詢表。 從業(yè)務屬性上來看，交易表是核心業(yè)務，交易查詢表是非核心業(yè)務(查詢使用)。而實現上，交易表是核心數據庫，而查詢表則屬于非核心數據庫。 但是， 這兩者需要滿足一致性。 關于這類一致性保障，如果有不丟消息的消息隊列，則很容易解決。萬一沒有這類消息隊列呢？ 其實，使用本地消息表，也一樣可以解決。
如圖所示，是利用本地消息表保持最終一致性的應用。 具體如下：
1.業(yè)務A將本地消息和A業(yè)務數據以本地事務的方式寫入DB1；
2.業(yè)務A寫完本地事務后，發(fā)送消息給MQ。
3.MQ推送消息給業(yè)務B，業(yè)務B執(zhí)行消息，寫入DB2.
4.由于MQ不能保證消息不丟，如果消息丟失了，則需要通過業(yè)務C，讀取DB1的消息，然后rpc發(fā)送給業(yè)務B重新執(zhí)行。
當然，如何判斷DB1的消息已經消費，這個可以通過DB2的事務執(zhí)行結果來判斷。
總結： 上訴的方式是一種非常經典的實現，基本避免了分布式事務，實現了“最終一致性”。但是，關系型數據庫的吞吐量和性能方面存在瓶頸，頻繁的讀寫消息會給數據庫造成壓力。所以，在真正的高并發(fā)場景下，該方案也會有瓶頸和限制的。
補償機制
補償機制在分布式系統(tǒng)中，應用最為廣泛。在錢包應用的場景比較多，比如核心收銀臺和付款到卡。 核心收銀臺中，當請求銀行扣款，扣款成功后，自身系統(tǒng)掛掉了。這個時候就會有一個后臺程序，我們也稱作補單程序來開始處理這類流程，讓原來中間斷掉的流程繼續(xù)走下去。
一般成熟的系統(tǒng)中，對于級別較高的服務和接口，整體的可用性通常都會很高。如果有些業(yè)務由于瞬時的網絡故障或調用超時等問題，那么這種補償機制其實是非常有效的。
總結
本文通過核心系統(tǒng)的幾個具體實際項目，闡述了如何保證分布式系統(tǒng)的一致性。每一種方案都有一定的特征和應用場景。 其實分布式系統(tǒng)的事務一致性本身是一個技術難題，目前沒有一種很簡單很完美的方案能夠應對所有場景。具體還是要使用者根據不同的業(yè)務場景去抉擇。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.ezxoed.cn/
本文標題：分布式系統(tǒng)一致性保障方案總結
相關文章
