redis 亿级查询速度_亿级流量系统架构之如何保证百亿流量下的数据一致性（上）...
歡迎關(guān)注頭條號：石杉的架構(gòu)筆記
周一至周五早八點(diǎn)半！精品技術(shù)文章準(zhǔn)時(shí)送上！！！
目錄
一、前情提示
二、什么是數(shù)據(jù)一致性？
三、一個(gè)數(shù)據(jù)計(jì)算鏈路的梳理
四、數(shù)據(jù)計(jì)算鏈路的bug
五、電商庫存數(shù)據(jù)的不一致問題
六、大型系統(tǒng)的數(shù)據(jù)不一致排查有多困難
七、下篇預(yù)告
一、前情提示
這篇文章，咱們繼續(xù)來聊聊之前的億級流量架構(gòu)的演進(jìn)，之前對這個(gè)系列的文章已經(jīng)更新到了可擴(kuò)展架構(gòu)的設(shè)計(jì)，如果有不太清楚的同學(xué)，建議一定先回看一下之前的文章：
1、億級流量系統(tǒng)架構(gòu)之如何支撐百億級數(shù)據(jù)的存儲與計(jì)算
2、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)高容錯分布式計(jì)算系統(tǒng)
3、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)承載百億流量的高性能架構(gòu)
4、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)每秒十萬查詢的高并發(fā)架構(gòu)
5、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)全鏈路99.99%高可用架構(gòu)
6、億級流量系統(tǒng)架構(gòu)之如何在上萬并發(fā)場景下設(shè)計(jì)可擴(kuò)展架構(gòu)(上)？
7、億級流量系統(tǒng)架構(gòu)之如何在上萬并發(fā)場景下設(shè)計(jì)可擴(kuò)展架構(gòu)(中)？
8、億級流量系統(tǒng)架構(gòu)之如何在上萬并發(fā)場景下設(shè)計(jì)可擴(kuò)展架構(gòu)(下)？
老規(guī)矩！我們首先看一下這個(gè)復(fù)雜的系統(tǒng)架構(gòu)演進(jìn)到當(dāng)前階段，整體的架構(gòu)圖是什么樣子的。
筆者再次友情提醒，如果各位小伙伴對下面這個(gè)復(fù)雜的架構(gòu)圖還有什么不理解的地方，一定要先回看之前的文章，因?yàn)橄盗形谋仨殞ι舷挛挠星逦睦斫夂驼J(rèn)識。
接著文本我們來聊聊一個(gè)核心系統(tǒng)每天承載百億流量的背景下，應(yīng)該如何來保證復(fù)雜系統(tǒng)中的數(shù)據(jù)一致性？
二、什么是數(shù)據(jù)一致性？
簡單來說，在一個(gè)復(fù)雜的系統(tǒng)中一定會對一些數(shù)據(jù)做出非常復(fù)雜的處理，而且可能是多個(gè)不同的子系統(tǒng)，甚至是多個(gè)服務(wù)。
對一個(gè)數(shù)據(jù)按照一定的順序依次做出復(fù)雜的業(yè)務(wù)邏輯的執(zhí)行，最終可能就會生產(chǎn)出一份寶貴的系統(tǒng)核心數(shù)據(jù)，落地到存儲里去，比如說在數(shù)據(jù)庫里存儲。
給大家來一張手繪彩圖，感受下這個(gè)現(xiàn)場的氛圍：
從上圖中我們就可以看到，多個(gè)系統(tǒng)如何對一個(gè)數(shù)據(jù)依次進(jìn)行處理，最終拿到一份核心數(shù)據(jù)，并落地到存儲里去。
那么在這個(gè)過程中，就可能會產(chǎn)生所謂的數(shù)據(jù)不一致的問題。
什么意思呢？給大家舉一個(gè)最簡單的例子，我們本來期望數(shù)據(jù)的變化過程是：數(shù)據(jù)1 -> 數(shù)據(jù)2 -> 數(shù)據(jù)3 -> 數(shù)據(jù)4。
那么最后落地到數(shù)據(jù)庫里的應(yīng)該是數(shù)據(jù)4，對不對？
結(jié)果呢？不知道為啥，經(jīng)過上面那個(gè)復(fù)雜的分布式系統(tǒng)中的各個(gè)子系統(tǒng)，或者是各個(gè)服務(wù)的協(xié)作處理，最后居然搞出來一個(gè)數(shù)據(jù)87。
搞了半天，搞了一個(gè)跟數(shù)據(jù)4風(fēng)馬牛不相及的一個(gè)東西，最后落地到了數(shù)據(jù)庫里。
然后啊，這套系統(tǒng)的最終用戶，可能通過前臺的界面看到了一個(gè)莫名其妙的數(shù)據(jù)87。
這就尷尬了，用戶明顯會覺得這個(gè)數(shù)據(jù)有錯誤，就會反饋給公司的客服，此時(shí)就會上報(bào)bug到工程師團(tuán)隊(duì)，大家就開始吭哧吭哧的找問題。
上面說的這個(gè)場景，其實(shí)就是一種數(shù)據(jù)不一致的問題，也是我們接下來幾篇文章要討論的一個(gè)問題。
實(shí)際上，在任何一個(gè)大規(guī)模分布式系統(tǒng)里，都會存在類似的問題。無論是電商，O2O，還是本文舉例的數(shù)據(jù)平臺系統(tǒng)，都一樣。
三、一個(gè)數(shù)據(jù)計(jì)算鏈路的梳理
那么既然已經(jīng)明確了問題，接下來就來看看在數(shù)據(jù)平臺這個(gè)系統(tǒng)里，到底是什么問題可能會導(dǎo)致一個(gè)最終落地存儲的數(shù)據(jù)的異常呢？
要明白這個(gè)問題，咱們先回過頭看看，在之前提過的數(shù)據(jù)平臺這個(gè)項(xiàng)目里，一個(gè)最終落地的數(shù)據(jù)的計(jì)算鏈路是什么樣的？
大家看看下面的圖：
如上圖所示，其實(shí)從最簡單的一個(gè)角度來說，這個(gè)數(shù)據(jù)計(jì)算的鏈路大概也就是上面的那個(gè)樣子。
看起來很簡單，對吧？
但是哪怕是這個(gè)系統(tǒng)里，數(shù)據(jù)計(jì)算鏈路，也絕對不是這么簡單的。
如果大家看過之前的系列文章的話，就應(yīng)該知道，這個(gè)系統(tǒng)為了支撐高并發(fā)、高可用、高性能等場景，引入了大量的復(fù)雜機(jī)制。
所以實(shí)際上一條原始數(shù)據(jù)進(jìn)入到系統(tǒng)，一直到最后落地到存儲里，計(jì)算鏈路還會包含下面的東西：
上面只不過是隨便列舉了幾條。然而哪怕只是上述幾條，都可以把一個(gè)數(shù)據(jù)的計(jì)算鏈路變得復(fù)雜很多倍了。
四、數(shù)據(jù)計(jì)算鏈路的bug
既然大家已經(jīng)明白了，在一個(gè)復(fù)雜系統(tǒng)里，一份核心數(shù)據(jù)可能是經(jīng)過一個(gè)極為復(fù)雜的計(jì)算鏈路的處理，中間百轉(zhuǎn)千回，任何可能的情況都會發(fā)生。
那么就可以理解在大型分布式系統(tǒng)中，數(shù)據(jù)不一致的問題是如何產(chǎn)生的了。
其實(shí)原因非常的簡單，說白了，就是數(shù)據(jù)計(jì)算鏈路的bug。
也就是說，在數(shù)據(jù)的計(jì)算過程中，某個(gè)子系統(tǒng)出現(xiàn)了bug，并沒有按照我們預(yù)期的行為去處理，導(dǎo)致最終產(chǎn)出去的數(shù)據(jù)變得錯誤了。
那么，為什么會在數(shù)據(jù)計(jì)算鏈路中出現(xiàn)這種bug呢？
原因很簡單，如果大家曾經(jīng)參與過上百人協(xié)作的大型分布式系統(tǒng)，或者是主導(dǎo)過上百人協(xié)作開發(fā)的大型分布式系統(tǒng)的架構(gòu)設(shè)計(jì)，應(yīng)該對核心數(shù)據(jù)的異常和錯誤非常熟悉，并且會感到頭疼不已。
大規(guī)模分布式系統(tǒng)中，動輒上百人協(xié)作開發(fā)。很可能某個(gè)子系統(tǒng)或者是某個(gè)服務(wù)的負(fù)責(zé)人，對數(shù)據(jù)的處理邏輯理解偏差了，代碼里寫了一個(gè)隱藏的bug。
而這個(gè)bug，輕易不會觸發(fā)，并且在QA測試環(huán)境還沒測出來，結(jié)果帶著一顆定時(shí)炸彈，系統(tǒng)上線。
最后在線上某種特殊的場景下，觸發(fā)了這個(gè)bug，導(dǎo)致最終的數(shù)據(jù)出現(xiàn)問題。
五、電商庫存數(shù)據(jù)的不一致問題
接觸過電商的同學(xué)，可能此時(shí)腦子里就可以快速的想到一個(gè)類似的經(jīng)典場景：電商中的庫存。
在大規(guī)模的電商系統(tǒng)中，庫存數(shù)據(jù)絕對是核心中的核心。但是實(shí)際上，在一個(gè)分布式系統(tǒng)中，很多系統(tǒng)可能都會采用一定的邏輯來更新庫存。
這就可能導(dǎo)致跟上述說的場景類似的問題，就是多個(gè)系統(tǒng)都更新庫存，但就是某個(gè)系統(tǒng)對庫存的更新出現(xiàn)了bug。
這可能是因?yàn)槟莻€(gè)系統(tǒng)的負(fù)責(zé)人沒理解到底應(yīng)該如何更新庫存，也或者是他更新的時(shí)候采用的邏輯，沒有考慮到一些特殊情況。
這樣導(dǎo)致的結(jié)果就是，系統(tǒng)里的庫存和倉庫中實(shí)際的庫存，死活對不上。但就是不知道到底哪個(gè)環(huán)節(jié)出了問題，導(dǎo)致庫存數(shù)據(jù)出錯。
這個(gè)，其實(shí)就是一個(gè)典型的數(shù)據(jù)不一致的問題。
六、大型系統(tǒng)的數(shù)據(jù)不一致排查有多困難
當(dāng)面對一個(gè)大型分布式系統(tǒng)時(shí)，如果你之前壓根兒沒考慮過數(shù)據(jù)不一致的問題，那么我敢打賭，當(dāng)你負(fù)責(zé)的系統(tǒng)在線上被客服反饋有某個(gè)核心數(shù)據(jù)不一致的時(shí)候，你絕對會一臉蒙圈。
因?yàn)橐粋€(gè)核心數(shù)據(jù)的處理，少則涉及幾個(gè)系統(tǒng)的協(xié)作處理，多則涉及十個(gè)以上的系統(tǒng)的協(xié)作處理。
如果你沒有留存任何日志、或者僅僅就是有部分日志，然后基本就只能所有人干瞪眼，大家大眼對小眼，都盯著自己的代碼看。
大家根據(jù)一個(gè)數(shù)據(jù)最后的錯誤結(jié)果，比如數(shù)據(jù)87。10多個(gè)人對著自己的代碼，反復(fù)的思考，冥思苦想。
然后每個(gè)人都在大腦中瘋狂的模擬自己代碼的運(yùn)行，但是就是想不明白，為什么本來應(yīng)該是數(shù)據(jù)4的，結(jié)果出來了一個(gè)數(shù)據(jù)87？
所以現(xiàn)實(shí)問題就是這樣，這種數(shù)據(jù)不一致的問題，大概有以下幾個(gè)痛點(diǎn)：
七、下篇預(yù)告
所以針對本文描述的大型分布式系統(tǒng)數(shù)據(jù)不一致的問題，下篇文章我們將給出：在百億流量的場景下，一套復(fù)雜系統(tǒng)我們是如何構(gòu)建整套核心數(shù)據(jù)保證方案的。
敬請期待：
- 億級流量系統(tǒng)架構(gòu)之如何保證百億流量下的數(shù)據(jù)一致性(中)？
- 億級流量系統(tǒng)架構(gòu)之如何保證百億流量下的數(shù)據(jù)一致性(下)？
end
如有收獲，請幫忙轉(zhuǎn)發(fā)，您的鼓勵是作者最大的動力，謝謝！
一大波微服務(wù)、分布式、高并發(fā)、高可用的原創(chuàng)系列文章正在路上,
歡迎關(guān)注頭條號：石杉的架構(gòu)筆記
周一至周五早八點(diǎn)半！精品技術(shù)文章準(zhǔn)時(shí)送上！！！
十余年BAT架構(gòu)經(jīng)驗(yàn)傾囊相授
推薦閱讀
1、拜托！面試請不要再問我Spring Cloud底層原理！
2、微服務(wù)注冊中心如何承載大型系統(tǒng)的千萬級訪問？
3、「性能優(yōu)化之道」每秒上萬并發(fā)下的Spring Cloud參數(shù)優(yōu)化實(shí)戰(zhàn)
4、「“剁手黨”狂歡的背后」微服務(wù)架構(gòu)如何保障99.99%的高可用？
5、兄弟，用大白話告訴你小白都能看懂的Hadoop架構(gòu)原理
6、大規(guī)模集群下Hadoop NameNode如何承載每秒上千次的高并發(fā)訪問
7、「性能優(yōu)化的秘密」Hadoop如何將TB級大文件的上傳性能優(yōu)化上百倍
8、拜托，面試請不要再問我TCC分布式事務(wù)的實(shí)現(xiàn)原理！
9、最終一致性分布式事務(wù)如何保障實(shí)際生產(chǎn)中99.99%高可用？
10、拜托，面試請不要再問我Redis分布式鎖的實(shí)現(xiàn)原理
11、Hadoop底層算法如何優(yōu)雅的將大規(guī)模集群性能提升10倍以上？
12、億級流量系統(tǒng)架構(gòu)之如何支撐百億級數(shù)據(jù)的存儲與計(jì)算
13、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)高容錯分布式計(jì)算系統(tǒng)
14、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)承載百億流量的高性能架構(gòu)
15、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)每秒十萬查詢的高并發(fā)架構(gòu)
16、億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)全鏈路99.99%高可用架構(gòu)
17、七張圖徹底講清楚ZooKeeper分布式鎖的實(shí)現(xiàn)原理
18、大白話聊聊Java并發(fā)面試問題之volatile到底是什么？
19、大白話聊聊Java并發(fā)面試問題之Java 8如何優(yōu)化CAS性能？
20、大白話聊聊Java并發(fā)面試問題之談?wù)勀銓QS的理解？
21、大白話聊聊Java并發(fā)面試問題之微服務(wù)注冊中心的讀寫鎖優(yōu)化
22、互聯(lián)網(wǎng)公司的面試官是如何360°無死角考察候選人的？(上篇)
23、互聯(lián)網(wǎng)公司面試官是如何360°無死角考察候選人的？(下篇)
24、「Java進(jìn)階面試系列之一」你們系統(tǒng)架構(gòu)中為何要引入消息中間件？
25、「Java進(jìn)階面試系列之二」系統(tǒng)架構(gòu)引入消息中間件有什么缺點(diǎn)
26、「行走的Offer收割機(jī)」一位朋友斬獲BAT技術(shù)專家Offer的面試經(jīng)歷
27、「Java進(jìn)階面試系列之三」消息中間件在你們項(xiàng)目里是如何落地的？
28、扎心！線上服務(wù)宕機(jī)時(shí)，如何保證數(shù)據(jù)100%不丟失？
29、 一次JVM FullGC的背后，竟隱藏著驚心動魄的線上生產(chǎn)事故！
30、「高并發(fā)優(yōu)化實(shí)踐」10倍請求壓力來襲，你的系統(tǒng)會被擊垮嗎？
31、消息中間件集群崩潰，如何保證百萬生產(chǎn)數(shù)據(jù)不丟失？
32、億級流量系統(tǒng)架構(gòu)之如何在上萬并發(fā)場景下設(shè)計(jì)可擴(kuò)展架構(gòu)(上)？
33、億級流量系統(tǒng)架構(gòu)之如何在上萬并發(fā)場景下設(shè)計(jì)可擴(kuò)展架構(gòu)(中)？
34、億級流量系統(tǒng)架構(gòu)之如何在上萬并發(fā)場景下設(shè)計(jì)可擴(kuò)展架構(gòu)(下)？
35、億級流量架構(gòu)第二彈：你的系統(tǒng)真的無懈可擊嗎？
總結(jié)
以上是生活随笔為你收集整理的redis 亿级查询速度_亿级流量系统架构之如何保证百亿流量下的数据一致性（上）...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： word公式编辑器快捷键_科研利器|编辑
- 下一篇： 跨境电商自建站后台系统原型rp_Shop