億級流量系統架構之如何保證百億流量下的資料一致性(上)【石杉的架構筆記】

石杉的架構筆記發表於2019-01-07

歡迎關注個人公眾號:石杉的架構筆記(ID:shishan100)

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


目錄

一、前情提示

二、什麼是資料一致性?

三、一個資料計算鏈路的梳理

四、資料計算鏈路的bug

五、電商庫存資料的不一致問題

六、大型系統的資料不一致排查有多困難

七、下篇預告


一、前情提示


這篇文章,我們們繼續來聊聊之前的億級流量架構的演進,之前對這個系列的文章已經更新到了可擴充套件架構的設計,如果有不太清楚的同學,建議一定先回看一下之前的文章:

1、億級流量系統架構之如何支撐百億級資料的儲存與計算

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

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

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

6、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(上)?

7、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)

8、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?


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

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

億級流量系統架構之如何保證百億流量下的資料一致性(上)【石杉的架構筆記】

接著文字我們來聊聊一個核心繫統每天承載百億流量的背景下,應該如何來保證複雜系統中的資料一致性?


二、什麼是資料一致性?

簡單來說,在一個複雜的系統中一定會對一些資料做出非常複雜的處理,而且可能是多個不同的子系統,甚至是多個服務。

對一個資料按照一定的順序依次做出複雜的業務邏輯的執行,最終可能就會生產出一份寶貴的系統核心資料,落地到儲存裡去,比如說在資料庫裡儲存。

給大家來一張手繪彩圖,感受下這個現場的氛圍:

億級流量系統架構之如何保證百億流量下的資料一致性(上)【石杉的架構筆記】

從上圖中我們就可以看到,多個系統如何對一個資料依次進行處理,最終拿到一份核心資料,並落地到儲存裡去。

那麼在這個過程中,就可能會產生所謂的資料不一致的問題。

什麼意思呢?給大家舉一個最簡單的例子,我們本來期望資料的變化過程是:資料1 -> 資料2 -> 資料3 -> 資料4。

那麼最後落地到資料庫裡的應該是資料4,對不對?

結果呢?不知道為啥,經過上面那個複雜的分散式系統中的各個子系統,或者是各個服務的協作處理,最後居然搞出來一個資料87。

搞了半天,搞了一個跟資料4風馬牛不相及的一個東西,最後落地到了資料庫裡。

然後啊,這套系統的終端使用者,可能通過前臺的介面看到了一個莫名其妙的資料87。

這就尷尬了,使用者明顯會覺得這個資料有錯誤,就會反饋給公司的客服,此時就會上報bug到工程師團隊,大家就開始吭哧吭哧的找問題。

上面說的這個場景,其實就是一種資料不一致的問題,也是我們接下來幾篇文章要討論的一個問題。

實際上,在任何一個大規模分散式系統裡,都會存在類似的問題。無論是電商,O2O,還是本文舉例的資料平臺系統,都一樣。


三、一個資料計算鏈路的梳理

那麼既然已經明確了問題,接下來就來看看在資料平臺這個系統裡,到底是什麼問題可能會導致一個最終落地儲存的資料的異常呢?

要明白這個問題,我們們先回過頭看看,在之前提過的資料平臺這個專案裡,一個最終落地的資料的計算鏈路是什麼樣的?

大家看看下面的圖:

億級流量系統架構之如何保證百億流量下的資料一致性(上)【石杉的架構筆記】

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

  1. 首先,通過MySQL binlog採集中介軟體獲取到資料,轉發給資料接入層。
  2. 然後,資料接入層會把原始資料落地到kv儲存裡去
  3. 接著,是實時計算平臺會從kv儲存裡提取資料進行計算
  4. 最後,會將計算結果寫入到資料庫+快取的叢集裡。資料查詢平臺會從資料庫 + 快取的叢集裡提取資料,提供使用者來進行查詢


看起來很簡單,對吧?

但是哪怕是這個系統裡,資料計算鏈路,也絕對不是這麼簡單的。

如果大家看過之前的系列文章的話,就應該知道,這個系統為了支撐高併發、高可用、高效能等場景,引入了大量的複雜機制。

所以實際上一條原始資料進入到系統,一直到最後落地到儲存裡,計算鏈路還會包含下面的東西:

  1. 接入層的限流處理
  2. 實時計算層的失敗重試
  3. 實時計算層的本地記憶體儲存的降級機制
  4. 資料分片的聚合與計算,單條資料在這裡可能會進入一個資料分片裡
  5. 資料查詢層的多級快取機制


上面只不過是隨便列舉了幾條。然而哪怕只是上述幾條,都可以把一個資料的計算鏈路變得複雜很多倍了。


四、資料計算鏈路的bug

既然大家已經明白了,在一個複雜系統裡,一份核心資料可能是經過一個極為複雜的計算鏈路的處理,中間百轉千回,任何可能的情況都會發生。

那麼就可以理解在大型分散式系統中,資料不一致的問題是如何產生的了。

其實原因非常的簡單,說白了,就是資料計算鏈路的bug。

也就是說,在資料的計算過程中,某個子系統出現了bug,並沒有按照我們預期的行為去處理,導致最終產出去的資料變得錯誤了。

那麼,為什麼會在資料計算鏈路中出現這種bug呢?

原因很簡單,如果大家曾經參與過上百人協作的大型分散式系統,或者是主導過上百人協作開發的大型分散式系統的架構設計,應該對核心資料的異常和錯誤非常熟悉,並且會感到頭疼不已。

大規模分散式系統中,動輒上百人協作開發。很可能某個子系統或者是某個服務的負責人,對資料的處理邏輯理解偏差了,程式碼裡寫了一個隱藏的bug。

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

最後線上上某種特殊的場景下,觸發了這個bug,導致最終的資料出現問題。


五、電商庫存資料的不一致問題

接觸過電商的同學,可能此時腦子裡就可以快速的想到一個類似的經典場景:電商中的庫存

在大規模的電商系統中,庫存資料絕對是核心中的核心。但是實際上,在一個分散式系統中,很多系統可能都會採用一定的邏輯來更新庫存。

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

這可能是因為那個系統的負責人沒理解到底應該如何更新庫存,也或者是他更新的時候採用的邏輯,沒有考慮到一些特殊情況。

這樣導致的結果就是,系統裡的庫存和倉庫中實際的庫存,死活對不上。但就是不知道到底哪個環節出了問題,導致庫存資料出錯。

這個,其實就是一個典型的資料不一致的問題。


六、大型系統的資料不一致排查有多困難

當面對一個大型分散式系統時,如果你之前壓根兒沒考慮過資料不一致的問題,那麼我敢打賭,當你負責的系統線上上被客服反饋有某個核心資料不一致的時候,你絕對會一臉蒙圈。

因為一個核心資料的處理,少則涉及幾個系統的協作處理,多則涉及十個以上的系統的協作處理。

如果你沒有留存任何日誌、或者僅僅就是有部分日誌,然後基本就只能所有人乾瞪眼,大家大眼對小眼,都盯著自己的程式碼看。

大家根據一個資料最後的錯誤結果,比如資料87。10多個人對著自己的程式碼,反覆的思考,冥思苦想。

然後每個人都在大腦中瘋狂的模擬自己程式碼的執行,但是就是想不明白,為什麼本來應該是資料4的,結果出來了一個資料87?

所以現實問題就是這樣,這種資料不一致的問題,大概有以下幾個痛點

  1. 自己基本無法主動提前感知到資料問題,要被動等待使用者發現,反饋給客服,這很可能導致你的產品被大量投訴,老闆很生氣,後果很嚴重。
  2. 即使客服告訴了你資料錯了,但是你們沒法還原現場,沒有留存證據,基本就是一群工程師對著程式碼想象,猜測。
  3. 即使你解決了一次資料不一致的問題,但是以後也許還有下一次,這樣搞下去,會導致團隊裡好幾個能幹的小夥兒時間都搭在這種破事兒上。


七、下篇預告

所以針對本文描述的大型分散式系統資料不一致的問題,下篇文章我們將給出:在百億流量的場景下,一套複雜系統我們是如何構建整套核心資料保證方案的。

敬請期待:

  • 億級流量系統架構之如何保證百億流量下的資料一致性(中)?
  • 億級流量系統架構之如何保證百億流量下的資料一致性(下)?


end



如有收穫,請幫忙轉發,您的鼓勵是作者最大的動力,謝謝!


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

歡迎掃描下方二維碼,持續關注:

億級流量系統架構之如何保證百億流量下的資料一致性(上)【石杉的架構筆記】

石杉的架構筆記(id:shishan100)

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


推薦閱讀:

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

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

3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰

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

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

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

7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍

8、拜託,面試請不要再問我TCC分散式事務的實現原理坑爹呀!

9、【坑爹呀!】最終一致性分散式事務如何保障實際生產中99.99%高可用?

10、拜託,面試請不要再問我Redis分散式鎖的實現原理!

11、【眼前一亮!】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上?

12、億級流量系統架構之如何支撐百億級資料的儲存與計算

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

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

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

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

17、七張圖徹底講清楚ZooKeeper分散式鎖的實現原理

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、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(中)?

35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構(下)?

36、億級流量架構第二彈:你的系統真的無懈可擊嗎?



作者:石杉的架構筆記
連結:https://juejin.im/post/5c263a936fb9a049ec6b2688
來源:掘金
著作權歸作者所有,轉載請聯絡作者獲得授權!









相關文章