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

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

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

目錄

1、前情提示

2、什麼是數據一致性？

3、一個數據計算鏈路的梳理

4、數據計算鏈路的bug

5、電商庫存數據的不一致問題

6、大型系統的數據不一致排查有多困難

7、下篇預告

1、前情提示

這篇文章，我們繼續來聊聊以前的億級流量架構的演進，以前對這個系列的文章已經更新到了可擴展架構的設計，若是有不太清楚的同窗，建議必定先回看一下以前的文章：

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

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

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

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

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

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

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

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

老規矩！咱們首先看一下這個複雜的系統架構演進到當前階段，總體的架構圖是什麼樣子的。

筆者再次友情提醒，若是各位小夥伴對下面這個複雜的架構圖還有什麼不理解的地方，必定要先回看以前的文章，由於系列文必須對上下文有清晰的理解和認識。

接着文本咱們來聊聊一個核心繫統天天承載百億流量的背景下，應該如何來保證複雜系統中的數據一致性？

2、什麼是數據一致性？

簡單來講，在一個複雜的系統中必定會對一些數據作出很是複雜的處理，並且多是多個不一樣的子系統，甚至是多個服務。

對一個數據按照必定的順序依次作出複雜的業務邏輯的執行，最終可能就會生產出一份寶貴的系統核心數據，落地到存儲裏去，好比說在數據庫裏存儲。

給你們來一張手繪彩圖，感覺下這個現場的氛圍：

從上圖中咱們就能夠看到，多個系統如何對一個數據依次進行處理，最終拿到一份核心數據，並落地到存儲裏去。

那麼在這個過程當中，就可能會產生所謂的數據不一致的問題。

什麼意思呢？給你們舉一個最簡單的例子，咱們原本指望數據的變化過程是：數據1 -> 數據2 -> 數據3 -> 數據4。

那麼最後落地到數據庫裏的應該是數據4，對不對？

結果呢？不知道爲啥，通過上面那個複雜的分佈式系統中的各個子系統，或者是各個服務的協做處理，最後竟然搞出來一個數據87。

搞了半天，搞了一個跟數據4風馬牛不相及的一個東西，最後落地到了數據庫裏。

而後啊，這套系統的最終用戶，可能經過前臺的界面看到了一個莫名其妙的數據87。

這就尷尬了，用戶明顯會以爲這個數據有錯誤，就會反饋給公司的客服，此時就會上報bug到工程師團隊，你們就開始吭哧吭哧的找問題。

上面說的這個場景，其實就是一種數據不一致的問題，也是咱們接下來幾篇文章要討論的一個問題。

實際上，在任何一個大規模分佈式系統裏，都會存在相似的問題。不管是電商，O2O，仍是本文舉例的數據平臺系統，都同樣。

3、一個數據計算鏈路的梳理

那麼既然已經明確了問題，接下來就來看看在數據平臺這個系統裏，究竟是什麼問題可能會致使一個最終落地存儲的數據的異常呢？

要明白這個問題，我們先回過頭看看，在以前提過的數據平臺這個項目裏，一個最終落地的數據的計算鏈路是什麼樣的？

你們看看下面的圖：

如上圖所示，其實從最簡單的一個角度來講，這個數據計算的鏈路大概也就是上面的那個樣子。

1. 首先，經過MySQL binlog採集中間件獲取到數據，轉發給數據接入層。
2. 而後，數據接入層會把原始數據落地到kv存儲裏去
3. 接着，是實時計算平臺會從kv存儲裏提取數據進行計算
4. 最後，會將計算結果寫入到數據庫+緩存的集羣裏。數據查詢平臺會從數據庫 + 緩存的集羣裏提取數據，提供用戶來進行查詢

看起來很簡單，對吧？

可是哪怕是這個系統裏，數據計算鏈路，也絕對不是這麼簡單的。

若是你們看過以前的系列文章的話，就應該知道，這個系統爲了支撐高併發、高可用、高性能等場景，引入了大量的複雜機制。

因此實際上一條原始數據進入到系統，一直到最後落地到存儲裏，計算鏈路還會包含下面的東西：

1. 接入層的限流處理
2. 實時計算層的失敗重試
3. 實時計算層的本地內存存儲的降級機制
4. 數據分片的聚合與計算，單條數據在這裏可能會進入一個數據分片裏
5. 數據查詢層的多級緩存機制

上面只不過是隨便列舉了幾條。然而哪怕只是上述幾條，均可以把一個數據的計算鏈路變得複雜不少倍了。

4、數據計算鏈路的bug

既然你們已經明白了，在一個複雜系統裏，一份核心數據多是通過一個極爲複雜的計算鏈路的處理，中間百轉千回，任何可能的狀況都會發生。

那麼就能夠理解在大型分佈式系統中，數據不一致的問題是如何產生的了。

其實緣由很是的簡單，說白了，就是數據計算鏈路的bug。

也就是說，在數據的計算過程當中，某個子系統出現了bug，並無按照咱們預期的行爲去處理，致使最終產出去的數據變得錯誤了。

那麼，爲何會在數據計算鏈路中出現這種bug呢？

緣由很簡單，若是你們曾經參與過上百人協做的大型分佈式系統，或者是主導過上百人協做開發的大型分佈式系統的架構設計，應該對核心數據的異常和錯誤很是熟悉，而且會感到頭疼不已。

大規模分佈式系統中，動輒上百人協做開發。極可能某個子系統或者是某個服務的負責人，對數據的處理邏輯理解誤差了，代碼裏寫了一個隱藏的bug。

而這個bug，輕易不會觸發，而且在QA測試環境還沒測出來，結果帶着一顆定時炸彈，系統上線。

最後在線上某種特殊的場景下，觸發了這個bug，致使最終的數據出現問題。

5、電商庫存數據的不一致問題

接觸過電商的同窗，可能此時腦子裏就能夠快速的想到一個相似的經典場景：電商中的庫存。

在大規模的電商系統中，庫存數據絕對是核心中的核心。可是實際上，在一個分佈式系統中，不少系統可能都會採用必定的邏輯來更新庫存。

這就可能致使跟上述說的場景相似的問題，就是多個系統都更新庫存，但就是某個系統對庫存的更新出現了bug。

這多是由於那個系統的負責人沒理解到底應該如何更新庫存，也或者是他更新的時候採用的邏輯，沒有考慮到一些特殊狀況。

這樣致使的結果就是，系統裏的庫存和倉庫中實際的庫存，死活對不上。但就是不知道到底哪一個環節出了問題，致使庫存數據出錯。

這個，其實就是一個典型的數據不一致的問題。

6、大型系統的數據不一致排查有多困難

當面對一個大型分佈式系統時，若是你以前壓根兒沒考慮過數據不一致的問題，那麼我敢打賭，當你負責的系統在線上被客服反饋有某個核心數據不一致的時候，你絕對會一臉蒙圈。

由於一個核心數據的處理，少則涉及幾個系統的協做處理，多則涉及十個以上的系統的協做處理。

若是你沒有留存任何日誌、或者僅僅就是有部分日誌，而後基本就只能全部人乾瞪眼，你們大眼對小眼，都盯着本身的代碼看。

你們根據一個數據最後的錯誤結果，好比數據87。10多我的對着本身的代碼，反覆的思考，左思右想。

而後每一個人都在大腦中瘋狂的模擬本身代碼的運行，可是就是想不明白，爲何原本應該是數據4的，結果出來了一個數據87？

因此現實問題就是這樣，這種數據不一致的問題，大概有如下幾個痛點：

1. 本身基本沒法主動提早感知到數據問題，要被動等待用戶發現，反饋給客服，這極可能致使你的產品被大量投訴，老闆很生氣，後果很嚴重。
2. 即便客服告訴了你數據錯了，可是大家無法還原現場，沒有留存證據，基本就是一羣工程師對着代碼想象，猜想。
3. 即便你解決了一次數據不一致的問題，可是之後也許還有下一次，這樣搞下去，會致使團隊裏好幾個能幹的小夥兒時間都搭在這種破事兒上。

7、下篇預告

因此針對本文描述的大型分佈式系統數據不一致的問題，下篇文章咱們將給出：在百億流量的場景下，一套複雜系統咱們是如何構建整套核心數據保證方案的。

敬請期待：

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

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六、億級流量架構第二彈：你的系統真的無懈可擊嗎？

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