億級流量系統架構之如何保證百億流量下的資料一致性（上）【石杉的架構筆記】
歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
目錄
一、前情提示
二、什麼是資料一致性？
三、一個數據計算鏈路的梳理
四、資料計算鏈路的bug
五、電商庫存資料的不一致問題
六、大型系統的資料不一致排查有多困難
七、下篇預告
一、前情提示
這篇文章，咱們繼續來聊聊之前的億級流量架構的演進，之前對這個系列的文章已經更新到了可擴充套件架構的設計，如果有不太清楚的同學，建議一定先回看一下之前的文章：
3、6、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
7、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
8、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
老規矩！我們首先看一下這個複雜的系統架構演進到當前階段，整體的架構圖是什麼樣子的。
筆者再次友情提醒，如果各位小夥伴對下面這個複雜的架構圖還有什麼不理解的地方，一定要先回看之前的文章，因為系列文必須對上下文有清晰的理解和認識。
接著文字我們來聊聊一個核心繫統每天承載百億流量的背景下，應該如何來保證複雜系統中的資料一致性？
二、什麼是資料一致性？
簡單來說，在一個複雜的系統中一定會對一些資料做出非常複雜的處理，而且可能是多個不同的子系統，甚至是多個服務。
對一個數據按照一定的順序依次做出複雜的業務邏輯的執行，最終可能就會生產出一份寶貴的系統核心資料，落地到儲存裡去，比如說在資料庫裡儲存。
給大家來一張手繪彩圖，感受下這個現場的氛圍：
從上圖中我們就可以看到，多個系統如何對一個數據依次進行處理，最終拿到一份核心資料，並落地到儲存裡去。
那麼在這個過程中，就可能會產生所謂的資料不一致的問題。
什麼意思呢？給大家舉一個最簡單的例子，我們本來期望資料的變化過程是：資料1 -> 資料2 -> 資料3 -> 資料4。
那麼最後落地到資料庫裡的應該是資料4，對不對？
結果呢？不知道為啥，經過上面那個複雜的分散式系統中的各個子系統，或者是各個服務的協作處理，最後居然搞出來一個數據87。
搞了半天，搞了一個跟資料4風馬牛不相及的一個東西，最後落地到了資料庫裡。
然後啊，這套系統的終端使用者，可能通過前臺的介面看到了一個莫名其妙的資料87。
這就尷尬了，使用者明顯會覺得這個資料有錯誤，就會反饋給公司的客服，此時就會上報bug到工程師團隊，大家就開始吭哧吭哧的找問題。
上面說的這個場景，其實就是一種資料不一致的問題，也是我們接下來幾篇文章要討論的一個問題。
實際上，在任何一個大規模分散式系統裡，都會存在類似的問題。無論是電商，O2O，還是本文舉例的資料平臺系統，都一樣。
三、一個數據計算鏈路的梳理
那麼既然已經明確了問題，接下來就來看看在資料平臺這個系統裡，到底是什麼問題可能會導致一個最終落地儲存的資料的異常呢？
要明白這個問題，咱們先回過頭看看，在之前提過的資料平臺這個專案裡，一個最終落地的資料的計算鏈路是什麼樣的？
大家看看下面的圖：
如上圖所示，其實從最簡單的一個角度來說，這個資料計算的鏈路大概也就是上面的那個樣子。
- 首先，通過MySQL binlog採集中介軟體獲取到資料，轉發給資料接入層。
- 然後，資料接入層會把原始資料落地到kv儲存裡去
- 接著，是實時計算平臺會從kv儲存裡提取資料進行計算
- 最後，會將計算結果寫入到資料庫+快取的叢集裡。資料查詢平臺會從資料庫 + 快取的叢集裡提取資料，提供使用者來進行查詢
看起來很簡單，對吧？
但是哪怕是這個系統裡，資料計算鏈路，也絕對不是這麼簡單的。
如果大家看過之前的系列文章的話，就應該知道，這個系統為了支撐高併發、高可用、高效能等場景，引入了大量的複雜機制。
所以實際上一條原始資料進入到系統，一直到最後落地到儲存裡，計算鏈路還會包含下面的東西：
- 接入層的限流處理
- 實時計算層的失敗重試
- 實時計算層的本地記憶體儲存的降級機制
- 資料分片的聚合與計算，單條資料在這裡可能會進入一個數據分片裡
- 資料查詢層的多級快取機制
上面只不過是隨便列舉了幾條。然而哪怕只是上述幾條，都可以把一個數據的計算鏈路變得複雜很多倍了。
四、資料計算鏈路的bug
既然大家已經明白了，在一個複雜系統裡，一份核心資料可能是經過一個極為複雜的計算鏈路的處理，中間百轉千回，任何可能的情況都會發生。
那麼就可以理解在大型分散式系統中，資料不一致的問題是如何產生的了。
其實原因非常的簡單，說白了，就是資料計算鏈路的bug。
也就是說，在資料的計算過程中，某個子系統出現了bug，並沒有按照我們預期的行為去處理，導致最終產出去的資料變得錯誤了。
那麼，為什麼會在資料計算鏈路中出現這種bug呢？
原因很簡單，如果大家曾經參與過上百人協作的大型分散式系統，或者是主導過上百人協作開發的大型分散式系統的架構設計，應該對核心資料的異常和錯誤非常熟悉，並且會感到頭疼不已。
大規模分散式系統中，動輒上百人協作開發。很可能某個子系統或者是某個服務的負責人，對資料的處理邏輯理解偏差了，程式碼裡寫了一個隱藏的bug。
而這個bug，輕易不會觸發，並且在QA測試環境還沒測出來，結果帶著一顆定時炸彈，系統上線。
最後在線上某種特殊的場景下，觸發了這個bug，導致最終的資料出現問題。
五、電商庫存資料的不一致問題
接觸過電商的同學，可能此時腦子裡就可以快速的想到一個類似的經典場景：電商中的庫存。
在大規模的電商系統中，庫存資料絕對是核心中的核心。但是實際上，在一個分散式系統中，很多系統可能都會採用一定的邏輯來更新庫存。
這就可能導致跟上述說的場景類似的問題，就是多個系統都更新庫存，但就是某個系統對庫存的更新出現了bug。
這可能是因為那個系統的負責人沒理解到底應該如何更新庫存，也或者是他更新的時候採用的邏輯，沒有考慮到一些特殊情況。
這樣導致的結果就是，系統裡的庫存和倉庫中實際的庫存，死活對不上。但就是不知道到底哪個環節出了問題，導致庫存資料出錯。
這個，其實就是一個典型的資料不一致的問題。
六、大型系統的資料不一致排查有多困難
當面對一個大型分散式系統時，如果你之前壓根兒沒考慮過資料不一致的問題，那麼我敢打賭，當你負責的系統在線上被客服反饋有某個核心資料不一致的時候，你絕對會一臉蒙圈。
因為一個核心資料的處理，少則涉及幾個系統的協作處理，多則涉及十個以上的系統的協作處理。
如果你沒有留存任何日誌、或者僅僅就是有部分日誌，然後基本就只能所有人乾瞪眼，大家大眼對小眼，都盯著自己的程式碼看。
大家根據一個數據最後的錯誤結果，比如資料87。10多個人對著自己的程式碼，反覆的思考，冥思苦想。
然後每個人都在大腦中瘋狂的模擬自己程式碼的執行，但是就是想不明白，為什麼本來應該是資料4的，結果出來了一個數據87？
所以現實問題就是這樣，這種資料不一致的問題，大概有以下幾個痛點：
- 自己基本無法主動提前感知到資料問題，要被動等待使用者發現，反饋給客服，這很可能導致你的產品被大量投訴，老闆很生氣，後果很嚴重。
- 即使客服告訴了你資料錯了，但是你們沒法還原現場，沒有留存證據，基本就是一群工程師對著程式碼想象，猜測。
- 即使你解決了一次資料不一致的問題，但是以後也許還有下一次，這樣搞下去，會導致團隊裡好幾個能幹的小夥兒時間都搭在這種破事兒上。
七、下篇預告
所以針對本文描述的大型分散式系統資料不一致的問題，下篇文章我們將給出：在百億流量的場景下，一套複雜系統我們是如何構建整套核心資料保證方案的。
敬請期待：
- 億級流量系統架構之如何保證百億流量下的資料一致性（中）？
- 億級流量系統架構之如何保證百億流量下的資料一致性（下）？
end
如有收穫，請幫忙轉發，您的鼓勵是作者最大的動力，謝謝！
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼，持續關注：
石杉的架構筆記（id:shishan100）
十餘年BAT架構經驗傾囊相授
推薦閱讀：2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
8、拜託，面試請不要再問我TCC分散式事務的實現原理坑爹呀！
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
作者：石杉的架構筆記
連結：https://juejin.im/post/5c263a936fb9a049ec6b2688
來源：掘金
著作權歸作者所有，轉載請聯絡作者獲得授權！