來自：石杉的架構(gòu)筆記 一、前情回顧上篇文章（《億級流量系統(tǒng)架構(gòu)之如何設(shè)計(jì)每秒十萬查詢的高并發(fā)架構(gòu)》），聊了一下系統(tǒng)架構(gòu)中的查詢平臺。 我們采用冷熱數(shù)據(jù)分離：
最終，整套查詢架構(gòu)抗住每秒10萬的并發(fā)查詢請求，都沒問題。 本文作為這個架構(gòu)演進(jìn)系列的最后一篇文章，我們來聊聊高可用這個話題。所謂的高可用是啥意思呢？ 簡單來說，就是如此復(fù)雜的架構(gòu)中，任何一個環(huán)節(jié)都可能會故障，比如MQ集群可能會掛掉、KV集群可能會掛掉、MySQL集群可能會掛掉。那你怎么才能保證說，你這套復(fù)雜架構(gòu)中任何一個環(huán)節(jié)掛掉了，整套系統(tǒng)可以繼續(xù)運(yùn)行？ 這就是所謂的全鏈路99.99%高可用架構(gòu)，因?yàn)槲覀兊钠脚_產(chǎn)品是付費(fèi)級別的，付費(fèi)級別，必須要為客戶做到最好，可用性是務(wù)必要保證的！ 我們先來看看目前為止的架構(gòu)是長啥樣子的。  二、MQ集群高可用方案異步轉(zhuǎn)同步 + 限流算法 + 限制性丟棄流量 MQ集群故障其實(shí)是有概率的，而且挺正常的，因?yàn)橹熬陀械拇笮突ヂ?lián)網(wǎng)公司，MQ集群故障之后，導(dǎo)致全平臺幾個小時(shí)都無法交易，嚴(yán)重的會造成幾個小時(shí)公司就有數(shù)千萬的損失。我們之前也遇到過MQ集群故障的場景，但是并不是這個系統(tǒng)里。 大家想一下，如果這個鏈路中，萬一MQ集群故障了，會發(fā)生什么？ 看看右上角那個地方，數(shù)據(jù)庫binlog采集中間件就無法寫入數(shù)據(jù)到MQ集群了啊，然后后面的流控集群也無法消費(fèi)和存儲數(shù)據(jù)到KV集群了。這套架構(gòu)將會徹底失效，無法運(yùn)行。 這個是我們想要的效果嗎？那肯定不是的，如果是這樣的效果，這個架構(gòu)的可用性保障也太差了。 因此在這里，我們針對MQ集群的故障，設(shè)計(jì)的高可用保障方案是：異步轉(zhuǎn)同步 + 限流算法 + 限制性丟棄流量。 簡單來說，數(shù)據(jù)庫binlog采集環(huán)節(jié)一旦發(fā)現(xiàn)了MQ集群故障，也就是嘗試多次都無法寫入數(shù)據(jù)到MQ集群，此時(shí)就會觸發(fā)降級策略。不再寫入數(shù)據(jù)到MQ集群，而是轉(zhuǎn)而直接調(diào)用流控集群提供的備用流量接收接口，直接發(fā)送數(shù)據(jù)給流控集群。 但是流控集群也比較尷尬，之前用MQ集群就是削峰的啊，高峰期可以稍微積壓一點(diǎn)數(shù)據(jù)在MQ集群里，避免流量過大，沖垮后臺系統(tǒng)。 所以流控集群的備用流量接收接口，都是實(shí)現(xiàn)了限流算法的，也就是如果發(fā)現(xiàn)一旦流量過大超過了閾值，直接采取丟棄的策略，拋棄部分流量。 但是這個拋棄部分流量也是有講究的，你要怎么拋棄流量？如果你不管三七二十一，胡亂丟棄流量，可能會導(dǎo)致所有的商家看到的數(shù)據(jù)分析結(jié)果都是不準(zhǔn)確的。因此當(dāng)時(shí)選擇的策略是，僅僅選擇少量商家的數(shù)據(jù)全量拋棄，但是大部分商家的數(shù)據(jù)全量保存。 也就是說，比如你的平臺用戶有20萬吧，可能在這個丟棄流量的策略下，有2萬商家會發(fā)現(xiàn)看不到今天的數(shù)據(jù)了，但是18萬商家的數(shù)據(jù)是不受影響，都是準(zhǔn)確的。但是這個總比20萬商家的數(shù)據(jù)全部都是不準(zhǔn)確的好吧，所以在降級策略制定的時(shí)候，都是有權(quán)衡的。 這樣的話，在MQ集群故障的場景下，雖然可能會丟棄部分流量，導(dǎo)致最終數(shù)據(jù)分析結(jié)果有偏差，但是大部分商家的數(shù)據(jù)都是正常的。 大家看看下面的圖，高可用保障環(huán)節(jié)全部選用淺紅色來表示，這樣很清晰。  三、KV集群高可用保障方案臨時(shí)擴(kuò)容Slave集群 + 內(nèi)存級分片存儲 + 小時(shí)級數(shù)據(jù)粒度 下一個問題，如果KV集群掛了怎么辦？這個問題我們還真的遇到過，不過也不是在這個系統(tǒng)里，是在另外一個我們負(fù)責(zé)過的核心系統(tǒng)里，KV集群確實(shí)出過故障，直接從持續(xù)好多個小時(shí)，導(dǎo)致公司業(yè)務(wù)都幾近于停擺，損失也是幾千萬級別的。 大家看看那個架構(gòu)圖的右側(cè)部分，如果KV集群掛了咋辦？那也是災(zāi)難性的，因?yàn)槲覀兊募軜?gòu)選型里，直接就是基于kv集群來進(jìn)行海量數(shù)據(jù)存儲的，要是KV掛了，沒任何高可用保障措施的話，會導(dǎo)致流控集群無法把數(shù)據(jù)寫入KV集群，此時(shí)后續(xù)環(huán)節(jié)就無法繼續(xù)計(jì)算了。 我們當(dāng)時(shí)考慮過要不要引入另外一套存儲進(jìn)行雙寫，比如引入一套hbase集群，但是那樣依賴會搞的更加的復(fù)雜，打鐵還需自身硬，還是要從自身架構(gòu)來做優(yōu)化。 因此，當(dāng)時(shí)選擇的一套kv集群降級的預(yù)案是：臨時(shí)擴(kuò)容Slave集群 + 小時(shí)級數(shù)據(jù)粒度 + 內(nèi)存級分片存儲。 簡單來說，就是一旦發(fā)現(xiàn)kv集群故障，直接報(bào)警。我們收到報(bào)警之后，就會立馬啟動臨時(shí)預(yù)案，手動擴(kuò)容部署N倍的Slave計(jì)算集群。 接著同樣會手動打開流控集群的一個降級開關(guān)，然后流控集群會直接按照預(yù)設(shè)的hash算法分發(fā)數(shù)據(jù)到各個Slave計(jì)算節(jié)點(diǎn)。 這就是關(guān)鍵點(diǎn)，不要再基于kv集群存數(shù)據(jù)了，本身我們的Slave集群就是分布式計(jì)算的，那不是剛好可以臨時(shí)用作分布式存儲嗎！直接流控集群分發(fā)數(shù)據(jù)到Slave集群就行了，Slave節(jié)點(diǎn)將數(shù)據(jù)留存在內(nèi)存中即可。 然后Master節(jié)點(diǎn)在分發(fā)數(shù)據(jù)計(jì)算任務(wù)的時(shí)候，會保證計(jì)算任務(wù)分發(fā)到某個Slave節(jié)點(diǎn)之后，他只要基于本地內(nèi)存中的數(shù)據(jù)計(jì)算即可。 將Master節(jié)點(diǎn)和Slave節(jié)點(diǎn)都重構(gòu)一下，重構(gòu)成本不會太高，但是這樣就實(shí)現(xiàn)了本地?cái)?shù)據(jù)存儲 + 本地?cái)?shù)據(jù)計(jì)算的效果了。 但是這里同樣有一個問題，要知道當(dāng)日數(shù)據(jù)量可是很大的！如果你都放Slave集群內(nèi)存里還得了？ 所以說，既然是降級，又要做一個balance了。我們選擇的是小時(shí)級數(shù)據(jù)粒度的方案，也就是說，僅僅在Slave集群中保存最近一個小時(shí)的數(shù)據(jù)，然后計(jì)算數(shù)據(jù)指標(biāo)的時(shí)候，只能產(chǎn)出每個小時(shí)的數(shù)據(jù)指標(biāo)。 但是如果是針對一天的數(shù)據(jù)需要計(jì)算出來的數(shù)據(jù)指標(biāo)，此時(shí)降級過后就無法提供了，因?yàn)閮?nèi)存中永遠(yuǎn)只有最近一個小時(shí)的數(shù)據(jù)，這樣才能保證Slave集群的內(nèi)存不會被撐爆。 對用戶而言，就是只能看當(dāng)天每個小時(shí)的數(shù)據(jù)指標(biāo)，但是全天匯總的暫時(shí)就無法看到。  四、實(shí)時(shí)計(jì)算鏈路高可用保障方案計(jì)算任務(wù)重分配 + 主備切換機(jī)制 下一塊就是實(shí)時(shí)計(jì)算鏈路的高可用保障方案了，其實(shí)這個之前給大家說過了，實(shí)時(shí)計(jì)算鏈路是一個分布式的架構(gòu)，所以要么是Slave節(jié)點(diǎn)宕機(jī)，要么是Master節(jié)點(diǎn)宕機(jī)。 其實(shí)這個倒沒什么，因?yàn)镾lave節(jié)點(diǎn)宕機(jī)，Master節(jié)點(diǎn)感知到了，會重新分配計(jì)算任務(wù)給其他的計(jì)算節(jié)點(diǎn)；如果Master節(jié)點(diǎn)宕機(jī)，就會基于Active-Standby的高可用架構(gòu)，自動主備切換。 咱們直接把架構(gòu)圖里的實(shí)時(shí)計(jì)算鏈路中的高可用環(huán)節(jié)標(biāo)成紅色就可以了。  五、熱數(shù)據(jù)高可用保障方案自研緩存集群查詢引擎 + JVM本地緩存 + 限流機(jī)制 接著咱們來看左側(cè)的數(shù)據(jù)查詢那塊，熱數(shù)據(jù)也就是提供實(shí)時(shí)計(jì)算鏈路寫入當(dāng)日數(shù)據(jù)的計(jì)算結(jié)果的，用的是MySQL集群來承載主體數(shù)據(jù)，然后前面掛載一個緩存集群。 如果出現(xiàn)故障，只有兩種情況：一種是MySQL集群故障，一種是緩存集群故障。 咱們分開說，如果是MySQL集群故障，我們采取的方案是：實(shí)時(shí)計(jì)算結(jié)果直接寫入緩存集群，然后因?yàn)闆]有MySQL支撐，所以沒法使用SQL來從MySQL中組裝報(bào)表數(shù)據(jù)。 因此，我們自研了一套基于緩存集群的內(nèi)存級查詢引擎，支持簡單的查詢語法，可以直接對緩存集群中的數(shù)據(jù)實(shí)現(xiàn)條件過濾、分組聚合、排序等基本查詢語義，然后直接對緩存中的數(shù)據(jù)查詢分析過后返回。 但是這樣唯一的不好，就是緩存集群承載的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)沒有MySQL集群大，所以會導(dǎo)致部分用戶看不到數(shù)據(jù)，部分用戶可以看到數(shù)據(jù)。不過這個既然是降級 ，那肯定是要損失掉部分用戶體驗(yàn)的。 如果是緩存集群故障，我們會有一個查詢平臺里的本地緩存，使用ehcache等框架就可以實(shí)現(xiàn)，從mysql中查出來的數(shù)據(jù)在查詢平臺的jvm本地緩存里cache一下，也可以用作一定的緩存支撐高并發(fā)的效果。而且查詢平臺實(shí)現(xiàn)限流機(jī)制，如果查詢流量超過自身承載范圍，就限流，直接對查詢返回異常響應(yīng)。  六、冷數(shù)據(jù)高可用保障方案收集查詢?nèi)罩?+ 離線日志分析 + 緩存高頻查詢 其實(shí)大家看上面的圖就知道，冷數(shù)據(jù)架構(gòu)本身就比比較復(fù)雜，涉及到ES、HBase等東西，如果你要是想做到一點(diǎn)ES、HBase宕機(jī)，然后還搞點(diǎn)兒什么降級方案，還是挺難的。 你總不能ES不能用了，臨時(shí)走Solr？或者HBase不能用了，臨時(shí)走KV集群？都不行。那個實(shí)現(xiàn)復(fù)雜度太高，不合適。 所以當(dāng)時(shí)我們采取的方法就是，對最近一段時(shí)間用戶發(fā)起的離線查詢的請求日志進(jìn)行收集，然后對請求日志在每天凌晨進(jìn)行分析，分析出來那種每個用戶會經(jīng)常、多次、高頻發(fā)起的冷數(shù)據(jù)查詢請求，然后對這個特定的查詢（比如特殊的一組條件，時(shí)間范圍，維度組合）對應(yīng)的結(jié)果，進(jìn)行緩存。 這樣就直接把各個用戶高頻發(fā)起的冷數(shù)據(jù)查詢請求的結(jié)果每天動態(tài)分析，動態(tài)放入緩存集群中。比如有的用戶每天都會看一下上周一周的數(shù)據(jù)分析結(jié)果，或者上個月一個月的數(shù)據(jù)分析結(jié)果，那么就可以把這些結(jié)果提前緩存起來。 一旦ES、HBase等集群故障，直接對外冷數(shù)據(jù)查詢，僅僅提供這些提前緩存好的高頻查詢即可，非高頻無緩存的查詢結(jié)果，就是看不到了。  七、最終總結(jié)上述系統(tǒng)到目前為止，已經(jīng)演進(jìn)到非常不錯的狀態(tài)了，因?yàn)檫@套架構(gòu)已經(jīng)解決了百億流量高并發(fā)寫入，海量數(shù)據(jù)存儲，高性能計(jì)算，高并發(fā)查詢，高可用保障，等一系列的技術(shù)挑戰(zhàn)。線上生產(chǎn)系統(tǒng)運(yùn)行非常穩(wěn)定，足以應(yīng)對各種生產(chǎ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ì)量保障，等等一系列的事情，不過文章就不再繼續(xù)寫下去了，因?yàn)槲恼鲁休d內(nèi)容量太少，很難寫清楚所有的東西。 其實(shí)有不少同學(xué)跟我反饋說，感覺看不懂這個架構(gòu)演進(jìn)系列的文章，其實(shí)很正常，因?yàn)槲恼鲁休d內(nèi)容較少，這里有大量的細(xì)節(jié)性的技術(shù)方案和落地的實(shí)施，都沒法寫出來，只能寫一下大型系統(tǒng)架構(gòu)不斷演進(jìn)，解決各種線上技術(shù)挑戰(zhàn)的一個過程。 我覺得對于一些年輕的同學(xué)，主要還是了解一下系統(tǒng)架構(gòu)演進(jìn)的過程，對于一些年長已經(jīng)做架構(gòu)設(shè)計(jì)的兄弟，應(yīng)該可以啟發(fā)一些思路。
|
|
|
