上篇文章??《為什么我建議線上高并發(fā)量的代碼，一定要注意數(shù)據(jù)可能會不一致？》??，初步給大家分析了一下，一個復(fù)雜的分布式系統(tǒng)中，數(shù)據(jù)不一致的問題是怎么產(chǎn)生的。

簡單來說，就是一個分布式系統(tǒng)中的多個子系統(tǒng)（或者服務(wù)）協(xié)作處理一份數(shù)據(jù)，但是最后這個數(shù)據(jù)的最終結(jié)果卻沒有符合期望。

這是一種非常典型的數(shù)據(jù)不一致的問題。當(dāng)然在分布式系統(tǒng)中，數(shù)據(jù)不一致問題還有其他的一些情況。

比如說多個系統(tǒng)都要維護(hù)一份數(shù)據(jù)的多個副本，結(jié)果某個系統(tǒng)中的數(shù)據(jù)副本跟其他的副本不一致，這也是數(shù)據(jù)不一致。

但是這幾篇文章，說的主要是我們上篇文章分析的那種數(shù)據(jù)不一致的問題到底應(yīng)該如何解決。

一、多系統(tǒng)訂閱數(shù)據(jù)回顧

我們先來看一張圖，是之前講系統(tǒng)架構(gòu)解耦的時候用的一張圖。

好！通過上面這張圖，我們來回顧一下之前做了系統(tǒng)解耦之后的一個架構(gòu)圖。

其實(shí)，實(shí)時計(jì)算平臺會把數(shù)據(jù)計(jì)算的結(jié)果投遞到一個消息中間件里。

然后，數(shù)據(jù)查詢平臺、數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)、數(shù)據(jù)鏈路追蹤系統(tǒng)，各個系統(tǒng)都需要那個數(shù)據(jù)計(jì)算結(jié)果，都會去訂閱里面的數(shù)據(jù)。

這個就是當(dāng)前的一個架構(gòu)，所以這個系列文章分析到這里，大家也可以反過來理解了之前為什么要做系統(tǒng)架構(gòu)的解耦了。

因?yàn)橐环莺诵臄?shù)據(jù)，是很多系統(tǒng)都可能會需要的。通過引入MQ對架構(gòu)解耦了之后，各個系統(tǒng)就可以按需訂閱數(shù)據(jù)了。

二、核心數(shù)據(jù)的監(jiān)控系統(tǒng)

如果要解決核心數(shù)據(jù)的不一致問題，首先就是要做核心數(shù)據(jù)的監(jiān)控。

有些同學(xué)會以為這個監(jiān)控就是用falcon之類的系統(tǒng)，做業(yè)務(wù)metrics監(jiān)控就可以了，但是其實(shí)并不是這樣。

這種核心數(shù)據(jù)的監(jiān)控，遠(yuǎn)遠(yuǎn)不是做一個metrics監(jiān)控可以解決的。

在我們的實(shí)踐中，必須要自己開發(fā)一個核心數(shù)據(jù)的監(jiān)控系統(tǒng)，在里面按照自己的需求，針對復(fù)雜的數(shù)據(jù)校驗(yàn)邏輯開發(fā)大量的監(jiān)控代碼。

我們用那個數(shù)據(jù)平臺項(xiàng)目來舉例，自己寫的數(shù)據(jù)質(zhì)量監(jiān)控系統(tǒng)，需要把核心的一些數(shù)據(jù)指標(biāo)從MQ里消費(fèi)出來，這些數(shù)據(jù)指標(biāo)都是實(shí)時計(jì)算平臺計(jì)算好的。

那么此時，就需要自定義一套監(jiān)控邏輯了，這種監(jiān)控邏輯，不同的系統(tǒng)都是完全不一樣的。

比如在這種數(shù)據(jù)類的系統(tǒng)里，很可能對數(shù)據(jù)指標(biāo)A的監(jiān)控邏輯是如下這樣的：

• 數(shù)據(jù)指標(biāo)A = 數(shù)據(jù)指標(biāo)B + 數(shù)據(jù)指標(biāo)C - 數(shù)據(jù)指標(biāo)D * 24。

?每個核心指標(biāo)都是有自己的一個監(jiān)控公式的，這個監(jiān)控公式，就是負(fù)責(zé)開發(fā)實(shí)時計(jì)算平臺的同學(xué)，他們寫的數(shù)據(jù)計(jì)算邏輯，是知道數(shù)據(jù)指標(biāo)之間的邏輯關(guān)系的。

所以此時就有了一個非常簡單的思路：

1. 首先，這個數(shù)據(jù)監(jiān)控系統(tǒng)從MQ里消費(fèi)到每一個最新計(jì)算出來的核心數(shù)據(jù)指標(biāo)。
2. 然后根據(jù)預(yù)先定義好的監(jiān)控公式，從數(shù)據(jù)?查詢平臺里調(diào)用接口獲取出來公式需要的其他數(shù)據(jù)指標(biāo)。
3. 接著，按照公式進(jìn)行監(jiān)控計(jì)算。

如果監(jiān)控計(jì)算過后發(fā)現(xiàn)幾個數(shù)據(jù)指標(biāo)之間的關(guān)系居然不符合預(yù)先定義好的那個規(guī)則，那么此時就可以立馬發(fā)送報(bào)警了（短信、郵件、IM通知）。

?工程師接到這報(bào)警之后，就可以立馬開始排查，為什么這個數(shù)據(jù)居然會不符合預(yù)先定義好的一套業(yè)務(wù)規(guī)則呢。

這樣就可以解決數(shù)據(jù)問題的第一個痛點(diǎn)：不需要等待用戶發(fā)現(xiàn)后反饋給客服了，自己系統(tǒng)第一時間就發(fā)現(xiàn)了數(shù)據(jù)的異常。

同樣，給大家上一張圖，直觀的感受一下。?

三、電商庫存數(shù)據(jù)如何監(jiān)控

如果用電商里的庫存數(shù)據(jù)來舉例也是一樣的，假設(shè)你想要監(jiān)控電商系統(tǒng)中的核心數(shù)據(jù)：庫存數(shù)據(jù)。

首先第一步，在微服務(wù)架構(gòu)中，你必須要收口。

也就是說，在徹底的服務(wù)化中，你要保證所有的子系統(tǒng) / 服務(wù)如果有任何庫存更新的操作，全部走接口調(diào)用請求庫存服務(wù)。只能是庫存服務(wù)來負(fù)責(zé)庫存數(shù)據(jù)在數(shù)據(jù)庫層面的更新操作，這樣就完成了收口。

收口了之后做庫存數(shù)據(jù)的監(jiān)控就好辦了，完全可以采用MySQL binlog采集的技術(shù)，直接用Mysql binlog同步中間件來監(jiān)控?cái)?shù)據(jù)庫中庫存數(shù)據(jù)涉及到的表和字段。

只要庫存服務(wù)對應(yīng)的數(shù)據(jù)庫中的表涉及到增刪改操作，都會被Mysql binlog同步中間件采集后，發(fā)送到數(shù)據(jù)監(jiān)控系統(tǒng)中去。

此時，數(shù)據(jù)監(jiān)控系統(tǒng)就可以采用預(yù)先定義好的庫存數(shù)據(jù)監(jiān)控邏輯，來查驗(yàn)這個庫存數(shù)據(jù)是否準(zhǔn)確。

這個監(jiān)控邏輯可以是很多種的，比如可以后臺走異步線程請求到實(shí)際的C/S架構(gòu)的倉儲系統(tǒng)中，查一下實(shí)際的庫存數(shù)量。

或者是根據(jù)一定的庫存邏輯來校驗(yàn)一下，舉個例子：

• 虛擬庫存 + 預(yù)售庫存 + 凍結(jié)庫存 + 可銷售庫存 = 總可用庫存數(shù)

當(dāng)然，這就是舉個例子，實(shí)際如何監(jiān)控，大家根據(jù)自己的業(yè)務(wù)來做就好了。

四、數(shù)據(jù)計(jì)算鏈路追蹤

?此時我們已經(jīng)解決了第一個問題，主動監(jiān)控系統(tǒng)中的少數(shù)核心數(shù)據(jù)，在第一時間可以自己先收到報(bào)警發(fā)現(xiàn)核心是護(hù)具有異常。

但是此時我們還需要解決第二個問題，那就是當(dāng)你發(fā)現(xiàn)核心數(shù)據(jù)出錯之后，如何快速的排查問題到底出在哪里？

比如，你發(fā)現(xiàn)數(shù)據(jù)平臺的某個核心指標(biāo)出錯，或者是電商系統(tǒng)的某個商品庫存數(shù)據(jù)出錯，此時你要排查數(shù)據(jù)到底為什么錯了，應(yīng)該怎么辦呢？

很簡單，此時我們必須要做數(shù)據(jù)計(jì)算鏈路的追蹤。

也就是說，你必須要知道這個數(shù)據(jù)從最開始到底是經(jīng)歷了哪些環(huán)節(jié)和步驟，每個環(huán)節(jié)到底如何更新了數(shù)據(jù)，更新后的數(shù)據(jù)又是什么，還有要記錄下來每次數(shù)據(jù)變更后的監(jiān)控檢查點(diǎn)。?

比如說：

• 步驟A -> 步驟B -> 步驟C -> 2018-01-01 10:00:00

第一次數(shù)據(jù)更新后，數(shù)據(jù)監(jiān)控檢查點(diǎn)，數(shù)據(jù)校驗(yàn)情況是準(zhǔn)確，庫存數(shù)據(jù)值為1365；

• 步驟A -> 步驟B -> 步驟D -> 步驟C -> 2018-01-01 11:05:00

第二次數(shù)據(jù)更新后，數(shù)據(jù)監(jiān)控檢查點(diǎn)，數(shù)據(jù)校驗(yàn)情況是錯誤，庫存數(shù)據(jù)值為1214

類似上面的那種數(shù)據(jù)計(jì)算鏈路的追蹤，是必須要做的。

因?yàn)槟惚仨氁酪粋€核心數(shù)據(jù)，他每次更新一次值經(jīng)歷了哪些中間步驟，哪些服務(wù)更新過他，那一次數(shù)據(jù)變更對應(yīng)的數(shù)據(jù)監(jiān)控結(jié)果如何。

此時，如果你發(fā)現(xiàn)一個庫存數(shù)據(jù)出錯了，立馬可以人肉搜出來這個數(shù)據(jù)過往的歷史計(jì)算鏈路。

你可以看到這條數(shù)據(jù)從一開始出現(xiàn)，然后每一次變更的計(jì)算鏈路和監(jiān)控結(jié)果。

比如上面那個舉例，你可能發(fā)現(xiàn)第二次庫存數(shù)據(jù)更新后結(jié)果是1214，這個值是錯誤的。

然后你一看，發(fā)現(xiàn)其實(shí)第一次更新的結(jié)果是正確的，但是第二次更新的計(jì)算鏈路中多了一個步驟D出來，那么可能這個步驟D是服務(wù)D做了一個更新。

此時，你就可以找服務(wù)D的服務(wù)人問問，結(jié)果可能就會發(fā)現(xiàn)，原來服務(wù)D沒有按照大家約定好的規(guī)則來更新庫存，結(jié)果就導(dǎo)致庫存數(shù)據(jù)出錯。

這個，就是排查核心數(shù)據(jù)問題的一個通用思路。

五、百億流量下的數(shù)據(jù)鏈路追蹤

如果要做數(shù)據(jù)計(jì)算鏈路，其實(shí)要解決的技術(shù)問題只有一個，那就是在百億流量的高并發(fā)下，任何一個核心數(shù)據(jù)每天的計(jì)算鏈路可能都是上億的，此時你應(yīng)該如何存儲呢？

其實(shí)給大家比較推薦的，是用elasticsearch技術(shù)來做這種數(shù)據(jù)鏈路的存儲。

因?yàn)閑s一方面是分布式的，支持海量數(shù)據(jù)的存儲。

而且他可以做高性能的分布式檢索，后續(xù)在排查數(shù)據(jù)問題的時候，是需要對海量數(shù)據(jù)做高性能的多條件檢索的。

所以，我們完全可以獨(dú)立出來一個數(shù)據(jù)鏈路追蹤系統(tǒng)，并設(shè)置如下操作：

• 數(shù)據(jù)計(jì)算過程中涉及到的各個服務(wù)，都需要對核心數(shù)據(jù)的處理發(fā)送一條計(jì)算鏈路日志到數(shù)據(jù)鏈路追蹤系統(tǒng)。
• 然后，數(shù)據(jù)鏈路追蹤系統(tǒng)就可以把計(jì)算鏈路日志落地到存儲里去，按照一定的規(guī)則建立好對應(yīng)的索引字段。
• 舉個例子，索引字段：核心數(shù)據(jù)名稱，核心數(shù)據(jù)id，本次請求id，計(jì)算節(jié)點(diǎn)序號，本次監(jiān)控結(jié)果，子系統(tǒng)名稱，服務(wù)名稱，計(jì)算數(shù)據(jù)內(nèi)容，等等。

此時一旦發(fā)現(xiàn)某個數(shù)據(jù)出錯，就可以立即根據(jù)這條數(shù)據(jù)的id，從es里提取出來歷史上所有的計(jì)算鏈路。

而且還可以給數(shù)據(jù)鏈路追蹤系統(tǒng)開發(fā)一套用戶友好的前端界面，比如在界面上可以按照請求id展示出來每次請求對應(yīng)的一系列技術(shù)步驟組成的鏈路。

此時會有什么樣的體驗(yàn)?zāi)兀课覀兞ⅠR可以清晰的看到是哪一次計(jì)算鏈路導(dǎo)致了數(shù)據(jù)的出錯，以及過程中每一個子系統(tǒng) / 服務(wù)對數(shù)據(jù)做了什么樣的修改。

然后，我們就可以追本溯源，直接定位到出錯的邏輯，進(jìn)行分析和修改。

說了那么多，還是給大家來一張圖，一起來感受一下這個過程。

六、自動化數(shù)據(jù)鏈路分析

到這里為止，大家如果能在自己公司的大規(guī)模分布式系統(tǒng)中，落地上述那套數(shù)據(jù)監(jiān)控 + 鏈路追蹤的機(jī)制，就已經(jīng)可以非常好的保證核心數(shù)據(jù)的準(zhǔn)確性了。

通過這套機(jī)制，核心數(shù)據(jù)出錯時，第一時間可以收到報(bào)警，而且可以立馬拉出數(shù)據(jù)計(jì)算鏈路，快速的分析數(shù)據(jù)為何出錯。

但是，如果要更進(jìn)一步的節(jié)省排查數(shù)據(jù)出錯問題的人力，那么可以在數(shù)據(jù)鏈路追蹤系統(tǒng)里面加入一套自動化數(shù)據(jù)鏈路分析的機(jī)制。

大家可以反向思考一下，假如說現(xiàn)在你發(fā)現(xiàn)數(shù)據(jù)出錯，而且手頭有數(shù)據(jù)計(jì)算鏈路，你會怎么檢查？

不用說，當(dāng)然是大家坐在一起唾沫橫飛的分析了，人腦分析。

比如說，步驟A按理說執(zhí)行完了應(yīng)該數(shù)據(jù)是X，步驟B按理說執(zhí)行完了應(yīng)該數(shù)據(jù)是Y，步驟C按理說執(zhí)行完了應(yīng)該數(shù)據(jù)是Z。

結(jié)果，誒！步驟C執(zhí)行完了怎么數(shù)據(jù)是ZZZ呢？？看來問題就出在步驟C了！

然后去步驟C看看，發(fā)現(xiàn)原來是服務(wù)C更新的，此時服務(wù)C的負(fù)責(zé)人開始吭哧吭哧的排查自己的代碼，看看到底為什么接收到一個數(shù)據(jù)Y之后，自己的代碼會處理成數(shù)據(jù)ZZZ，而不是數(shù)據(jù)Z呢？

最后，找到了代碼問題，此時就ok了，在本地再次復(fù)現(xiàn)數(shù)據(jù)錯誤，然后修復(fù)bug后上線即可。

所以，這個過程的前半部分，是完全可以自動化的。也就是你寫一套自動分析數(shù)據(jù)鏈路的代碼，就模擬你人腦分析鏈路的邏輯即可，自動一步步分析每個步驟的計(jì)算結(jié)果。這樣就可以把數(shù)據(jù)監(jiān)控系統(tǒng)和鏈路追蹤系統(tǒng)打通了。

一旦數(shù)據(jù)監(jiān)控系統(tǒng)發(fā)現(xiàn)數(shù)據(jù)出錯，立馬可以調(diào)用鏈路追蹤系統(tǒng)的接口，進(jìn)行自動化的鏈路分析，看看本次數(shù)據(jù)出錯，到底是鏈路中的哪個服務(wù)bug導(dǎo)致的數(shù)據(jù)問題。

接著，將所有的信息匯總起來，發(fā)送一個報(bào)警通知給相關(guān)人等。

相關(guān)人員看到報(bào)警之后，一目了然，所有人立馬知道本次數(shù)據(jù)出錯，是鏈路中的哪個步驟，哪個服務(wù)導(dǎo)致的。

最后，那個服務(wù)的負(fù)責(zé)人就可以立馬根據(jù)報(bào)警信息，排查自己的系統(tǒng)中的代碼了。