數據一致性檢測的應用場景與最佳實踐

隨着業務規模的擴張，企業系統變得愈來愈複雜，在這種複雜的分佈式系統架構下，不免會出現遠程調用失敗，消息發送失敗，併發 bug 等等問題，這些問題最終會致使系統間的數據不一致，致使用戶體驗受損，用戶利益受損，對平臺來講就是產生資損。所以如何持續保障系統的業務穩定性對於企業來講是一個很重要的課題，本文旨在介紹一些常見業務應用場景下的業務數據一致性保障最佳實踐。

離線or在線,事前or過後

應對業務數據不一致問題的常規操做是，配置定時任務，在每一個固定時間點去拉取歷史一段時間的數據出來進行比對，判斷是否有數據故障出現，好比利用hadoop作一些批處理MapReduce做業，這種離線計算的方式時效性比較差，對於電商系統或者對於實時性要求較高的系統來講，問題發現的越晚損失也就越大，因此咱們須要一種在線的校驗模式來實時發現數據不一致問題。

在線的校驗模式指的是每出現一筆數據就進行一次比對，這種比對方式還能夠分爲事前和過後比對。

• 事前比對是一種業務強耦合的校驗方式，咱們在業務系統代碼中進行相似 AOP 的操做，橫插一段校驗代碼，若是校驗發現問題，則阻斷此次業務操做，這種模式雖然時效性很高，可以保證每一筆數據的正確性，可是由於和業務耦合的過重，很容易出現一些災難性的問題，好比校驗代碼的性能差或者異常處理不正確，會直接致使業務操做受阻，影響正常業務活動。
• 過後校驗嚴格上來講不能算是實時校驗，由於校驗的時間點滯後於真實的業務動做發生時間點，這算是一種準實時校驗，這種校驗的好處在於，能夠和業務解耦，不阻斷業務的正常進行，還能較爲"實時"的發現數據不一致問題，而且在一些特殊場景下(好比異步業務，下面會介紹)只能使用過後校驗，缺點也很明顯，就是時效性相比於事前校驗來講會比較差。

這裏在囉嗦一句，可能讀到這裏，有些人會問，既然是業務動做發生以後再進行校驗，它的意義還有多大呢？的確相比於事前校驗來講，他並不能保證每一筆數據都正確，可是在實際操做中，像電商這種場景下，咱們進行業務功能迭代，會通過平常環境 -> 預發環境 -> Beta測試 -> 線上環境的流程，尤爲是在預發環境和 Beta 測試的狀況下，通常會進行一些線上引流或者模擬數據測試，特色是量小，即便發生問題也只是局部不會引發災難，那在這種場景下，過後校驗的意義就顯得很大，能夠提早驗證功能和數據的正確性，又不會對線上形成強耦合的影響；在功能徹底上線後，過後校驗的做用在於及時發現數據不一致問題，避免問題的進一步擴散。

綜上所述，對於業務數據校驗時效性不是那麼高的場景下，離線校驗是一種比較合適的方式，開發接入成本都較低，對於業務數據校驗時效性有一些要求的場景下，過後校驗是一種比較適合的方式，對於業務校驗時效性要求很是嚴格，而且可以投入較多資源的狀況下，事前校驗比較適合。

數據一致性檢測實踐案例

案例一:會員系統

某店鋪會員入會業務，須要結合店鋪系統、打標系統、會員系統進行入會退會操做，以下圖所示:

在這個業務場景中，買家在店鋪會員頁發起入會申請，入會成功對外發送會員入會metaq消息，下游業務系統根據這個metaq消息，爲該用戶打上一個標籤，用戶在下單的時候就根據這個標籤判斷是否有優先購買的權利。既然有入會就有退會，退會一樣發起metaq消息給用戶進行去標操做。因此無論入會仍是退會，業務上要求店鋪系統的會員狀態（入會仍是退會）必須和用戶系統的標籤狀態一致（有或者沒有），一旦發現數據不一致，一個已經退會的用戶若是還有用戶會員標籤，該用戶就能夠購買這個限購商品，這樣就會形成商家資損。所以必須有對帳業務對數據一致性進行強保證，一旦發現數據不一致，必需要通知相關人員進行數據覈對，若有問題則進行數據訂正。

這個案例在對帳系統的選擇上有以下幾個要求:

1. 實時：必須當天儘快處理。
2. 能夠報警
3. 必須支持不一樣領域模型。
4. 接口調用須要有必定的延遲，以便下游系統處理完全部流程以後再校驗。
5. 因爲入會、退會metaq可能會有丟失或者亂序的狀況，所以不能夠根據該消息進行對帳。

在這個業務場景下，咱們能夠看到，業務是異步的，會員系統發起入會操做後，並非馬上就能在用戶系統打標的，因此實時的事前校驗並不適合這個場景，由於在會員系統發起入會操做的時候在用戶系統中還查不到這個打標狀態，須要延遲一段時間去查，因此只能用過後校驗來作。

咱們在這個場景的作法是：拉取店鋪會員數據庫的實時binlog日誌數據，給到校驗系統，校驗系統解析日誌數據拿到要打標的會員id，而且延時一段時間後去會員系統查詢這個會員的入會狀態，和日誌中的狀態進行一致性比對，發現不一致則進行告警。

案例二:新老庫遷移

當新老系統須要進行更替的時候，常常會涉及到數據遷移，因爲數據量很是大，並且不容許停機，因此遷移必定是一個按部就班的過程，整個過程會分紅兩個部分，第一個部分是雙寫，保證新增數據兩邊同步。第二步是開始作存量數據遷移，經過後臺任務慢慢跑。在這個過程當中可能會出現部分字段沒有同步，更新數據順序錯亂致使數據內容不一致的問題，因此須要對遷移進行數據的一致性檢查，及時發現數據問題進行訂正或者bug修復。

因爲咱們的目的是將數據遷移到新系統，因此數據校驗觸發條件就是新系統有數據寫入，這裏可能有人會問若是老系統同步失敗呢，那麼新系統就不會有數據寫入，就觸發不了校驗。這裏就存在校驗邊界的問題，即咱們假設同步系統是必定會同步成功的，若是同步失敗的話不容許跳過會一直嘗試重試同步，因此這裏若是發生同步失敗，同步會暫停而且打印出同步錯誤日誌，這個就不是校驗系統的問題了，咱們會經過同步的進度或者同步日誌來觀察到這個現象。

因此咱們在這個場景的作法是:接收新庫的數據庫變動binlog日誌數據，解析日誌內容，經過這條數據id去查詢舊庫的對應數據，進行數據內容的比對。因爲雙寫的存在，一條數據可能會變動屢次，這裏就要求咱們的校驗必須是較爲實時的進行，不然就會出現拿到的日誌數據內容是舊的(這條數據又發生了更新)，致使查詢老庫的數據出現不一致的問題，其實算是一種誤報。

 

 

 

隨着業務規模的擴張，企業系統變得愈來愈複雜，在這種複雜的分佈式系統架構下，不免會出現遠程調用失敗，消息發送失敗，併發 bug 等等問題，這些問題最終會致使系統間的數據不一致，致使用戶體驗受損，用戶利益受損，對平臺來講就是產生資損。所以如何持續保障系統的業務穩定性對於企業來講是一個很重要的課題，本文旨在介紹一些常見業務應用場景下的業務數據一致性保障最佳實踐。

離線or在線,事前or過後

應對業務數據不一致問題的常規操做是，配置定時任務，在每一個固定時間點去拉取歷史一段時間的數據出來進行比對，判斷是否有數據故障出現，好比利用hadoop作一些批處理MapReduce做業，這種離線計算的方式時效性比較差，對於電商系統或者對於實時性要求較高的系統來講，問題發現的越晚損失也就越大，因此咱們須要一種在線的校驗模式來實時發現數據不一致問題。

在線的校驗模式指的是每出現一筆數據就進行一次比對，這種比對方式還能夠分爲事前和過後比對。

• 事前比對是一種業務強耦合的校驗方式，咱們在業務系統代碼中進行相似 AOP 的操做，橫插一段校驗代碼，若是校驗發現問題，則阻斷此次業務操做，這種模式雖然時效性很高，可以保證每一筆數據的正確性，可是由於和業務耦合的過重，很容易出現一些災難性的問題，好比校驗代碼的性能差或者異常處理不正確，會直接致使業務操做受阻，影響正常業務活動。
• 過後校驗嚴格上來講不能算是實時校驗，由於校驗的時間點滯後於真實的業務動做發生時間點，這算是一種準實時校驗，這種校驗的好處在於，能夠和業務解耦，不阻斷業務的正常進行，還能較爲"實時"的發現數據不一致問題，而且在一些特殊場景下(好比異步業務，下面會介紹)只能使用過後校驗，缺點也很明顯，就是時效性相比於事前校驗來講會比較差。

這裏在囉嗦一句，可能讀到這裏，有些人會問，既然是業務動做發生以後再進行校驗，它的意義還有多大呢？的確相比於事前校驗來講，他並不能保證每一筆數據都正確，可是在實際操做中，像電商這種場景下，咱們進行業務功能迭代，會通過平常環境 -> 預發環境 -> Beta測試 -> 線上環境的流程，尤爲是在預發環境和 Beta 測試的狀況下，通常會進行一些線上引流或者模擬數據測試，特色是量小，即便發生問題也只是局部不會引發災難，那在這種場景下，過後校驗的意義就顯得很大，能夠提早驗證功能和數據的正確性，又不會對線上形成強耦合的影響；在功能徹底上線後，過後校驗的做用在於及時發現數據不一致問題，避免問題的進一步擴散。

綜上所述，對於業務數據校驗時效性不是那麼高的場景下，離線校驗是一種比較合適的方式，開發接入成本都較低，對於業務數據校驗時效性有一些要求的場景下，過後校驗是一種比較適合的方式，對於業務校驗時效性要求很是嚴格，而且可以投入較多資源的狀況下，事前校驗比較適合。

數據一致性檢測實踐案例

案例一:會員系統

某店鋪會員入會業務，須要結合店鋪系統、打標系統、會員系統進行入會退會操做，以下圖所示:

在這個業務場景中，買家在店鋪會員頁發起入會申請，入會成功對外發送會員入會metaq消息，下游業務系統根據這個metaq消息，爲該用戶打上一個標籤，用戶在下單的時候就根據這個標籤判斷是否有優先購買的權利。既然有入會就有退會，退會一樣發起metaq消息給用戶進行去標操做。因此無論入會仍是退會，業務上要求店鋪系統的會員狀態（入會仍是退會）必須和用戶系統的標籤狀態一致（有或者沒有），一旦發現數據不一致，一個已經退會的用戶若是還有用戶會員標籤，該用戶就能夠購買這個限購商品，這樣就會形成商家資損。所以必須有對帳業務對數據一致性進行強保證，一旦發現數據不一致，必需要通知相關人員進行數據覈對，若有問題則進行數據訂正。

這個案例在對帳系統的選擇上有以下幾個要求:

1. 實時：必須當天儘快處理。
2. 能夠報警
3. 必須支持不一樣領域模型。
4. 接口調用須要有必定的延遲，以便下游系統處理完全部流程以後再校驗。
5. 因爲入會、退會metaq可能會有丟失或者亂序的狀況，所以不能夠根據該消息進行對帳。

在這個業務場景下，咱們能夠看到，業務是異步的，會員系統發起入會操做後，並非馬上就能在用戶系統打標的，因此實時的事前校驗並不適合這個場景，由於在會員系統發起入會操做的時候在用戶系統中還查不到這個打標狀態，須要延遲一段時間去查，因此只能用過後校驗來作。

咱們在這個場景的作法是：拉取店鋪會員數據庫的實時binlog日誌數據，給到校驗系統，校驗系統解析日誌數據拿到要打標的會員id，而且延時一段時間後去會員系統查詢這個會員的入會狀態，和日誌中的狀態進行一致性比對，發現不一致則進行告警。

案例二:新老庫遷移

當新老系統須要進行更替的時候，常常會涉及到數據遷移，因爲數據量很是大，並且不容許停機，因此遷移必定是一個按部就班的過程，整個過程會分紅兩個部分，第一個部分是雙寫，保證新增數據兩邊同步。第二步是開始作存量數據遷移，經過後臺任務慢慢跑。在這個過程當中可能會出現部分字段沒有同步，更新數據順序錯亂致使數據內容不一致的問題，因此須要對遷移進行數據的一致性檢查，及時發現數據問題進行訂正或者bug修復。

因爲咱們的目的是將數據遷移到新系統，因此數據校驗觸發條件就是新系統有數據寫入，這裏可能有人會問若是老系統同步失敗呢，那麼新系統就不會有數據寫入，就觸發不了校驗。這裏就存在校驗邊界的問題，即咱們假設同步系統是必定會同步成功的，若是同步失敗的話不容許跳過會一直嘗試重試同步，因此這裏若是發生同步失敗，同步會暫停而且打印出同步錯誤日誌，這個就不是校驗系統的問題了，咱們會經過同步的進度或者同步日誌來觀察到這個現象。

因此咱們在這個場景的作法是:接收新庫的數據庫變動binlog日誌數據，解析日誌內容，經過這條數據id去查詢舊庫的對應數據，進行數據內容的比對。因爲雙寫的存在，一條數據可能會變動屢次，這裏就要求咱們的校驗必須是較爲實時的進行，不然就會出現拿到的日誌數據內容是舊的(這條數據又發生了更新)，致使查詢老庫的數據出現不一致的問題，其實算是一種誤報。

 

 

 

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。