億級流量系統架構之如何設計高容錯分佈式計算系統【石杉的架構筆記】

歡迎關注我的公衆號：石杉的架構筆記（ID:shishan100）

週一至週五早8點半！精品技術文章準時送上！

億級流量架構專欄：

• 億級流量系統架構之如何支撐百億級數據的存儲與計算
• 億級流量系統架構之如何設計高容錯分佈式計算系統
• 億級流量系統架構之如何設計承載百億流量的高性能架構【敬請期待】
• 億級流量系統架構之如何設計每秒數十萬查詢的高併發架構【敬請期待】
• 億級流量系統架構之如何設計全鏈路99.99%高可用架構【敬請期待】

1、寫在前面

上篇文章《大型系統架構演進之如何支撐百億級數據的存儲與計算》，聊了一下商家數據平臺第一個階段的架構演進。經過離線與實時計算鏈路的拆分，離線計算的增量計算優化，實時計算的滑動時間窗口計算引擎，分庫分表 + 讀寫分離，等各類技術手段，支撐住了百億量級的數據量的存儲與計算。

咱們先來回看一下當時的那個架構圖，而後繼續聊聊這套架構在面對高併發、高可用、高性能等各類技術挑戰下，應該如何繼續演進。

2、active-standby高可用架構

你們看看上面的那個架構圖，有沒有發現裏面有一個比較致命的問題？就是如何避免系統單點故障！

在最初的部署架構下，由於數據平臺系統對CPU、內存、磁盤的要求很高，因此咱們是單機部署在一臺較高配置的虛擬機上的，16核CPU、64G內存、SSD固態硬盤。這個機器的配置是能夠保證數據平臺系統在高負載之下正常運行的。

可是若是僅僅是單機部署數據平臺系統的話，會致使致命的單點故障問題，也就是若是單臺機器上部署的數據平臺系統宕機的話，就會立馬致使整套系統崩潰。

所以在初期的階段，咱們對數據平臺實現了active-standby的高可用架構，也就是一共部署在兩臺機器上，可是同一時間只有一臺機器是會運行的，可是另一臺機器是備用的。處於active狀態的系統會將滑動窗口計算引擎的計算狀態和結果寫入zookeeper中，做爲元數據存儲起來。

關於元數據基於zookeeper來存儲，咱們是充分參考了開源的Storm流式計算引擎的架構實現，由於Storm做爲一個很是優秀的分佈式流式計算系統，一樣須要高併發的讀寫大量的計算中間狀態和數據，他就是基於zookeeper來進行存儲的。

自己zookeeper的讀寫性能很是的高，並且zookeeper集羣自身就能夠作到很是高的可用性，同時還提供了大量的分佈式系統須要的功能支持，包括分佈式鎖、分佈式協調、master選舉、主備切換等等。

所以基於zookeeper咱們實現了active-standby的主備自動切換，若是active節點宕機，那麼standby節點感知到，會自動切花爲active，同時自動讀取他們共享的一個計算引擎的中間狀態，而後繼續恢復以前的計算。

你們看下面的圖，一塊兒感覺一下。

在完成上述的active-standby架構以後，確定是消除掉了系統的單點故障了，保證了基本的可用性。並且在實際的線上生產環境中表現還不錯，一年系統總有個幾回會出現故障，可是每次都能自動切換standby機器穩定運行。

這裏隨便給你們舉幾個生產環境機器故障的例子，由於部署在公司的雲環境中，用的都是虛擬機，可能遇到的坑爹故障包括但不限於下面幾種狀況：

• 虛擬機所在的宿主機掛了
• 虛擬機的網絡出現故障
• 負載太高致使磁盤壞了

因此在線上高負載環境中，永遠別寄但願於機器永遠不宕機，你要隨時作好準備，機器會掛！系統必須作好充分的故障預測、高可用架構以及故障演練，保證各類場景下均可以繼續運行。

3、Master-Slave架構的分佈式計算系統

可是此時另一個問題又來了，你們考慮一個問題，數據平臺系統其實最核心的任務就是對一個一個的時間窗口中的數據進行計算，可是隨着天天的日增數據量愈來愈多，每一個時間窗口內的數據量也會愈來愈大，同時會致使數據平臺系統的計算負載愈來愈高。

在線上生產環境表現出來的狀況就是，數據平臺系統部署機器的CPU負載愈來愈高，高峯期很容易會100%，機器壓力較大。新一輪的系統重構，勢在必行。

首先咱們將數據平臺系統完全重構和設計爲一套分佈式的計算系統，將任務調度與任務計算兩個職責進行分離，有一個專門的Master節點負責讀取切分好的數據分片（也就是所謂的時間窗口，一個窗口就是一個數據分片），而後將各個數據分片的計算任務分發給多個Slave節點。

Slave節點的任務就是專門接收一個一個的計算任務，每一個計算任務就是對一個數據分片執行一個幾百行到上千行的複雜SQL語句來產出對應的數據分析結果。

同時對Master節點，咱們爲了不其出現單點故障，因此仍是沿用了以前的Active-Standby架構，Master節點是在線上部署一主一備的，平時都是active節點運做，一旦宕機，standby節點會切換爲active節點，而後自動調度運行各個計算任務。

這套架構部署上線以後，效果仍是很不錯的，由於Master節點其實就是讀取數據分片，而後爲每一個數據分片構造計算任務，接着就是將計算任務分發給各個Slave節點進行計算。

Master節點幾乎沒有太多複雜的任務，部署一臺高配置的機器就絕對沒問題。

負載主要在Slave節點，而Slave節點由於部署了多臺機器，每臺機器就是執行部分計算任務，因此很大程度上下降了單臺Slave節點的負載，並且只要有須要，隨時能夠對Slave集羣進行擴容部署更多的機器，這樣不管計算任務有多繁忙，均可以不斷的擴容，保證單臺Slave機器的負載不會太高。

4、彈性計算資源調度機制

在解決了單臺機器計算負載壓力太高的問題以後，咱們又遇到了下一個問題，就是在線上生產環境中偶爾會發現某個計算任務耗時過長，致使某臺Slave機器積壓了大量的計算任務一直遲遲得不處處理。

這個問題的產生，其實主要是因爲系統的高峯和低谷的數據差別致使的。

你們能夠想一想，在高峯期，瞬時涌入的數據量很大，極可能某個數據分片包含的數據量過大，達到普通數據分片的幾倍甚至幾十倍，這是緣由之一。

還有一個緣由，由於截止到目前爲止的計算操做，其實仍是基於幾百行到上千行的複雜SQL落地到MySQL從庫中去執行計算的。

所以，在高峯期可能MySQL從庫所在數據庫服務器的CPU負載、IO負載都會很是的高，致使SQL執行性能降低數倍，這個時候數據分片裏的數據量又大，執行的又慢，很容易就會致使某個計算任務執行時間過長。

最後一個形成負載不均衡的緣由，就是每一個計算任務對應一個數據分片和一個SQL，可是不一樣的SQL執行效率不一樣，有的SQL可能只要200毫秒就能夠結束，有的SQL要1秒，因此不一樣的SQL執行效率不一樣，形成了不一樣的計算任務的執行時間的不一樣。

所以，咱們又專門在Master節點中加入了計算任務metrics上報、計算任務耗時預估、任務執行狀態監控、機器資源管理、彈性資源調度等機制。

實現的一個效果大體就是：

• Master節點會實時感知到各個機器的計算任務執行狀況、排隊負載壓力、資源使用等狀況。
• 同時還會收集各個機器的計算任務的歷史metrics
• 接着會根據計算任務的歷史metrics、預估當前計算任務的耗時、綜合考慮當前各Slave機器的負載，來將任務分發給負載較低的Slave機器。

經過這套機制，咱們充分保證了線上Slave集羣資源的均衡利用，不會出現單臺機器負載太高，計算任務排隊時間過長的狀況，通過生產環境的落地實踐以及一些優化以後，該機制運行良好。

5、分佈式系統高容錯機制

其實一旦將系統重構爲分佈式系統架構以後，就可能會出現各類各樣的問題，此時就須要開發一整套的容錯機制。

大致提及來的話，這套系統目前在線上生產環境可能產生的問題包括但不限於：

• 某個Slave節點在執行過程當中忽然宕機
• 某個計算任務執行時間過長
• 某個計算任務執行失敗

所以，Master節點內須要實現一套針對Slave節點計算任務調度的容錯機制，大致思路以下：

1. Master節點會監控各個計算任務的執行狀態，同時也會監控各個Slave節點的運行狀態
2. 若是說某個Slave宕機了，那麼此時Master就會將那個Slave沒執行完的計算任務從新分配給其餘的Slave節點
3. 若是說某個Slave的計算任務執行失敗了，同時重試幾回以後仍是失敗，那麼Master會將這個計算任務從新分配給其餘的Slave節點來執行
4. 若是說某個計算任務在多個Slave中沒法成功計算的話，此時會將這個計算任務儲存在一個延時內存隊列中，間隔一段時間事後，好比說等待高峯期故去，而後再從新嘗試執行這個計算任務
5. 若是某個計算任務等待很長時間都沒成功執行，多是hang死了，那麼Master節點會更新這個計算任務的版本號，而後分配計算任務給其餘的Slave節點來執行。
6. 之因此要更新版本號，是爲了不說，新分配的Slave執行完畢寫入結果以後，以前的那個Slave hang死了一段時間恢復了，接着將計算結果寫入存儲覆蓋正確的結果。用版本號機制能夠避免這種狀況的發生。

6、階段性總結

系統架構到這個程度爲止，其實在當時而言是運行的至關不錯的，每日億級的請求以及數據場景下，這套系統架構都能承載的很好，若是寫數據庫併發更高能夠隨時加更多的主庫，若是讀併發太高能夠隨時加更多的從庫，同時單表數據量過大了就分更多的表，Slave計算節點也能夠隨時按需擴容。

計算性能也是能夠在這個請求量級和數據量級下保持很高的水準，由於數據分片計算引擎（滑動窗口）能夠保證計算性能在秒級完成。同時各個Slave計算節點的負載均可以經過彈性資源調度機制保持的很是的均衡。

另外整套分佈式系統還實現了高可用以及高容錯的機制，Master節點是Active-Standby架構能夠自動故障轉移，Slave節點任何故障都會被Master節點感知到同時自動重試計算任務。

7、下一個階段的展望

其實若是僅僅只是天天億級的流量請求過來，這套架構是能夠撐住了，可是問題是，隨之接踵而來的，就是天天請求流量開始達到數十億次甚至百億級的請求量，此時上面那套架構又開始支撐不住了，須要繼續重構和演進系統架構。

END

下一篇文章，會給你們聊聊：《億級流量系統架構之如何設計承載百億流量的高性能架構》，敬請期待。

敬請期待：

《億級流量系統架構之如何設計高容錯分佈式計算系統》

《億級流量系統架構之如何設計承載百億流量的高性能架構》

《億級流量系統架構之如何設計每秒數十萬查詢的高併發架構》

《億級流量系統架構之如何設計全鏈路99.99%高可用架構》

若有收穫，請幫忙轉發，您的鼓勵是做者最大的動力，謝謝！

一大波微服務、分佈式、高併發、高可用的原創系列

文章正在路上,歡迎掃描下方二維碼，持續關注：

石杉的架構筆記（id:shishan100）

十餘年BAT架構經驗傾囊相授

推薦閱讀：

一、拜託！面試請不要再問我Spring Cloud底層原理

二、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？

三、【性能優化之道】每秒上萬併發下的Spring Cloud參數優化實戰

四、微服務架構如何保障雙11狂歡下的99.99%高可用

五、兄弟，用大白話告訴你小白都能聽懂的Hadoop架構原理

六、大規模集羣下Hadoop NameNode如何承載每秒上千次的高併發訪問

七、【性能優化的祕密】Hadoop如何將TB級大文件的上傳性能優化上百倍

八、拜託，面試請不要再問我TCC分佈式事務的實現原理坑爹呀！

九、【坑爹呀！】最終一致性分佈式事務如何保障實際生產中99.99%高可用？

十、拜託，面試請不要再問我Redis分佈式鎖的實現原理！

十一、【眼前一亮！】看Hadoop底層算法如何優雅的將大規模集羣性能提高10倍以上？

十二、億級流量系統架構之如何支撐百億級數據的存儲與計算