億級流量系統架構之如何保證百億流量下的數據一致性（中）？【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

目錄

1、多系統訂閱數據回顧

2、核心數據的監控系統

3、電商庫存數據如何監控

4、數據計算鏈路追蹤

5、百億流量下的數據鏈路追蹤

6、自動化數據鏈路分析

7、下篇預告

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

簡單來講，就是一個分佈式系統中的多個子系統（或者服務）協做處理一份數據，可是最後這個數據的最終結果卻沒有符合指望。

這是一種很是典型的數據不一致的問題。固然在分佈式系統中，數據不一致問題還有其餘的一些狀況。

好比說多個系統都要維護一份數據的多個副本，結果某個系統中的數據副本跟其餘的副本不一致，這也是數據不一致。

可是這幾篇文章，說的主要是咱們上篇文章分析的那種數據不一致的問題到底應該如何解決。

一、多系統訂閱數據回顧

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

好！經過上面這張圖，咱們來回顧一下以前作了系統解耦以後的一個架構圖。

其實，實時計算平臺會把數據計算的結果投遞到一個消息中間件裏。

而後，數據查詢平臺、數據質量監控系統、數據鏈路追蹤系統，各個系統都須要那個數據計算結果，都會去訂閱裏面的數據。

這個就是當前的一個架構，因此這個系列文章分析到這裏，你們也能夠反過來理解了以前爲何要作系統架構的解耦了。

由於一份核心數據，是不少系統均可能會須要的。經過引入MQ對架構解耦了以後，各個系統就能夠按需訂閱數據了。

二、核心數據的監控系統

若是要解決核心數據的不一致問題，首先就是要作核心數據的監控。

有些同窗會覺得這個監控就是用falcon之類的系統，作業務metrics監控就能夠了，可是其實並非這樣。

這種核心數據的監控，遠遠不是作一個metrics監控能夠解決的。

在咱們的實踐中，必需要本身開發一個核心數據的監控系統，在裏面按照本身的需求，針對複雜的數據校驗邏輯開發大量的監控代碼。

咱們用那個數據平臺項目來舉例，本身寫的數據質量監控系統，須要把核心的一些數據指標從MQ裏消費出來，這些數據指標都是實時計算平臺計算好的。

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

好比在這種數據類的系統裏，極可能對數據指標A的監控邏輯是以下這樣的：

• 數據指標A = 數據指標B + 數據指標C - 數據指標D * 24。

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

因此此時就有了一個很是簡單的思路：

1. 首先，這個數據監控系統從MQ裏消費到每個最新計算出來的核心數據指標
2. 而後根據預先定義好的監控公式，從數據查詢平臺裏調用接口獲取出來公式須要的其餘數據指標
3. 接着，按照公式進行監控計算。

若是監控計算事後發現幾個數據指標之間的關係竟然不符合預先定義好的那個規則，那麼此時就能夠立馬發送報警了（短信、郵件、IM通知）。

工程師接到這報警以後，就能夠立馬開始排查，爲何這個數據竟然會不符合預先定義好的一套業務規則呢。

這樣就能夠解決數據問題的第一個痛點：不須要等待用戶發現後反饋給客服了，本身系統第一時間就發現了數據的異常。

一樣，給你們上一張圖，直觀的感覺一下。

三、電商庫存數據如何監控

若是用電商裏的庫存數據來舉例也是同樣的，假設你想要監控電商系統中的核心數據：庫存數據。

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

也就是說，在完全的服務化中，你要保證全部的子系統 / 服務若是有任何庫存更新的操做，所有走接口調用請求庫存服務。只能是庫存服務來負責庫存數據在數據庫層面的更新操做，這樣就完成了收口。

收口了以後作庫存數據的監控就好辦了，徹底能夠採用MySQL binlog採集的技術，直接用Mysql binlog同步中間件來監控數據庫中庫存數據涉及到的表和字段。

只要庫存服務對應的數據庫中的表涉及到增刪改操做，都會被Mysql binlog同步中間件採集後，發送到數據監控系統中去。

此時，數據監控系統就能夠採用預先定義好的庫存數據監控邏輯，來查驗這個庫存數據是否準確。

這個監控邏輯能夠是不少種的，好比能夠後臺走異步線程請求到實際的C/S架構的倉儲系統中，查一下實際的庫存數量。

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

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

固然，這就是舉個例子，實際如何監控，你們根據本身的業務來作就行了。

四、數據計算鏈路追蹤

此時咱們已經解決了第一個問題，主動監控系統中的少數核心數據，在第一時間能夠本身先收到報警發現核心是護具備異常。

可是此時咱們還須要解決第二個問題，那就是當你發現核心數據出錯以後，如何快速的排查問題到底出在哪裏？

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

很簡單，此時咱們必需要作數據計算鏈路的追蹤。

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

好比說：

• 步驟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沒有按照你們約定好的規則來更新庫存，結果就致使庫存數據出錯。

這個，就是排查覈心數據問題的一個通用思路。

五、百億流量下的數據鏈路追蹤

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

其實給你們比較推薦的，是用elasticsearch技術來作這種數據鏈路的存儲。

由於es一方面是分佈式的，支持海量數據的存儲。

並且他能夠作高性能的分佈式檢索，後續在排查數據問題的時候，是須要對海量數據作高性能的多條件檢索的。

因此，咱們徹底能夠獨立出來一個數據鏈路追蹤系統，並設置以下操做：

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

• 而後，數據鏈路追蹤系統就能夠把計算鏈路日誌落地到存儲裏去，按照必定的規則創建好對應的索引字段。

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

此時一旦發現某個數據出錯，就能夠當即根據這條數據的id，從es裏提取出來歷史上全部的計算鏈路。

並且還能夠給數據鏈路追蹤系統開發一套用戶友好的前端界面，好比在界面上能夠按照請求id展現出來每次請求對應的一系列技術步驟組成的鏈路。

此時會有什麼樣的體驗呢？咱們立馬能夠清晰的看到是哪一次計算鏈路致使了數據的出錯，以及過程當中每個子系統 / 服務對數據作了什麼樣的修改。

而後，咱們就能夠追本溯源，直接定位到出錯的邏輯，進行分析和修改。

說了那麼多，仍是給你們來一張圖，一塊兒來感覺一下這個過程。

六、自動化數據鏈路分析

到這裏爲止，你們若是能在本身公司的大規模分佈式系統中，落地上述那套數據監控 + 鏈路追蹤的機制，就已經能夠很是好的保證核心數據的準確性了。

經過這套機制，核心數據出錯時，第一時間能夠收到報警，並且能夠立馬拉出數據計算鏈路，快速的分析數據爲什麼出錯。

可是，若是要更進一步的節省排查數據出錯問題的人力，那麼能夠在數據鏈路追蹤系統裏面加入一套自動化數據鏈路分析的機制。

你們能夠反向思考一下，假如說如今你發現數據出錯，並且手頭有數據計算鏈路，你會怎麼檢查？

不用說，固然是你們坐在一塊兒唾沫橫飛的分析了，人腦分析。

好比說，步驟A按理說執行完了應該數據是X，步驟B按理說執行完了應該數據是Y，步驟C按理說執行完了應該數據是Z。

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

而後去步驟C看看，發現原來是服務C更新的，此時服務C的負責人開始吭哧吭哧的排查本身的代碼，看看到底爲何接收到一個數據Y以後，本身的代碼會處理成數據ZZZ，而不是數據Z呢？

最後，找到了代碼問題，此時就ok了，在本地再次復現數據錯誤，而後修復bug後上線便可。

因此，這個過程的前半部分，是徹底能夠自動化的。也就是你寫一套自動分析數據鏈路的代碼，就模擬你人腦分析鏈路的邏輯便可，自動一步步分析每一個步驟的計算結果。這樣就能夠把數據監控系統和鏈路追蹤系統打通了。

一旦數據監控系統發現數據出錯，立馬能夠調用鏈路追蹤系統的接口，進行自動化的鏈路分析，看看本次數據出錯，究竟是鏈路中的哪一個服務bug致使的數據問題。

接着，將全部的信息彙總起來，發送一個報警通知給相關人等。

相關人員看到報警以後，一目瞭然，全部人立馬知道本次數據出錯，是鏈路中的哪一個步驟，哪一個服務致使的。

最後，那個服務的負責人就能夠立馬根據報警信息，排查本身的系統中的代碼了。

七、下篇預告

到這篇文章爲止，咱們基本上梳理清楚了大規模的負責分佈式系統中，如何保證核心數據的一致性。

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

敬請期待：

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

end

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算

1三、億級流量系統架構之如何設計高容錯分佈式計算系統

1四、億級流量系統架構之如何設計承載百億流量的高性能架構

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

1六、億級流量系統架構之如何設計全鏈路99.99%高可用架構

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

3二、【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

3三、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？

3四、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？

3五、億級流量系統架構之如何在上萬併發場景下設計可擴展架構（下）？

3六、億級流量架構第二彈：你的系統真的無懈可擊嗎？

3七、億級流量系統架構之如何保證百億流量下的數據一致性（上）

做者：石杉的架構筆記 連接：https://juejin.im/post/5c263a936fb9a049ec6b2688 來源：掘金 著做權歸做者全部，轉載請聯繫做者得到受權！