業務中臺資料一致性方案

引言

隨著業務的發展，微服務架構逐漸成為當下業務中臺的主流架構形式，它不但解決了各個應用之間的解耦問題，同時也解決了單體應用的性能問題實作可擴展可動態伸縮的能力，如下圖所示，業務中臺就是將平臺的通用能力進行下沉，避免重復建設，形成底座平臺能力，上層的各個應用服務都是基于中臺能力進行快速構建，但是隨著應用規模的擴大，原本在單體應用中不是問題的問題，在微服務架構中可能就是比較嚴重的問題，本文所要探討的服務之間的資料一致性便是其中最具代表性的問題，本文將結合常見的電商下單場景來說明業務中臺資料一致性方案，

資料一致性原理預備知識

在探討業務中臺資料一致性方案之前，我們先來一起回顧下資料庫事務的相關內容，通過對資料庫事務的分析，我們可以看出來在微服務架構中想要保證資料的一致性將會遇到什么樣的問題，

1、本地事務

事務的概念對于程式猿來說一定不陌生，這里的事務指的是資料庫事務，所謂資料庫事務，簡單來理解就是一套關于資料一致性維護的資料庫機制， 我們都知道，實際業務平臺大部分的業務資料還是保存在關系型資料庫中，在單體應用的時代，資料庫實體本身可以保證事務的有效性，
資料庫事務需要滿足四個基本特征：

（1）原子性（Atomicity）：極端主義者，要么大家一起成功，有一個失敗都不行

（2）一致性（Consistency）: 資料具有一致性，不存在狀態不確定的狀況

（3）隔離性（Isolation）：事務之間互相不干擾，你走你的陽關道，我走我的獨木橋

（4）永久性（Durability）：一旦事務提交后，資料就記錄就會被持久化

都說王守義 13 香，筆者最近也下單了一部 pro 準備換掉三年前的 iphone，那么我們以下單購買 iphone13 進行舉例說明，我們暫時將如下圖所示，如果在一個完整事務中，存在生成訂單、扣減庫存、增加積分以及發放優惠券這四項業務，那么要么這四項都成功，下單夠購買 13 香這個業務才算是成功，中間有一項失敗就會造成業務資料的不一致，因此需要進行事務回滾，回滾到下單前的狀態，以保證業務資料的一致性，

2、分布式事務

隨著業務的不斷發展，業務復雜度也在不斷的增長，企業基于微服務架構向下沉淀出了通用的業務中臺，資料的訪問形式變得復雜了，服務節點間的資料訪問通過 API 介面進行，原本單資料庫實體只能保證資料庫實體內部的事務，但是在跨資料庫實體以及分布式業務呼叫程序中，單資料庫實體已經無法保證全域事務的有效性，因此我們需要分布式的事務機制來保證各個服務節點之間的資料邏輯一致，否則就會出現如下的資料不一致的問題，

針對分布式場景下的資料一致性問題，業界提出了 CAP 理論以及 BASE 理論，同時在這些理論的基礎之上產生了相應的分布式事務解決方案，我們先來看下什么是 CAP 理論以及 BASE 理論，

CAP 理論

Consistency：資料一致性

Avalibility：資料可用性

Partition tolerance：磁區容錯性

任何一個分布式系統是沒法同時滿足 CAP 中的三項的，為什么這么說呢？我們來舉個簡單的例子來進行說明，如下圖所示，訂單服務將生成的訂服務寫入訂單資料主庫，同時將資料同步到訂單資料從庫中，訂單服務從從庫中進行訂單資料查詢，從人實作訂單資料的讀寫分離，那么我們繼續來看，當系統滿足磁區容錯性之后，資料一致性和資料可用性之間存在怎樣的矛盾，

如果必須實作資料的一致性，那么當訂單資料寫入主庫的時候，由于此時主庫還未將最新的訂單資料同步到從庫當中，因此主庫和從庫出現了資料不一致的情況，但是一致性又要求必須實作資料的強一致，那么此時的只好將從庫鎖住不對外提供服務，直到主庫資料同步到從庫后再開放訂單資料查詢，因此在 這個程序中無法同時滿足資料一致性以及可用性，

對應的 BASE 理論，其實就是一種 CAP 理論的實際權衡結果，既然無法做到強一致性，那么各個服務節點可以根據自身的業務特點實作資料的最終一致，所謂 BASE 理論指的就是：

a、Basically Available — 基本可用，畢竟對于分布式系統來說，可用性比資料一致性性要重要的多

b、Soft state — 軟狀態 指允許系統中的資料存在中間狀態，并認為該中間狀態的存在不會影響系統的整體可用性，即允許系統在不同節點的資料副本之間進行資料同步的程序中存在延時

c、Eventually consistent — 最終一致性，強調的是系統中所有的資料副本，在進過一段時間的同步后，最終能夠達到一個一致的狀態，最終一致性需要保證資料最終能夠一致而不需要保證資料實時的一致性，

看吧，實際上我們也不需要太為難我們自己，既然很難實作強一致性，那么實作最終一致性相對來說是一個非常劃算以及可行性較高的資料一致性解決方案，
有了前人大佬們總結的分布式理論，我們一起來看下幾種常見的分布式事務場景吧，

（1）一個事務中包含了多資料庫操作

我們還是以上面購買 13 香來舉個栗子，由于業務量的不斷攀升，之前的單資料庫實體已經無法滿足當前業務要求，因此我們將資料庫按照業務域進行了拆分，我們簡化下購物的業務流程，簡化后包括生成訂單、扣減庫存以及增加積分，因此一個購物事務中包括了三個資料庫的操作，但是資料庫實體只能保證自身的事務特性，不能保證全域的事務特性，如果訂單生成，但是庫存沒有扣減，積分沒有增加，將數顯資料不一致問題，因此出現了分布式事務問題，

（2）一個事務中包含了多服務訪問同一資料庫

隨著業務的發展，原先單體專案的模塊越來越多，維護起來成本較高，比如訂單模塊修改了但是庫存模塊沒有修改，但是發布的時候還是需要發布整個應用，萬一有個 Bug 啥的還要回滾，不能做到功能和維護上面的隔離，因此我們需要對應用不同的模塊進行拆分，那么原本的內部呼叫變成了兩個服務之間的遠程呼叫，原本的本地事務就演變成了分布式事務，

（3）一個事務包含了多個微服務呼叫資料不一致引發的問題

在微服務架構體系下面，原有的服務中的各個業務模塊經過縱向拆分后，成為一個個獨立的服務，如前面的購物業務流程，整個程序涉及到多個微服務，因此資料庫提供的事務機制，只能保證一個微服務節點的事務，同樣不能保證全域的事務，因此當一個微服務需要呼叫多個其他微服務完成對應的業務時，分布式事務的問題就會出現，

資料一致性解決方案

正是因為分布式微服務的復雜結構，因此給維護資料一致性帶來了一定的挑戰，但是由于分布式理論的發展與實踐，為我們解決分布式系統提供了理論依據，

分布式系統資料一致性的保證的關鍵點就在于如何實作和單系統一樣的事務控制，在單點系統階段，資料的一致性通過資料庫本身的機制進行保證，但是在分布式中臺系統中，資料一致性需要借助于外部的力量進行保證，

當下已經有較為成熟的資料一致性解決方案了，下面我們來具體分析下各個解決方案，我們按照分布式系統是否強調資料的強一致性，我們可以將分布式事務分為剛性事務以及柔性事務，

1、剛性事務
所謂的剛性事務就是追求資料的強一致性，必須滿足資料庫事務的 ACID 特性，典型的剛性事務解決方案就是 XA 模型，它通過引入一個事務協調者的角色，站在全域的角度來看分布式事務，將各個子域合并為一個大的分布式事務來實作資料的一致性，

但是在實際的高并發場景下基本不會使用這樣的分布式解決方案，主要原因有以下幾點，我們以 XA 模型中最常見的兩階段提交的方案來說明其存在的不足之處，

（1）單點故障問題：由于引入了分布式事務的全域協調者的角色，那么如果一旦全域協調者產生故障，那么各個子事務參與者并不能獲取事務執行結果狀態，導致子事務阻塞，因此我們需要花費很大精力去保證事務協調者的高可用，

（2）性能問題：在大型分布式系統高并發場景下，由于參與分布式事務的 RM 過多，因此網路通信次數、重試以及通信時間都會增加，導致可能的阻塞時間也會變長，從而降低了整個系統的吞吐狀況，

2、柔性事務

既然剛性事務在高并發場景下存在上述的問題，那么有沒有更好的資料一致性解決方案呢？這時候柔性分布式事務就派上用場了，柔性事務尊屬分布式事務的 BASE 理論，它允許一段時間內的系統之間資料的不一致，但是在最終狀態下需要保證事務的一致性，

（1）TCC 模式

所謂 TCC 模式即為 Try-Confirm-Cancel，它是二階段提交的一種實作方式，它包含的主要操作如下所示：

**Try：**嘗試執行業務，但是實際并沒有真正執行，只是進行資料檢查，鎖定業務資源，便于后續業務執行需要

**Confirm：**執行具體的業務操作，使用之前階段預留的業務資源資料

**Cancel：**如果在 try 階段某個事務執行失敗，則取消之前的業務操作

Try 階段：

這個階段主要實作嘗試執行對應的業務，可以理解為一種預備執行的狀態，因為在完成業務流程之前，并不知道各個業務節點或者可以理解為子事務是否可以正常執行，因此嘗試在各個子事務去預先執行，看看能不能正常處理，

回到我們這個購買 13 香的例子當中，訂單中心首先將訂單狀態修改為 UPDATING 狀態，而不是 COMPLETED 狀態，庫存中心可以將 13 香的庫存鎖住，積分中心同樣可以進行預增加積分，

Confirm 階段：

如果有幸進入這個階段，說明前期的 try 階段都已經處理成功了，即為訂單的狀態成功變更為 UPDATING 狀態，庫存中的訂單資料量已經被鎖定，用戶對應的購物積分已經預先增加了，這三個步驟都已經完美實作了，對應的 TCC 框架已經感知到各個 Try 階段的執行結果，因此在執行 Confirm 時候需要執行對應服務提供的 Confirm 介面去完成實際的資料提交，

TCC 框架需要分別呼叫各個服務的確認提交介面完成對應的本地事務提交，訂單服務需要將訂單狀態修改為訂單完成狀態、 庫存服務需要將將庫存進行真實的扣減，用戶積分服務為用戶增加相應的用戶積分，

Cancel 階段：

如果不幸走到這個階段，無論在哪個階段都需要對之前執行的所有擦偶作執行回滾，恢復原有資料，如在執行到積分添加的程序中出現例外，那么代表這個分支事務在執行中出現了問題，無法完成正常的事務提交，因此為了保證資料的一致性，需要將之前的資料進行回滾操作，

在整個 TCC 處理程序之中，還有一件事情需要特別注意，那就是為了保證業務的成功率，各個業務服務向 TCC 框架進行 confirm 以及 TCC 向各個業務服務進行 confirm 以及 cancel 的時候都需要進行例外重試，以保證執行的成功率，因此對應的業務服務需要進行冪等處理，防止重試導致的重復操作，

可以看得出來，TCC 模式下的微服務需要業務代碼重度耦合，實際編碼的體感很不好，需要借助于外部的 TCC 框架，同時需要在業務代碼中增加 Try、Cancel 處理流程需要的介面，上述的 TCC 解決方案，需要在用戶執行完下單操作之后依次執行訂單生成介面、庫存扣減介面以及用戶積分介面來完成整體的業務操作，但是在實際的業務場景中，我們大概率不會這么同步呼叫多個介面來完成具體業務，下面我們看看另外一種分布式資料一致性解決方案，

（2）可靠訊息最終一致性

在實際的平臺中，我們通常使用訊息事件來解決各個微服務之間的耦合問題，我們結合之前的購買 13 香的實際案例來進行說明，可靠訊息的事務模型實際上就是基于事件驅動架構，當用戶在購買 13 香之后，創建了 13 香的訂單并完成支付，向訊息中間件發送訂單已支付事件訊息，訂閱了訂單支付支付之間訊息的庫存服務、積分服務等，接收到對應的訂單支付訊息之后，執行其對應的業務流程，如扣減庫存以及增加用戶積分等，

從上述描述中我們可以看出來，可靠訊息最終一致性的方案中，訊息的可靠投遞是一切后續業務的重要前提，同時需要避免訊息的重復消費，因此對應監聽訊息的服務的業務介面需要實作冪等性，我們來看如下的偽代碼，

public void generateOrder（） {

	try{
    boolean result = orderRepo.saveOrder(orderMpdel);
    
    if(result) {
      mqSender.sendMessage(orderModel);
    }
      
    
  } catch(Exception e) {
    rollback();
  }


}

在上述代碼中，無論是本地訂單資料保存（本地事務）處理失敗還是異步訊息發送例外，我們都會進行訂單資料回滾，這代碼看上去沒有什么毛病，但是我們再仔細分析下是不是真的沒有什么問題嗎？

由于引入了訊息中間件，服務之間的呼叫不再是依次的同步呼叫，各自服務通過消費對應的訂單訊息來實作各自的業務，當用戶進行下單操作后，訂單服務會生成對應的訂單資訊，而后發送訂單生成訊息，但是由于是分布式系統，受網路等因素的影響，有可能出現訊息發送完成后訂單服務未接收到訊息中間件回傳的回應資訊，因此訂單服務將之前的訂單資料進行了回滾，但是積分服務已經將 MQ 中的訂單資訊進行了消費，增加了用戶積分，這就造成了訂單與積分資料不一致的情況， 另外如果在訂單生成之后，訂單服務掛掉了無法正常投遞訊息也會造成資料不一致的情況，

a、本地訊息表

通過本地訊息表的方式將分布式事務拆解為本地事務的實作，如下圖所示，將訂單生成以及訊息記錄表包裹在一個本地事務中，生成訂單資訊后同時在本地訊息表中插入一條訂單訊息發送記錄用以記錄訊息發送的狀態，如果訊息發送失敗則記錄狀態，訂單服務進行重試發送，超過重試次數后可以由定時服務進行定時掃描本地未完成狀態的訊息進行重新發行訊息，以保證訊息的正常投遞，

當訊息到達 MQ 之后，如果 MQ 進行了正常的回應則業務可以繼續，但是如果 MQ 未正常回應，則訂單服務認為 MQ 未能正常接收訊息需要不斷進行重試，

MQ 接收到訊息并進行持久化后，則回應訂單服務說我這里已經接收到你的訂單訊息了，接下來的事情就交給我我吧，此時訂單服務不再進行訊息發送重試，本地訊息表中的訊息狀態為已發送，

訊息發送成功后，積分服務將會消費對應的訂單訊息，但是如果積分服務在執行本地積分服務失敗后需要通知訂單服務將原來的訂單資訊進行回滾，

b、事務訊息

關于事務訊息，將在另外一篇文章詳細介紹，主要的思想是借助于 RocketMQ 的事務訊息機制，將分布式事務轉換為兩階段提交的解決方案，從而實作依托于訊息中間件的事務一致性解決方案，

總結

本文以最常見的電商購物案例為實際背景，圍繞如何實作業務中臺的資料一致性進行了詳細的說明，分別從分布式系統資料一致性問題產生的背景、相關的分布式事務理論以及基于理論之上產生的相應的解決方案總結了業務中臺的資料一致性的解決方案，重點闡述了柔分布式事務解決方案在業務中臺資料一致性實踐中的應用，