久久国产精品一区二区三区四区,久色婷婷小香蕉久久,国产日韩欧美在线播放不卡,另类av一区二区

一、前情提示

這篇文章，咱們繼續來聊聊之前的億級流量架構的演進。老規矩！我們首先看一下這個復雜的系統架構演進到當前階段，整體的架構圖是什么樣子的。

(資料圖片僅供參考)

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

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

二、什么是數據一致性？

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

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

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

從上圖中我們就可以看到，多個系統如何對一個數據依次進行處理，最終拿到一份核心數據，并落地到存儲里去。

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

什么意思呢？給大家舉一個最簡單的例子，我們本來期望數據的變化過程是：數據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？

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

自己基本無法主動提前感知到數據問題，要被動等待用戶發現，反饋給客服，這很可能導致你的產品被大量投訴，老板很生氣，后果很嚴重。

即使客服告訴了你數據錯了，但是你們沒法還原現場，沒有留存證據，基本就是一群工程師對著代碼想象，猜測。

即使你解決了一次數據不一致的問題，但是以后也許還有下一次，這樣搞下去，會導致團隊里好幾個能干的小伙兒時間都搭在這種破事兒上。

關鍵詞： 分布式系統 數據一致性 協作處理 實時計算