來(lái)自：石杉的架構(gòu)筆記

一、前情回顧

上篇文章（《億級(jí)流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)每秒十萬(wàn)查詢(xún)的高并發(fā)架構(gòu)》），聊了一下系統(tǒng)架構(gòu)中的查詢(xún)平臺(tái)。

我們采用冷熱數(shù)據(jù)分離：

冷數(shù)據(jù)基于HBase+Elasticsearch+純內(nèi)存自研的查詢(xún)引擎，解決了海量歷史數(shù)據(jù)的高性能毫秒級(jí)的查詢(xún)
熱數(shù)據(jù)基于緩存集群+MySQL集群做到了當(dāng)日數(shù)據(jù)的幾十毫秒級(jí)別的查詢(xún)性能。

最終，整套查詢(xún)架構(gòu)抗住每秒10萬(wàn)的并發(fā)查詢(xún)請(qǐng)求，都沒(méi)問(wèn)題。

本文作為這個(gè)架構(gòu)演進(jìn)系列的最后一篇文章，我們來(lái)聊聊高可用這個(gè)話(huà)題。所謂的高可用是啥意思呢？

簡(jiǎn)單來(lái)說(shuō)，就是如此復(fù)雜的架構(gòu)中，任何一個(gè)環(huán)節(jié)都可能會(huì)故障，比如MQ集群可能會(huì)掛掉、KV集群可能會(huì)掛掉、MySQL集群可能會(huì)掛掉。那你怎么才能保證說(shuō)，你這套復(fù)雜架構(gòu)中任何一個(gè)環(huán)節(jié)掛掉了，整套系統(tǒng)可以繼續(xù)運(yùn)行？

這就是所謂的全鏈路99.99%高可用架構(gòu)，因?yàn)槲覀兊钠脚_(tái)產(chǎn)品是付費(fèi)級(jí)別的，付費(fèi)級(jí)別，必須要為客戶(hù)做到最好，可用性是務(wù)必要保證的！

我們先來(lái)看看目前為止的架構(gòu)是長(zhǎng)啥樣子的。

億級(jí)流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)全鏈路99.99%高可用架構(gòu)

二、MQ集群高可用方案

異步轉(zhuǎn)同步 + 限流算法 + 限制性丟棄流量

MQ集群故障其實(shí)是有概率的，而且挺正常的，因?yàn)橹熬陀械拇笮突ヂ?lián)網(wǎng)公司，MQ集群故障之后，導(dǎo)致全平臺(tái)幾個(gè)小時(shí)都無(wú)法交易，嚴(yán)重的會(huì)造成幾個(gè)小時(shí)公司就有數(shù)千萬(wàn)的損失。我們之前也遇到過(guò)MQ集群故障的場(chǎng)景，但是并不是這個(gè)系統(tǒng)里。

大家想一下，如果這個(gè)鏈路中，萬(wàn)一MQ集群故障了，會(huì)發(fā)生什么？

看看右上角那個(gè)地方，數(shù)據(jù)庫(kù)binlog采集中間件就無(wú)法寫(xiě)入數(shù)據(jù)到MQ集群了啊，然后后面的流控集群也無(wú)法消費(fèi)和存儲(chǔ)數(shù)據(jù)到KV集群了。這套架構(gòu)將會(huì)徹底失效，無(wú)法運(yùn)行。

這個(gè)是我們想要的效果嗎？那肯定不是的，如果是這樣的效果，這個(gè)架構(gòu)的可用性保障也太差了。

因此在這里，我們針對(duì)MQ集群的故障，設(shè)計(jì)的高可用保障方案是：異步轉(zhuǎn)同步 + 限流算法 + 限制性丟棄流量。

簡(jiǎn)單來(lái)說(shuō)，數(shù)據(jù)庫(kù)binlog采集環(huán)節(jié)一旦發(fā)現(xiàn)了MQ集群故障，也就是嘗試多次都無(wú)法寫(xiě)入數(shù)據(jù)到MQ集群，此時(shí)就會(huì)觸發(fā)降級(jí)策略。不再寫(xiě)入數(shù)據(jù)到MQ集群，而是轉(zhuǎn)而直接調(diào)用流控集群提供的備用流量接收接口，直接發(fā)送數(shù)據(jù)給流控集群。

但是流控集群也比較尷尬，之前用MQ集群就是削峰的啊，高峰期可以稍微積壓一點(diǎn)數(shù)據(jù)在MQ集群里，避免流量過(guò)大，沖垮后臺(tái)系統(tǒng)。

所以流控集群的備用流量接收接口，都是實(shí)現(xiàn)了限流算法的，也就是如果發(fā)現(xiàn)一旦流量過(guò)大超過(guò)了閾值，直接采取丟棄的策略，拋棄部分流量。

但是這個(gè)拋棄部分流量也是有講究的，你要怎么拋棄流量？如果你不管三七二十一，胡亂丟棄流量，可能會(huì)導(dǎo)致所有的商家看到的數(shù)據(jù)分析結(jié)果都是不準(zhǔn)確的。因此當(dāng)時(shí)選擇的策略是，僅僅選擇少量商家的數(shù)據(jù)全量拋棄，但是大部分商家的數(shù)據(jù)全量保存。

也就是說(shuō)，比如你的平臺(tái)用戶(hù)有20萬(wàn)吧，可能在這個(gè)丟棄流量的策略下，有2萬(wàn)商家會(huì)發(fā)現(xiàn)看不到今天的數(shù)據(jù)了，但是18萬(wàn)商家的數(shù)據(jù)是不受影響，都是準(zhǔn)確的。但是這個(gè)總比20萬(wàn)商家的數(shù)據(jù)全部都是不準(zhǔn)確的好吧，所以在降級(jí)策略制定的時(shí)候，都是有權(quán)衡的。

這樣的話(huà)，在MQ集群故障的場(chǎng)景下，雖然可能會(huì)丟棄部分流量，導(dǎo)致最終數(shù)據(jù)分析結(jié)果有偏差，但是大部分商家的數(shù)據(jù)都是正常的。

大家看看下面的圖，高可用保障環(huán)節(jié)全部選用淺紅色來(lái)表示，這樣很清晰。

三、KV集群高可用保障方案

臨時(shí)擴(kuò)容Slave集群 + 內(nèi)存級(jí)分片存儲(chǔ) + 小時(shí)級(jí)數(shù)據(jù)粒度

下一個(gè)問(wèn)題，如果KV集群掛了怎么辦？這個(gè)問(wèn)題我們還真的遇到過(guò)，不過(guò)也不是在這個(gè)系統(tǒng)里，是在另外一個(gè)我們負(fù)責(zé)過(guò)的核心系統(tǒng)里，KV集群確實(shí)出過(guò)故障，直接從持續(xù)好多個(gè)小時(shí)，導(dǎo)致公司業(yè)務(wù)都幾近于停擺，損失也是幾千萬(wàn)級(jí)別的。

大家看看那個(gè)架構(gòu)圖的右側(cè)部分，如果KV集群掛了咋辦？那也是災(zāi)難性的，因?yàn)槲覀兊募軜?gòu)選型里，直接就是基于kv集群來(lái)進(jìn)行海量數(shù)據(jù)存儲(chǔ)的，要是KV掛了，沒(méi)任何高可用保障措施的話(huà)，會(huì)導(dǎo)致流控集群無(wú)法把數(shù)據(jù)寫(xiě)入KV集群，此時(shí)后續(xù)環(huán)節(jié)就無(wú)法繼續(xù)計(jì)算了。

我們當(dāng)時(shí)考慮過(guò)要不要引入另外一套存儲(chǔ)進(jìn)行雙寫(xiě)，比如引入一套hbase集群，但是那樣依賴(lài)會(huì)搞的更加的復(fù)雜，打鐵還需自身硬，還是要從自身架構(gòu)來(lái)做優(yōu)化。

因此，當(dāng)時(shí)選擇的一套kv集群降級(jí)的預(yù)案是：臨時(shí)擴(kuò)容Slave集群 + 小時(shí)級(jí)數(shù)據(jù)粒度 + 內(nèi)存級(jí)分片存儲(chǔ)。

簡(jiǎn)單來(lái)說(shuō)，就是一旦發(fā)現(xiàn)kv集群故障，直接報(bào)警。我們收到報(bào)警之后，就會(huì)立馬啟動(dòng)臨時(shí)預(yù)案，手動(dòng)擴(kuò)容部署N倍的Slave計(jì)算集群。

接著同樣會(huì)手動(dòng)打開(kāi)流控集群的一個(gè)降級(jí)開(kāi)關(guān)，然后流控集群會(huì)直接按照預(yù)設(shè)的hash算法分發(fā)數(shù)據(jù)到各個(gè)Slave計(jì)算節(jié)點(diǎn)。

這就是關(guān)鍵點(diǎn)，不要再基于kv集群存數(shù)據(jù)了，本身我們的Slave集群就是分布式計(jì)算的，那不是剛好可以臨時(shí)用作分布式存儲(chǔ)嗎！直接流控集群分發(fā)數(shù)據(jù)到Slave集群就行了，Slave節(jié)點(diǎn)將數(shù)據(jù)留存在內(nèi)存中即可。

然后Master節(jié)點(diǎn)在分發(fā)數(shù)據(jù)計(jì)算任務(wù)的時(shí)候，會(huì)保證計(jì)算任務(wù)分發(fā)到某個(gè)Slave節(jié)點(diǎn)之后，他只要基于本地內(nèi)存中的數(shù)據(jù)計(jì)算即可。

將Master節(jié)點(diǎn)和Slave節(jié)點(diǎn)都重構(gòu)一下，重構(gòu)成本不會(huì)太高，但是這樣就實(shí)現(xiàn)了本地?cái)?shù)據(jù)存儲(chǔ) + 本地?cái)?shù)據(jù)計(jì)算的效果了。

但是這里同樣有一個(gè)問(wèn)題，要知道當(dāng)日數(shù)據(jù)量可是很大的！如果你都放Slave集群內(nèi)存里還得了？

所以說(shuō)，既然是降級(jí)，又要做一個(gè)balance了。我們選擇的是小時(shí)級(jí)數(shù)據(jù)粒度的方案，也就是說(shuō)，僅僅在Slave集群中保存最近一個(gè)小時(shí)的數(shù)據(jù)，然后計(jì)算數(shù)據(jù)指標(biāo)的時(shí)候，只能產(chǎn)出每個(gè)小時(shí)的數(shù)據(jù)指標(biāo)。

但是如果是針對(duì)一天的數(shù)據(jù)需要計(jì)算出來(lái)的數(shù)據(jù)指標(biāo)，此時(shí)降級(jí)過(guò)后就無(wú)法提供了，因?yàn)閮?nèi)存中永遠(yuǎn)只有最近一個(gè)小時(shí)的數(shù)據(jù)，這樣才能保證Slave集群的內(nèi)存不會(huì)被撐爆。

對(duì)用戶(hù)而言，就是只能看當(dāng)天每個(gè)小時(shí)的數(shù)據(jù)指標(biāo)，但是全天匯總的暫時(shí)就無(wú)法看到。

四、實(shí)時(shí)計(jì)算鏈路高可用保障方案

計(jì)算任務(wù)重分配 + 主備切換機(jī)制

下一塊就是實(shí)時(shí)計(jì)算鏈路的高可用保障方案了，其實(shí)這個(gè)之前給大家說(shuō)過(guò)了，實(shí)時(shí)計(jì)算鏈路是一個(gè)分布式的架構(gòu)，所以要么是Slave節(jié)點(diǎn)宕機(jī)，要么是Master節(jié)點(diǎn)宕機(jī)。

其實(shí)這個(gè)倒沒(méi)什么，因?yàn)镾lave節(jié)點(diǎn)宕機(jī)，Master節(jié)點(diǎn)感知到了，會(huì)重新分配計(jì)算任務(wù)給其他的計(jì)算節(jié)點(diǎn)；如果Master節(jié)點(diǎn)宕機(jī)，就會(huì)基于Active-Standby的高可用架構(gòu)，自動(dòng)主備切換。

咱們直接把架構(gòu)圖里的實(shí)時(shí)計(jì)算鏈路中的高可用環(huán)節(jié)標(biāo)成紅色就可以了。

五、熱數(shù)據(jù)高可用保障方案

自研緩存集群查詢(xún)引擎 + JVM本地緩存 + 限流機(jī)制

接著咱們來(lái)看左側(cè)的數(shù)據(jù)查詢(xún)那塊，熱數(shù)據(jù)也就是提供實(shí)時(shí)計(jì)算鏈路寫(xiě)入當(dāng)日數(shù)據(jù)的計(jì)算結(jié)果的，用的是MySQL集群來(lái)承載主體數(shù)據(jù)，然后前面掛載一個(gè)緩存集群。

如果出現(xiàn)故障，只有兩種情況：一種是MySQL集群故障，一種是緩存集群故障。

咱們分開(kāi)說(shuō)，如果是MySQL集群故障，我們采取的方案是：實(shí)時(shí)計(jì)算結(jié)果直接寫(xiě)入緩存集群，然后因?yàn)闆](méi)有MySQL支撐，所以沒(méi)法使用SQL來(lái)從MySQL中組裝報(bào)表數(shù)據(jù)。

因此，我們自研了一套基于緩存集群的內(nèi)存級(jí)查詢(xún)引擎，支持簡(jiǎn)單的查詢(xún)語(yǔ)法，可以直接對(duì)緩存集群中的數(shù)據(jù)實(shí)現(xiàn)條件過(guò)濾、分組聚合、排序等基本查詢(xún)語(yǔ)義，然后直接對(duì)緩存中的數(shù)據(jù)查詢(xún)分析過(guò)后返回。

但是這樣唯一的不好，就是緩存集群承載的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)沒(méi)有MySQL集群大，所以會(huì)導(dǎo)致部分用戶(hù)看不到數(shù)據(jù)，部分用戶(hù)可以看到數(shù)據(jù)。不過(guò)這個(gè)既然是降級(jí) ，那肯定是要損失掉部分用戶(hù)體驗(yàn)的。

如果是緩存集群故障，我們會(huì)有一個(gè)查詢(xún)平臺(tái)里的本地緩存，使用ehcache等框架就可以實(shí)現(xiàn)，從mysql中查出來(lái)的數(shù)據(jù)在查詢(xún)平臺(tái)的jvm本地緩存里cache一下，也可以用作一定的緩存支撐高并發(fā)的效果。而且查詢(xún)平臺(tái)實(shí)現(xiàn)限流機(jī)制，如果查詢(xún)流量超過(guò)自身承載范圍，就限流，直接對(duì)查詢(xún)返回異常響應(yīng)。

六、冷數(shù)據(jù)高可用保障方案

收集查詢(xún)?nèi)罩?+ 離線(xiàn)日志分析 + 緩存高頻查詢(xún)

其實(shí)大家看上面的圖就知道，冷數(shù)據(jù)架構(gòu)本身就比比較復(fù)雜，涉及到ES、HBase等東西，如果你要是想做到一點(diǎn)ES、HBase宕機(jī)，然后還搞點(diǎn)兒什么降級(jí)方案，還是挺難的。

你總不能ES不能用了，臨時(shí)走Solr？或者HBase不能用了，臨時(shí)走KV集群？都不行。那個(gè)實(shí)現(xiàn)復(fù)雜度太高，不合適。

所以當(dāng)時(shí)我們采取的方法就是，對(duì)最近一段時(shí)間用戶(hù)發(fā)起的離線(xiàn)查詢(xún)的請(qǐng)求日志進(jìn)行收集，然后對(duì)請(qǐng)求日志在每天凌晨進(jìn)行分析，分析出來(lái)那種每個(gè)用戶(hù)會(huì)經(jīng)常、多次、高頻發(fā)起的冷數(shù)據(jù)查詢(xún)請(qǐng)求，然后對(duì)這個(gè)特定的查詢(xún)（比如特殊的一組條件，時(shí)間范圍，維度組合）對(duì)應(yīng)的結(jié)果，進(jìn)行緩存。

這樣就直接把各個(gè)用戶(hù)高頻發(fā)起的冷數(shù)據(jù)查詢(xún)請(qǐng)求的結(jié)果每天動(dòng)態(tài)分析，動(dòng)態(tài)放入緩存集群中。比如有的用戶(hù)每天都會(huì)看一下上周一周的數(shù)據(jù)分析結(jié)果，或者上個(gè)月一個(gè)月的數(shù)據(jù)分析結(jié)果，那么就可以把這些結(jié)果提前緩存起來(lái)。

一旦ES、HBase等集群故障，直接對(duì)外冷數(shù)據(jù)查詢(xún)，僅僅提供這些提前緩存好的高頻查詢(xún)即可，非高頻無(wú)緩存的查詢(xún)結(jié)果，就是看不到了。

七、最終總結(jié)

上述系統(tǒng)到目前為止，已經(jīng)演進(jìn)到非常不錯(cuò)的狀態(tài)了，因?yàn)檫@套架構(gòu)已經(jīng)解決了百億流量高并發(fā)寫(xiě)入，海量數(shù)據(jù)存儲(chǔ)，高性能計(jì)算，高并發(fā)查詢(xún)，高可用保障，等一系列的技術(shù)挑戰(zhàn)。線(xiàn)上生產(chǎn)系統(tǒng)運(yùn)行非常穩(wěn)定，足以應(yīng)對(duì)各種生產(chǎn)級(jí)的問(wèn)題。

其實(shí)再往后這套系統(tǒng)架構(gòu)還可以繼續(xù)演進(jìn)，因?yàn)榇笮拖到y(tǒng)的架構(gòu)演進(jìn)，可以持續(xù)N多年，比如我們后面還有分布式系統(tǒng)全鏈路數(shù)據(jù)一致性保障、高穩(wěn)定性工程質(zhì)量保障，等等一系列的事情，不過(guò)文章就不再繼續(xù)寫(xiě)下去了，因?yàn)槲恼鲁休d內(nèi)容量太少，很難寫(xiě)清楚所有的東西。

其實(shí)有不少同學(xué)跟我反饋說(shuō)，感覺(jué)看不懂這個(gè)架構(gòu)演進(jìn)系列的文章，其實(shí)很正常，因?yàn)槲恼鲁休d內(nèi)容較少，這里有大量的細(xì)節(jié)性的技術(shù)方案和落地的實(shí)施，都沒(méi)法寫(xiě)出來(lái)，只能寫(xiě)一下大型系統(tǒng)架構(gòu)不斷演進(jìn)，解決各種線(xiàn)上技術(shù)挑戰(zhàn)的一個(gè)過(guò)程。

我覺(jué)得對(duì)于一些年輕的同學(xué)，主要還是了解一下系統(tǒng)架構(gòu)演進(jìn)的過(guò)程，對(duì)于一些年長(zhǎng)已經(jīng)做架構(gòu)設(shè)計(jì)的兄弟，應(yīng)該可以啟發(fā)一些思路。