目錄

一、多系統訂閱資料回顧

二、核心資料的監控系統

三、電商庫存資料如何監控

四、資料計算鏈路追蹤

五、百億流量下的資料鏈路追蹤

六、自動化資料鏈路分析

七、下篇預告

上篇文章《億級流量系統架構之如何保證百億流量下的資料一致性（上 ）》，初步給大家分析了一下，一個複雜的分散式系統中，資料不一致的問題是怎麼產生的。

簡單來說，就是一個分散式系統中的多個子系統（或者服務）協作處理一份資料，但是最後這個資料的最終結果卻沒有符合期望。

這是一種非常典型的資料不一致的問題。當然在分散式系統中，資料不一致問題還有其他的一些情況。

比如說多個系統都要維護一份資料的多個副本，結果某個系統中的資料副本跟其他的副本不一致，這也是資料不一致。

但是這幾篇文章，說的主要是我們上篇文章分析的那種資料不一致的問題到底應該如何解決。

1、多系統訂閱資料回顧

我們先來看一張圖，是之前講系統架構解耦的時候用的一張圖。

好！通過上面這張圖，我們來回顧一下之前做了系統解耦之後的一個架構圖。

其實，實時計算平臺會把資料計算的結果投遞到一個訊息中介軟體裡。

然後，資料查詢平臺、資料質量監控系統、資料鏈路追蹤系統，各個系統都需要那個資料計算結果，都會去訂閱裡面的資料。

這個就是當前的一個架構，所以這個系列文章分析到這裡，大家也可以反過來理解了之前為什麼要做系統架構的解耦了。

因為一份核心資料，是很多系統都可能會需要的。通過引入MQ對架構解耦了之後，各個系統就可以按需訂閱資料了。

2、核心資料的監控系統

如果要解決核心資料的不一致問題，首先就是要做核心資料的監控。

有些同學會以為這個監控就是用falcon之類的系統，做業務metrics監控就可以了，但是其實並不是這樣。

這種核心資料的監控，遠遠不是做一個metrics監控可以解決的。

在我們的實踐中，必須要自己開發一個核心資料的監控系統，在裡面按照自己的需求，針對複雜的資料校驗邏輯開發大量的監控程式碼。

我們用那個資料平臺專案來舉例，自己寫的資料質量監控系統，需要把核心的一些資料指標從MQ裡消費出來，這些資料指標都是實時計算平臺計算好的。

那麼此時，就需要自定義一套監控邏輯了，這種監控邏輯，不同的系統都是完全不一樣的。

比如在這種資料類的系統裡，很可能對資料指標A的監控邏輯是如下這樣的：

• 資料指標A = 資料指標B + 資料指標C - 資料指標D * 24。

每個核心指標都是有自己的一個監控公式的，這個監控公式，就是負責開發實時計算平臺的同學，他們寫的資料計算邏輯，是知道資料指標之間的邏輯關係的。

所以此時就有了一個非常簡單的思路：

1. 首先，這個資料監控系統從MQ裡消費到每一個最新計算出來的核心資料指標
2. 然後根據預先定義好的監控公式，從資料查詢平臺裡呼叫介面獲取出來公式需要的其他資料指標
3. 接著，按照公式進行監控計算。

如果監控計算過後發現幾個資料指標之間的關係居然不符合預先定義好的那個規則，那麼此時就可以立馬傳送報警了（簡訊、郵件、IM通知）。

工程師接到這報警之後，就可以立馬開始排查，為什麼這個資料居然會不符合預先定義好的一套業務規則呢。

這樣就可以解決資料問題的第一個痛點：不需要等待使用者發現後反饋給客服了，自己系統第一時間就發現了資料的異常。

同樣，給大家上一張圖，直觀的感受一下。

3、電商庫存資料如何監控

如果用電商裡的庫存資料來舉例也是一樣的，假設你想要監控電商系統中的核心資料：庫存資料。

首先第一步，在微服務架構中，你必須要收口。

也就是說，在徹底的服務化中，你要保證所有的子系統 / 服務如果有任何庫存更新的操作，全部走介面呼叫請求庫存服務。只能是庫存服務來負責庫存資料在資料庫層面的更新操作，這樣就完成了收口。

收口了之後做庫存資料的監控就好辦了，完全可以採用MySQL binlog採集的技術，直接用Mysql binlog同步中介軟體來監控資料庫中庫存資料涉及到的表和欄位。

只要庫存服務對應的資料庫中的表涉及到增刪改操作，都會被Mysql binlog同步中介軟體採集後，傳送到資料監控系統中去。

此時，資料監控系統就可以採用預先定義好的庫存資料監控邏輯，來查驗這個庫存資料是否準確。

這個監控邏輯可以是很多種的，比如可以後臺走非同步執行緒請求到實際的C/S架構的倉儲系統中，查一下實際的庫存數量。

或者是根據一定的庫存邏輯來校驗一下，舉個例子：

• 虛擬庫存 + 預售庫存 + 凍結庫存 + 可銷售庫存 = 總可用庫存數

當然，這就是舉個例子，實際如何監控，大家根據自己的業務來做就好了。

4、資料計算鏈路追蹤

此時我們已經解決了第一個問題，主動監控系統中的少數核心資料，在第一時間可以自己先收到報警發現核心是護具有異常。

但是此時我們還需要解決第二個問題，那就是當你發現核心資料出錯之後，如何快速的排查問題到底出在哪裡？

比如，你發現資料平臺的某個核心指標出錯，或者是電商系統的某個商品庫存資料出錯，此時你要排查資料到底為什麼錯了，應該怎麼辦呢？

很簡單，此時我們必須要做資料計算鏈路的追蹤。

也就是說，你必須要知道這個資料從最開始到底是經歷了哪些環節和步驟，每個環節到底如何更新了資料，更新後的資料又是什麼，還有要記錄下來每次資料變更後的監控檢查點。

比如說：

• 步驟A -> 步驟B -> 步驟C -> 2018-01-01 10:00:00

第一次資料更新後，資料監控檢查點，資料校驗情況是準確，庫存資料值為1365；

• 步驟A -> 步驟B -> 步驟D -> 步驟C -> 2018-01-01 11:05:00

第二次資料更新後，資料監控檢查點，資料校驗情況是錯誤，庫存資料值為1214

類似上面的那種資料計算鏈路的追蹤，是必須要做的。

因為你必須要知道一個核心資料，他每次更新一次值經歷了哪些中間步驟，哪些服務更新過他，那一次資料變更對應的資料監控結果如何。

此時，如果你發現一個庫存資料出錯了，立馬可以人肉搜出來這個資料過往的歷史計算鏈路。

你可以看到這條資料從一開始出現，然後每一次變更的計算鏈路和監控結果。

比如上面那個舉例，你可能發現第二次庫存資料更新後結果是1214，這個值是錯誤的。

然後你一看，發現其實第一次更新的結果是正確的，但是第二次更新的計算鏈路中多了一個步驟D出來，那麼可能這個步驟D是服務D做了一個更新。

此時，你就可以找服務D的服務人問問，結果可能就會發現，原來服務D沒有按照大家約定好的規則來更新庫存，結果就導致庫存資料出錯。

這個，就是排查核心資料問題的一個通用思路。

5、百億流量下的資料鏈路追蹤

如果要做資料計算鏈路，其實要解決的技術問題只有一個，那就是在百億流量的高併發下，任何一個核心資料每天的計算鏈路可能都是上億的，此時你應該如何儲存呢？

其實給大家比較推薦的，是用elasticsearch技術來做這種資料鏈路的儲存。

因為es一方面是分散式的，支援海量資料的儲存。

而且他可以做高效能的分散式檢索，後續在排查資料問題的時候，是需要對海量資料做高效能的多條件檢索的。

所以，我們完全可以獨立出來一個資料鏈路追蹤系統，並設定如下操作：

• 資料計算過程中涉及到的各個服務，都需要對核心資料的處理髮送一條計算鏈路日誌到資料鏈路追蹤系統。

• 然後，資料鏈路追蹤系統就可以把計算鏈路日誌落地到儲存裡去，按照一定的規則建立好對應的索引欄位。

• 舉個例子，索引欄位：核心資料名稱，核心資料id，本次請求id，計算節點序號，本次監控結果，子系統名稱，服務名稱，計算資料內容，等等。

此時一旦發現某個資料出錯，就可以立即根據這條資料的id，從es裡提取出來歷史上所有的計算鏈路。

而且還可以給資料鏈路追蹤系統開發一套使用者友好的前端介面，比如在介面上可以按照請求id展示出來每次請求對應的一系列技術步驟組成的鏈路。

此時會有什麼樣的體驗呢？我們立馬可以清晰的看到是哪一次計算鏈路導致了資料的出錯，以及過程中每一個子系統 / 服務對資料做了什麼樣的修改。

然後，我們就可以追本溯源，直接定位到出錯的邏輯，進行分析和修改。

說了那麼多，還是給大家來一張圖，一起來感受一下這個過程。

6、自動化資料鏈路分析

到這裡為止，大家如果能在自己公司的大規模分散式系統中，落地上述那套資料監控 + 鏈路追蹤的機制，就已經可以非常好的保證核心資料的準確性了。

通過這套機制，核心資料出錯時，第一時間可以收到報警，而且可以立馬拉出資料計算鏈路，快速的分析資料為何出錯。

但是，如果要更進一步的節省排查資料出錯問題的人力，那麼可以在資料鏈路追蹤系統裡面加入一套自動化資料鏈路分析的機制。

大家可以反向思考一下，假如說現在你發現資料出錯，而且手頭有資料計算鏈路，你會怎麼檢查？

不用說，當然是大家坐在一起唾沫橫飛的分析了，人腦分析。

比如說，步驟A按理說執行完了應該資料是X，步驟B按理說執行完了應該資料是Y，步驟C按理說執行完了應該資料是Z。

結果，誒！步驟C執行完了怎麼資料是ZZZ呢？？看來問題就出在步驟C了！

然後去步驟C看看，發現原來是服務C更新的，此時服務C的負責人開始吭哧吭哧的排查自己的程式碼，看看到底為什麼接收到一個資料Y之後，自己的程式碼會處理成資料ZZZ，而不是資料Z呢？

最後，找到了程式碼問題，此時就ok了，在本地再次復現資料錯誤，然後修復bug後上線即可。

所以，這個過程的前半部分，是完全可以自動化的。也就是你寫一套自動分析資料鏈路的程式碼，就模擬你人腦分析鏈路的邏輯即可，自動一步步分析每個步驟的計算結果。這樣就可以把資料監控系統和鏈路追蹤系統打通了。

一旦資料監控系統發現資料出錯，立馬可以呼叫鏈路追蹤系統的介面，進行自動化的鏈路分析，看看本次資料出錯，到底是鏈路中的哪個服務bug導致的資料問題。

接著，將所有的資訊彙總起來，傳送一個報警通知給相關人等。

相關人員看到報警之後，一目瞭然，所有人立馬知道本次資料出錯，是鏈路中的哪個步驟，哪個服務導致的。

最後，那個服務的負責人就可以立馬根據報警資訊，排查自己的系統中的程式碼了。

7、下篇預告

到這篇文章為止，我們基本上梳理清楚了大規模的負責分散式系統中，如何保證核心資料的一致性。

那麼下篇文章，我們再就技術實現中涉及到的一些MQ技術的細節，基於RabbitMQ來進行更進一步的分析。

敬請期待：

億級流量系統架構之如何保證百億流量下的資料一致性（下）？

end