一、寫在前面

上篇文章：??別光看NB的Github開源項(xiàng)目，你得參考他們?nèi)ピO(shè)計(jì)自己的架構(gòu)??，聊了一下商家數(shù)據(jù)平臺(tái)第一個(gè)階段的架構(gòu)演進(jìn)。通過(guò)離線與實(shí)時(shí)計(jì)算鏈路的拆分，離線計(jì)算的增量計(jì)算優(yōu)化，實(shí)時(shí)計(jì)算的滑動(dòng)時(shí)間窗口計(jì)算引擎，分庫(kù)分表 + 讀寫分離，等各種技術(shù)手段，支撐住了百億量級(jí)的數(shù)據(jù)量的存儲(chǔ)與計(jì)算。

我們先來(lái)回看一下當(dāng)時(shí)的那個(gè)架構(gòu)圖，然后繼續(xù)聊聊這套架構(gòu)在面對(duì)高并發(fā)、高可用、高性能等各種技術(shù)挑戰(zhàn)下，應(yīng)該如何繼續(xù)演進(jìn)。

二、active-standby高可用架構(gòu)

大家看看上面的那個(gè)架構(gòu)圖，有沒(méi)有發(fā)現(xiàn)里面有一個(gè)比較致命的問(wèn)題？就是如何避免系統(tǒng)單點(diǎn)故障！

在最初的部署架構(gòu)下，因?yàn)閿?shù)據(jù)平臺(tái)系統(tǒng)對(duì)CPU、內(nèi)存、磁盤的要求很高，所以我們是單機(jī)部署在一臺(tái)較高配置的虛擬機(jī)上的，16核CPU、64G內(nèi)存、SSD固態(tài)硬盤。這個(gè)機(jī)器的配置是可以保證數(shù)據(jù)平臺(tái)系統(tǒng)在高負(fù)載之下正常運(yùn)行的。

但是如果僅僅是單機(jī)部署數(shù)據(jù)平臺(tái)系統(tǒng)的話，會(huì)導(dǎo)致致命的單點(diǎn)故障問(wèn)題，也就是如果單臺(tái)機(jī)器上部署的數(shù)據(jù)平臺(tái)系統(tǒng)宕機(jī)的話，就會(huì)立馬導(dǎo)致整套系統(tǒng)崩潰。

因此在初期的階段，我們對(duì)數(shù)據(jù)平臺(tái)實(shí)現(xiàn)了active-standby的高可用架構(gòu)，也就是一共部署在兩臺(tái)機(jī)器上，但是同一時(shí)間只有一臺(tái)機(jī)器是會(huì)運(yùn)行的，但是另外一臺(tái)機(jī)器是備用的。處于active狀態(tài)的系統(tǒng)會(huì)將滑動(dòng)窗口計(jì)算引擎的計(jì)算狀態(tài)和結(jié)果寫入zookeeper中，作為元數(shù)據(jù)存儲(chǔ)起來(lái)。

關(guān)于元數(shù)據(jù)基于zookeeper來(lái)存儲(chǔ)，我們是充分參考了開源的Storm流式計(jì)算引擎的架構(gòu)實(shí)現(xiàn)，因?yàn)镾torm作為一個(gè)非常優(yōu)秀的分布式流式計(jì)算系統(tǒng)，同樣需要高并發(fā)的讀寫大量的計(jì)算中間狀態(tài)和數(shù)據(jù)，他就是基于zookeeper來(lái)進(jìn)行存儲(chǔ)的。

本身zookeeper的讀寫性能非常的高，而且zookeeper集群自身就可以做到非常高的可用性，同時(shí)還提供了大量的分布式系統(tǒng)需要的功能支持，包括分布式鎖、分布式協(xié)調(diào)、master選舉、主備切換等等。

因此基于zookeeper我們實(shí)現(xiàn)了active-standby的主備自動(dòng)切換，如果active節(jié)點(diǎn)宕機(jī)，那么standby節(jié)點(diǎn)感知到，會(huì)自動(dòng)切花為active，同時(shí)自動(dòng)讀取他們共享的一個(gè)計(jì)算引擎的中間狀態(tài)，然后繼續(xù)恢復(fù)之前的計(jì)算。

大家看下面的圖，一起感受一下。

在完成上述的active-standby架構(gòu)之后，肯定是消除掉了系統(tǒng)的單點(diǎn)故障了，保證了基本的可用性。而且在實(shí)際的線上生產(chǎn)環(huán)境中表現(xiàn)還不錯(cuò)，一年系統(tǒng)總有個(gè)幾次會(huì)出現(xiàn)故障，但是每次都能自動(dòng)切換standby機(jī)器穩(wěn)定運(yùn)行。

這里隨便給大家舉幾個(gè)生產(chǎn)環(huán)境機(jī)器故障的例子，因?yàn)椴渴鹪诠镜脑骗h(huán)境中，用的都是虛擬機(jī)，可能遇到的坑爹故障包括但不限于下面幾種情況：

• 虛擬機(jī)所在的宿主機(jī)掛了
• 虛擬機(jī)的網(wǎng)絡(luò)出現(xiàn)故障
• 負(fù)載過(guò)高導(dǎo)致磁盤壞了

所以在線上高負(fù)載環(huán)境中，永遠(yuǎn)別寄希望于機(jī)器永遠(yuǎn)不宕機(jī)，你要隨時(shí)做好準(zhǔn)備，機(jī)器會(huì)掛！系統(tǒng)必須做好充分的故障預(yù)測(cè)、高可用架構(gòu)以及故障演練，保證各種場(chǎng)景下都可以繼續(xù)運(yùn)行。

三、Master-Slave架構(gòu)的分布式計(jì)算系統(tǒng)

但是此時(shí)另外一個(gè)問(wèn)題又來(lái)了，大家考慮一個(gè)問(wèn)題，數(shù)據(jù)平臺(tái)系統(tǒng)其實(shí)最核心的任務(wù)就是對(duì)一個(gè)一個(gè)的時(shí)間窗口中的數(shù)據(jù)進(jìn)行計(jì)算，但是隨著每天的日增數(shù)據(jù)量越來(lái)越多，每個(gè)時(shí)間窗口內(nèi)的數(shù)據(jù)量也會(huì)越來(lái)越大，同時(shí)會(huì)導(dǎo)致數(shù)據(jù)平臺(tái)系統(tǒng)的計(jì)算負(fù)載越來(lái)越高。

在線上生產(chǎn)環(huán)境表現(xiàn)出來(lái)的情況就是，數(shù)據(jù)平臺(tái)系統(tǒng)部署機(jī)器的CPU負(fù)載越來(lái)越高，高峰期很容易會(huì)100%，機(jī)器壓力較大。新一輪的系統(tǒng)重構(gòu)，勢(shì)在必行。

首先我們將數(shù)據(jù)平臺(tái)系統(tǒng)徹底重構(gòu)和設(shè)計(jì)為一套分布式的計(jì)算系統(tǒng)，將任務(wù)調(diào)度與任務(wù)計(jì)算兩個(gè)職責(zé)進(jìn)行分離，有一個(gè)專門的Master節(jié)點(diǎn)負(fù)責(zé)讀取切分好的數(shù)據(jù)分片（也就是所謂的時(shí)間窗口，一個(gè)窗口就是一個(gè)數(shù)據(jù)分片），然后將各個(gè)數(shù)據(jù)分片的計(jì)算任務(wù)分發(fā)給多個(gè)Slave節(jié)點(diǎn)。

Slave節(jié)點(diǎn)的任務(wù)就是專門接收一個(gè)一個(gè)的計(jì)算任務(wù)，每個(gè)計(jì)算任務(wù)就是對(duì)一個(gè)數(shù)據(jù)分片執(zhí)行一個(gè)幾百行到上千行的復(fù)雜SQL語(yǔ)句來(lái)產(chǎn)出對(duì)應(yīng)的數(shù)據(jù)分析結(jié)果。

同時(shí)對(duì)Master節(jié)點(diǎn)，我們?yōu)榱吮苊馄涑霈F(xiàn)單點(diǎn)故障，所以還是沿用了之前的Active-Standby架構(gòu)，Master節(jié)點(diǎn)是在線上部署一主一備的，平時(shí)都是active節(jié)點(diǎn)運(yùn)作，一旦宕機(jī)，standby節(jié)點(diǎn)會(huì)切換為active節(jié)點(diǎn)，然后自動(dòng)調(diào)度運(yùn)行各個(gè)計(jì)算任務(wù)。

這套架構(gòu)部署上線之后，效果還是很不錯(cuò)的，因?yàn)镸aster節(jié)點(diǎn)其實(shí)就是讀取數(shù)據(jù)分片，然后為每個(gè)數(shù)據(jù)分片構(gòu)造計(jì)算任務(wù)，接著就是將計(jì)算任務(wù)分發(fā)給各個(gè)Slave節(jié)點(diǎn)進(jìn)行計(jì)算。

Master節(jié)點(diǎn)幾乎沒(méi)有太多復(fù)雜的任務(wù)，部署一臺(tái)高配置的機(jī)器就絕對(duì)沒(méi)問(wèn)題。

負(fù)載主要在Slave節(jié)點(diǎn)，而Slave節(jié)點(diǎn)因?yàn)椴渴鹆硕嗯_(tái)機(jī)器，每臺(tái)機(jī)器就是執(zhí)行部分計(jì)算任務(wù)，所以很大程度上降低了單臺(tái)Slave節(jié)點(diǎn)的負(fù)載，而且只要有需要，隨時(shí)可以對(duì)Slave集群進(jìn)行擴(kuò)容部署更多的機(jī)器，這樣無(wú)論計(jì)算任務(wù)有多繁忙，都可以不斷的擴(kuò)容，保證單臺(tái)Slave機(jī)器的負(fù)載不會(huì)過(guò)高。

四、彈性計(jì)算資源調(diào)度機(jī)制

在解決了單臺(tái)機(jī)器計(jì)算負(fù)載壓力過(guò)高的問(wèn)題之后，我們又遇到了下一個(gè)問(wèn)題，就是在線上生產(chǎn)環(huán)境中偶爾會(huì)發(fā)現(xiàn)某個(gè)計(jì)算任務(wù)耗時(shí)過(guò)長(zhǎng)，導(dǎo)致某臺(tái)Slave機(jī)器積壓了大量的計(jì)算任務(wù)一直遲遲得不到處理。

這個(gè)問(wèn)題的產(chǎn)生，其實(shí)主要是由于系統(tǒng)的高峰和低谷的數(shù)據(jù)差異導(dǎo)致的。

大家可以想想，在高峰期，瞬時(shí)涌入的數(shù)據(jù)量很大，很可能某個(gè)數(shù)據(jù)分片包含的數(shù)據(jù)量過(guò)大，達(dá)到普通數(shù)據(jù)分片的幾倍甚至幾十倍，這是原因之一。

還有一個(gè)原因，因?yàn)榻刂沟侥壳盀橹沟挠?jì)算操作，其實(shí)還是基于幾百行到上千行的復(fù)雜SQL落地到MySQL從庫(kù)中去執(zhí)行計(jì)算的。

因此，在高峰期可能MySQL從庫(kù)所在數(shù)據(jù)庫(kù)服務(wù)器的CPU負(fù)載、IO負(fù)載都會(huì)非常的高，導(dǎo)致SQL執(zhí)行性能下降數(shù)倍，這個(gè)時(shí)候數(shù)據(jù)分片里的數(shù)據(jù)量又大，執(zhí)行的又慢，很容易就會(huì)導(dǎo)致某個(gè)計(jì)算任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)。

最后一個(gè)造成負(fù)載不均衡的原因，就是每個(gè)計(jì)算任務(wù)對(duì)應(yīng)一個(gè)數(shù)據(jù)分片和一個(gè)SQL，但是不同的SQL執(zhí)行效率不同，有的SQL可能只要200毫秒就可以結(jié)束，有的SQL要1秒，所以不同的SQL執(zhí)行效率不同，造成了不同的計(jì)算任務(wù)的執(zhí)行時(shí)間的不同。

因此，我們又專門在Master節(jié)點(diǎn)中加入了計(jì)算任務(wù)metrics上報(bào)、計(jì)算任務(wù)耗時(shí)預(yù)估、任務(wù)執(zhí)行狀態(tài)監(jiān)控、機(jī)器資源管理、彈性資源調(diào)度等機(jī)制。

實(shí)現(xiàn)的一個(gè)效果大致就是：

• Master節(jié)點(diǎn)會(huì)實(shí)時(shí)感知到各個(gè)機(jī)器的計(jì)算任務(wù)執(zhí)行情況、排隊(duì)負(fù)載壓力、資源使用等情況。
• 同時(shí)還會(huì)收集各個(gè)機(jī)器的計(jì)算任務(wù)的歷史metrics
• 接著會(huì)根據(jù)計(jì)算任務(wù)的歷史metrics、預(yù)估當(dāng)前計(jì)算任務(wù)的耗時(shí)、綜合考慮當(dāng)前各Slave機(jī)器的負(fù)載，來(lái)將任務(wù)分發(fā)給負(fù)載較低的Slave機(jī)器。

通過(guò)這套機(jī)制，我們充分保證了線上Slave集群資源的均衡利用，不會(huì)出現(xiàn)單臺(tái)機(jī)器負(fù)載過(guò)高，計(jì)算任務(wù)排隊(duì)時(shí)間過(guò)長(zhǎng)的情況，經(jīng)過(guò)生產(chǎn)環(huán)境的落地實(shí)踐以及一些優(yōu)化之后，該機(jī)制運(yùn)行良好。

五、分布式系統(tǒng)高容錯(cuò)機(jī)制

其實(shí)一旦將系統(tǒng)重構(gòu)為分布式系統(tǒng)架構(gòu)之后，就可能會(huì)出現(xiàn)各種各樣的問(wèn)題，此時(shí)就需要開發(fā)一整套的容錯(cuò)機(jī)制。

大體說(shuō)起來(lái)的話，這套系統(tǒng)目前在線上生產(chǎn)環(huán)境可能產(chǎn)生的問(wèn)題包括但不限于：

• 某個(gè)Slave節(jié)點(diǎn)在執(zhí)行過(guò)程中突然宕機(jī)
• 某個(gè)計(jì)算任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)
• 某個(gè)計(jì)算任務(wù)執(zhí)行失敗

因此，Master節(jié)點(diǎn)內(nèi)需要實(shí)現(xiàn)一套針對(duì)Slave節(jié)點(diǎn)計(jì)算任務(wù)調(diào)度的容錯(cuò)機(jī)制，大體思路如下：

1、Master節(jié)點(diǎn)會(huì)監(jiān)控各個(gè)計(jì)算任務(wù)的執(zhí)行狀態(tài)，同時(shí)也會(huì)監(jiān)控各個(gè)Slave節(jié)點(diǎn)的運(yùn)行狀態(tài)

2、如果說(shuō)某個(gè)Slave宕機(jī)了，那么此時(shí)Master就會(huì)將那個(gè)Slave沒(méi)執(zhí)行完的計(jì)算任務(wù)重新分配給其他的Slave節(jié)點(diǎn)

3、如果說(shuō)某個(gè)Slave的計(jì)算任務(wù)執(zhí)行失敗了，同時(shí)重試幾次之后還是失敗，那么Master會(huì)將這個(gè)計(jì)算任務(wù)重新分配給其他的Slave節(jié)點(diǎn)來(lái)執(zhí)行

4、如果說(shuō)某個(gè)計(jì)算任務(wù)在多個(gè)Slave中無(wú)法成功計(jì)算的話，此時(shí)會(huì)將這個(gè)計(jì)算任務(wù)儲(chǔ)存在一個(gè)延時(shí)內(nèi)存隊(duì)列中，間隔一段時(shí)間過(guò)后，比如說(shuō)等待高峰期故去，然后再重新嘗試執(zhí)行這個(gè)計(jì)算任務(wù)

5、如果某個(gè)計(jì)算任務(wù)等待很長(zhǎng)時(shí)間都沒(méi)成功執(zhí)行，可能是hang死了，那么Master節(jié)點(diǎn)會(huì)更新這個(gè)計(jì)算任務(wù)的版本號(hào)，然后分配計(jì)算任務(wù)給其他的Slave節(jié)點(diǎn)來(lái)執(zhí)行。

6、之所以要更新版本號(hào)，是為了避免說(shuō)，新分配的Slave執(zhí)行完畢寫入結(jié)果之后，之前的那個(gè)Slave hang死了一段時(shí)間恢復(fù)了，接著將計(jì)算結(jié)果寫入存儲(chǔ)覆蓋正確的結(jié)果。用版本號(hào)機(jī)制可以避免這種情況的發(fā)生。

六、階段性總結(jié)

系統(tǒng)架構(gòu)到這個(gè)程度為止，其實(shí)在當(dāng)時(shí)而言是運(yùn)行的相當(dāng)不錯(cuò)的，每日億級(jí)的請(qǐng)求以及數(shù)據(jù)場(chǎng)景下，這套系統(tǒng)架構(gòu)都能承載的很好，如果寫數(shù)據(jù)庫(kù)并發(fā)更高可以隨時(shí)加更多的主庫(kù)，如果讀并發(fā)過(guò)高可以隨時(shí)加更多的從庫(kù)，同時(shí)單表數(shù)據(jù)量過(guò)大了就分更多的表，Slave計(jì)算節(jié)點(diǎn)也可以隨時(shí)按需擴(kuò)容。

計(jì)算性能也是可以在這個(gè)請(qǐng)求量級(jí)和數(shù)據(jù)量級(jí)下保持很高的水準(zhǔn)，因?yàn)閿?shù)據(jù)分片計(jì)算引擎（滑動(dòng)窗口）可以保證計(jì)算性能在秒級(jí)完成。同時(shí)各個(gè)Slave計(jì)算節(jié)點(diǎn)的負(fù)載都可以通過(guò)彈性資源調(diào)度機(jī)制保持的非常的均衡。

另外整套分布式系統(tǒng)還實(shí)現(xiàn)了高可用以及高容錯(cuò)的機(jī)制，Master節(jié)點(diǎn)是Active-Standby架構(gòu)可以自動(dòng)故障轉(zhuǎn)移，Slave節(jié)點(diǎn)任何故障都會(huì)被Master節(jié)點(diǎn)感知到同時(shí)自動(dòng)重試計(jì)算任務(wù)。

七、下一個(gè)階段的展望

其實(shí)如果僅僅只是每天億級(jí)的流量請(qǐng)求過(guò)來(lái)，這套架構(gòu)是可以撐住了，但是問(wèn)題是，隨之接踵而來(lái)的，就是每天請(qǐng)求流量開始達(dá)到數(shù)十億次甚至百億級(jí)的請(qǐng)求量，此時(shí)上面那套架構(gòu)又開始支撐不住了，需要繼續(xù)重構(gòu)和演進(jìn)系統(tǒng)架構(gòu)。