一、前情提示

這篇文章，咱們繼續(xù)來(lái)聊聊之前的億級(jí)流量架構(gòu)的演進(jìn)。老規(guī)矩！我們首先看一下這個(gè)復(fù)雜的系統(tǒng)架構(gòu)演進(jìn)到當(dāng)前階段，整體的架構(gòu)圖是什么樣子的。

筆者再次友情提醒，如果各位小伙伴對(duì)下面這個(gè)復(fù)雜的架構(gòu)圖還有什么不理解的地方，一定要先回看之前的文章，因?yàn)橄盗形谋仨殞?duì)上下文有清晰的理解和認(rèn)識(shí)。

接著文本我們來(lái)聊聊一個(gè)核心系統(tǒng)每天承載百億流量的背景下，應(yīng)該如何來(lái)保證復(fù)雜系統(tǒng)中的數(shù)據(jù)一致性？

二、什么是數(shù)據(jù)一致性？

簡(jiǎn)單來(lái)說(shuō)，在一個(gè)復(fù)雜的系統(tǒng)中一定會(huì)對(duì)一些數(shù)據(jù)做出非常復(fù)雜的處理，而且可能是多個(gè)不同的子系統(tǒng)，甚至是多個(gè)服務(wù)。

對(duì)一個(gè)數(shù)據(jù)按照一定的順序依次做出復(fù)雜的業(yè)務(wù)邏輯的執(zhí)行，最終可能就會(huì)生產(chǎn)出一份寶貴的系統(tǒng)核心數(shù)據(jù)，落地到存儲(chǔ)里去，比如說(shuō)在數(shù)據(jù)庫(kù)里存儲(chǔ)。

給大家來(lái)一張手繪彩圖，感受下這個(gè)現(xiàn)場(chǎng)的氛圍：

從上圖中我們就可以看到，多個(gè)系統(tǒng)如何對(duì)一個(gè)數(shù)據(jù)依次進(jìn)行處理，最終拿到一份核心數(shù)據(jù)，并落地到存儲(chǔ)里去。

那么在這個(gè)過(guò)程中，就可能會(huì)產(chǎn)生所謂的數(shù)據(jù)不一致的問題。

什么意思呢？給大家舉一個(gè)最簡(jiǎn)單的例子，我們本來(lái)期望數(shù)據(jù)的變化過(guò)程是：數(shù)據(jù)1 -> 數(shù)據(jù)2 -> 數(shù)據(jù)3 -> 數(shù)據(jù)4。

那么最后落地到數(shù)據(jù)庫(kù)里的應(yīng)該是數(shù)據(jù)4，對(duì)不對(duì)？

結(jié)果呢？不知道為啥，經(jīng)過(guò)上面那個(gè)復(fù)雜的分布式系統(tǒng)中的各個(gè)子系統(tǒng)，或者是各個(gè)服務(wù)的協(xié)作處理，最后居然搞出來(lái)一個(gè)數(shù)據(jù)87。

搞了半天，搞了一個(gè)跟數(shù)據(jù)4風(fēng)馬牛不相及的一個(gè)東西，最后落地到了數(shù)據(jù)庫(kù)里。

然后啊，這套系統(tǒng)的最終用戶，可能通過(guò)前臺(tái)的界面看到了一個(gè)莫名其妙的數(shù)據(jù)87。

這就尷尬了，用戶明顯會(huì)覺得這個(gè)數(shù)據(jù)有錯(cuò)誤，就會(huì)反饋給公司的客服，此時(shí)就會(huì)上報(bào)bug到工程師團(tuán)隊(duì)，大家就開始吭哧吭哧的找問題。

上面說(shuō)的這個(gè)場(chǎng)景，其實(shí)就是一種數(shù)據(jù)不一致的問題，也是我們接下來(lái)幾篇文章要討論的一個(gè)問題。

實(shí)際上，在任何一個(gè)大規(guī)模分布式系統(tǒng)里，都會(huì)存在類似的問題。無(wú)論是電商，O2O，還是本文舉例的數(shù)據(jù)平臺(tái)系統(tǒng)，都一樣。

三、一個(gè)數(shù)據(jù)計(jì)算鏈路的梳理

那么既然已經(jīng)明確了問題，接下來(lái)就來(lái)看看在數(shù)據(jù)平臺(tái)這個(gè)系統(tǒng)里，到底是什么問題可能會(huì)導(dǎo)致一個(gè)最終落地存儲(chǔ)的數(shù)據(jù)的異常呢？

要明白這個(gè)問題，咱們先回過(guò)頭看看，在之前提過(guò)的數(shù)據(jù)平臺(tái)這個(gè)項(xiàng)目里，一個(gè)最終落地的數(shù)據(jù)的計(jì)算鏈路是什么樣的？

大家看看下面的圖：

如上圖所示，其實(shí)從最簡(jiǎn)單的一個(gè)角度來(lái)說(shuō)，這個(gè)數(shù)據(jù)計(jì)算的鏈路大概也就是上面的那個(gè)樣子。

• 首先，通過(guò)MySQL binlog采集中間件獲取到數(shù)據(jù)，轉(zhuǎn)發(fā)給數(shù)據(jù)接入層。
• 然后，數(shù)據(jù)接入層會(huì)把原始數(shù)據(jù)落地到kv存儲(chǔ)里去
• 接著，是實(shí)時(shí)計(jì)算平臺(tái)會(huì)從kv存儲(chǔ)里提取數(shù)據(jù)進(jìn)行計(jì)算
• 最后，會(huì)將計(jì)算結(jié)果寫入到數(shù)據(jù)庫(kù)+緩存的集群里。數(shù)據(jù)查詢平臺(tái)會(huì)從數(shù)據(jù)庫(kù) + 緩存的集群里提取數(shù)據(jù)，提供用戶來(lái)進(jìn)行查詢

看起來(lái)很簡(jiǎn)單，對(duì)吧？

但是哪怕是這個(gè)系統(tǒng)里，數(shù)據(jù)計(jì)算鏈路，也絕對(duì)不是這么簡(jiǎn)單的。

如果大家看過(guò)之前的系列文章的話，就應(yīng)該知道，這個(gè)系統(tǒng)為了支撐高并發(fā)、高可用、高性能等場(chǎng)景，引入了大量的復(fù)雜機(jī)制。

所以實(shí)際上一條原始數(shù)據(jù)進(jìn)入到系統(tǒng)，一直到最后落地到存儲(chǔ)里，計(jì)算鏈路還會(huì)包含下面的東西：

• 接入層的限流處理
• 實(shí)時(shí)計(jì)算層的失敗重試
• 實(shí)時(shí)計(jì)算層的本地內(nèi)存存儲(chǔ)的降級(jí)機(jī)制
• 數(shù)據(jù)分片的聚合與計(jì)算，單條數(shù)據(jù)在這里可能會(huì)進(jìn)入一個(gè)數(shù)據(jù)分片里
• 數(shù)據(jù)查詢層的多級(jí)緩存機(jī)制

上面只不過(guò)是隨便列舉了幾條。然而哪怕只是上述幾條，都可以把一個(gè)數(shù)據(jù)的計(jì)算鏈路變得復(fù)雜很多倍了。

四、數(shù)據(jù)計(jì)算鏈路的bug

既然大家已經(jīng)明白了，在一個(gè)復(fù)雜系統(tǒng)里，一份核心數(shù)據(jù)可能是經(jīng)過(guò)一個(gè)極為復(fù)雜的計(jì)算鏈路的處理，中間百轉(zhuǎn)千回，任何可能的情況都會(huì)發(fā)生。

那么就可以理解在大型分布式系統(tǒng)中，數(shù)據(jù)不一致的問題是如何產(chǎn)生的了。

其實(shí)原因非常的簡(jiǎn)單，說(shuō)白了，就是數(shù)據(jù)計(jì)算鏈路的bug。

也就是說(shuō)，在數(shù)據(jù)的計(jì)算過(guò)程中，某個(gè)子系統(tǒng)出現(xiàn)了bug，并沒有按照我們預(yù)期的行為去處理，導(dǎo)致最終產(chǎn)出去的數(shù)據(jù)變得錯(cuò)誤了。

那么，為什么會(huì)在數(shù)據(jù)計(jì)算鏈路中出現(xiàn)這種bug呢？

原因很簡(jiǎn)單，如果大家曾經(jīng)參與過(guò)上百人協(xié)作的大型分布式系統(tǒng)，或者是主導(dǎo)過(guò)上百人協(xié)作開發(fā)的大型分布式系統(tǒng)的架構(gòu)設(shè)計(jì)，應(yīng)該對(duì)核心數(shù)據(jù)的異常和錯(cuò)誤非常熟悉，并且會(huì)感到頭疼不已。

大規(guī)模分布式系統(tǒng)中，動(dòng)輒上百人協(xié)作開發(fā)。很可能某個(gè)子系統(tǒng)或者是某個(gè)服務(wù)的負(fù)責(zé)人，對(duì)數(shù)據(jù)的處理邏輯理解偏差了，代碼里寫了一個(gè)隱藏的bug。

而這個(gè)bug，輕易不會(huì)觸發(fā)，并且在QA測(cè)試環(huán)境還沒測(cè)出來(lái)，結(jié)果帶著一顆定時(shí)炸彈，系統(tǒng)上線。

最后在線上某種特殊的場(chǎng)景下，觸發(fā)了這個(gè)bug，導(dǎo)致最終的數(shù)據(jù)出現(xiàn)問題。

五、電商庫(kù)存數(shù)據(jù)的不一致問題

接觸過(guò)電商的同學(xué)，可能此時(shí)腦子里就可以快速的想到一個(gè)類似的經(jīng)典場(chǎng)景：電商中的庫(kù)存。

在大規(guī)模的電商系統(tǒng)中，庫(kù)存數(shù)據(jù)絕對(duì)是核心中的核心。但是實(shí)際上，在一個(gè)分布式系統(tǒng)中，很多系統(tǒng)可能都會(huì)采用一定的邏輯來(lái)更新庫(kù)存。

這就可能導(dǎo)致跟上述說(shuō)的場(chǎng)景類似的問題，就是多個(gè)系統(tǒng)都更新庫(kù)存，但就是某個(gè)系統(tǒng)對(duì)庫(kù)存的更新出現(xiàn)了bug。

這可能是因?yàn)槟莻€(gè)系統(tǒng)的負(fù)責(zé)人沒理解到底應(yīng)該如何更新庫(kù)存，也或者是他更新的時(shí)候采用的邏輯，沒有考慮到一些特殊情況。

這樣導(dǎo)致的結(jié)果就是，系統(tǒng)里的庫(kù)存和倉(cāng)庫(kù)中實(shí)際的庫(kù)存，死活對(duì)不上。但就是不知道到底哪個(gè)環(huán)節(jié)出了問題，導(dǎo)致庫(kù)存數(shù)據(jù)出錯(cuò)。

這個(gè)，其實(shí)就是一個(gè)典型的數(shù)據(jù)不一致的問題。

六、大型系統(tǒng)的數(shù)據(jù)不一致排查有多困難

當(dāng)面對(duì)一個(gè)大型分布式系統(tǒng)時(shí)，如果你之前壓根兒沒考慮過(guò)數(shù)據(jù)不一致的問題，那么我敢打賭，當(dāng)你負(fù)責(zé)的系統(tǒng)在線上被客服反饋有某個(gè)核心數(shù)據(jù)不一致的時(shí)候，你絕對(duì)會(huì)一臉蒙圈。

因?yàn)橐粋€(gè)核心數(shù)據(jù)的處理，少則涉及幾個(gè)系統(tǒng)的協(xié)作處理，多則涉及十個(gè)以上的系統(tǒng)的協(xié)作處理。

如果你沒有留存任何日志、或者僅僅就是有部分日志，然后基本就只能所有人干瞪眼，大家大眼對(duì)小眼，都盯著自己的代碼看。

大家根據(jù)一個(gè)數(shù)據(jù)最后的錯(cuò)誤結(jié)果，比如數(shù)據(jù)87。10多個(gè)人對(duì)著自己的代碼，反復(fù)的思考，冥思苦想。

然后每個(gè)人都在大腦中瘋狂的模擬自己代碼的運(yùn)行，但是就是想不明白，為什么本來(lái)應(yīng)該是數(shù)據(jù)4的，結(jié)果出來(lái)了一個(gè)數(shù)據(jù)87？

所以現(xiàn)實(shí)問題就是這樣，這種數(shù)據(jù)不一致的問題，大概有以下幾個(gè)痛點(diǎn)：

自己基本無(wú)法主動(dòng)提前感知到數(shù)據(jù)問題，要被動(dòng)等待用戶發(fā)現(xiàn)，反饋給客服，這很可能導(dǎo)致你的產(chǎn)品被大量投訴，老板很生氣，后果很嚴(yán)重。

即使客服告訴了你數(shù)據(jù)錯(cuò)了，但是你們沒法還原現(xiàn)場(chǎng)，沒有留存證據(jù)，基本就是一群工程師對(duì)著代碼想象，猜測(cè)。

即使你解決了一次數(shù)據(jù)不一致的問題，但是以后也許還有下一次，這樣搞下去，會(huì)導(dǎo)致團(tuán)隊(duì)里好幾個(gè)能干的小伙兒時(shí)間都搭在這種破事兒上。