億級流量系統架構之如何在上萬併發場景下設計可擴展架構（上）？【石杉的架構筆記】

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

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

1、寫在前面

以前更新過一個「億級流量系統架構」系列，主要講述了一個大規模商家數據平臺的以下幾個方面：

• 如何承載百億級數據存儲
• 如何設計高容錯的分佈式架構
• 如何設計承載百億流量的高性能架構
• 如何設計每秒數十萬併發查詢的高併發架構
• 如何設計全鏈路99.99%高可用架構。

接下來，咱們將會繼續經過幾篇文章，對這套系統的可擴展架構、數據一致性保障等方面進行探討。

若是沒看過本系列文章的同窗能夠先回過頭看看以前寫的幾篇文章：

億級流量系統架構

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

2、背景回顧

若是你們看過以前的一系列文章，應該依稀還記得上一篇文章最後，整個系統架構大體演進到了以下圖的一個狀態。

若是沒看過以前的系列文章，上來猛一看下面這個圖，絕對一臉懵逼，就看到一片「花花綠綠」。這個也沒辦法，複雜的系統架構都是特別的龐雜的。

3、實時計算平臺與數據查詢平臺之間的耦合

好，我們正式開始！這篇文章我們來聊聊這套系統裏的不一樣子系統之間通訊過程的一個可擴展性的架構處理。

這裏面蘊含了線上複雜系統之間交互的真實場景和痛點，相信對你們可以有所啓發。

咱們就關注一下上面的架構圖裏左側的部分，處於中間位置的那個實時計算平臺在完成了每個數據分片的計算事後，都會將計算結果寫入到最左側的數據查詢平臺中。

出於種種考量，由於計算結果的數據量相比於原始數據的數據量，實際上已經少了一個數量級了。

因此，咱們選擇的是實時計算平臺直接將數據寫入到數據查詢平臺的MySQL數據庫集羣中，而後數據查詢平臺基於MySQL數據庫集羣來對外提供查詢請求。

此外，爲了保證當天的實時計算結果可以高併發的被用戶查詢，所以當時採起的是實時計算平臺的計算結果同時雙寫緩存集羣和數據庫集羣。

這樣，數據查詢平臺能夠優先走緩存集羣，若是找不到緩存纔會從數據庫集羣裏回查數據。

因此上述就是實時計算平臺與數據查詢平臺之間在某一個時期的一個典型的系統耦合架構。

兩個不一樣的系統之間，經過同一套數據存儲（數據庫集羣+緩存集羣）進行了耦合。

你們看看下面的圖，再來清晰的感覺一下系統之間耦合的感受。

系統耦合痛點1：被動承擔的高併發寫入壓力

你們若是仔細看過以前的系列文章，大概就該知道，在早期主要是集中精力對實時計算平臺的架構作了大量的演進，以便於讓他能夠支撐超高併發寫入、海量數據的超高性能計算，最後就能夠抗住每秒數萬甚至數十萬的數據涌入的存儲和計算。

可是由於早期採用了上圖的這種最簡單、最高效、最實用的耦合交互方式，實時計算平臺直接把每一個數據分片計算完的結果寫入共享存儲中，就致使了一個很大的問題。

實時計算平臺能抗住超高併發寫入沒問題了，並且還能快速的高性能計算也沒問題。

可是，他同時會隨着數據量的增加，愈來愈高併發的將計算結果寫入到一個數據庫集羣中。而這個數據庫集羣在團隊劃分的時候，其實是交給數據查詢平臺團隊來負責維護的。

也就是說，對實時計算平臺團隊來講，他們是不care那個數據庫集羣是什麼狀態的，而就是不停的把數據寫入到那個集羣裏去。

可是，對於數據查詢平臺團隊來講，他們就會被動的承擔實時計算平臺愈來愈高併發壓力寫入的數據。

這個時候數據查詢平臺團隊的同窗極可能處於這樣的一種焦躁中：原本本身這塊系統也有不少架構上的改進點要作，好比說以前提到的冷數據查詢引擎的自研。

可是呢，他們卻要不停的被線上數據庫服務器的報警搞的焦頭爛額，疲於奔命。

由於數據庫服務器單機寫入壓力可能隨着業務增加，迅速變成每秒5000~6000的寫入壓力，天天到了高峯期，線上服務器的CPU、磁盤、IO、網絡等壓力巨大，報警頻繁。

此時數據查詢平臺團隊的架構演進節奏就會被打亂，由於必須被動的去根據實時計算平臺的寫入壓力來進行調整，必須立馬停下手中的工做，而後去考慮如何對數據庫集羣作分庫分表的方案，如何對錶進行擴容，如何對庫進行擴容。

同時結合分庫分表的方案，數據查詢平臺自身的查詢機制又要跟着一塊兒改變，大量的改造工做，調研工做，數據遷移工做，上線部署工做，代碼改造工做。

實際上，上面說的這種狀況，絕對是不合理的。

由於整個這套數據平臺是一個大互聯網公司裏核心業務部門的一個核心繫統，他是數十個Java工程師與大數據工程師通力合做一塊兒開發，並且裏面劃分爲了多個team。

好比說數據接入系統是一個團隊負責，實時計算平臺是一個團隊負責，數據查詢平臺是一個團隊負責，離線數據倉庫是一個團隊負責，等等。

因此只要分工合做了之後，那麼就不該該讓一個團隊被動的去承擔另一個團隊猛然增加的寫入壓力，這樣會打破每一個團隊本身的工做節奏。

致使這個問題的根本緣由，就是由於兩個系統間，沒有作任何解耦的處理。

這就致使數據查詢平臺團隊根本沒法對實時計算平臺涌入過來的數據作任何有效的控制和管理，這也致使了「被動承擔高併發寫入壓力」問題的發生。

這種系統耦合致使的被動高併發寫入壓力還不僅是上面那麼簡單，實際在上述場景中，線上生產環境還發生過各類奇葩的事情：

某一次線上忽然產生大量的熱數據，熱數據計算結果涌入數據查詢平臺，由於沒作任何管控，幾乎一瞬間致使某臺數據庫服務器寫入併發達到1萬+，DBA焦急的擔憂數據庫快宕機了，全部人也都被搞的焦頭爛額，心理崩潰。

系統耦合痛點2：數據庫運維操做致使的線上系統性能劇烈抖動

在這種系統耦合的場景下，反過來實時計算平臺團隊的同窗其實內心也會吶喊：咱們內心也苦啊！

由於反過來你們能夠思考一下，線上數據庫中的表結構改變，那幾乎能夠說是再正常不過了，尤爲是高速迭代發展中的業務。

需求評審會上，要是不當心碰上某個產品經理，今天改需求，明天改需求。工程師估計會怒火沖天的想要砍人。可是沒辦法，最後仍是得爲五斗米折腰，該改的需求仍是得改。該改的表結構也仍是要改，改加的索引也仍是要加。

可是你們考慮一個點，若是說對上述這種強耦合的系統架構，單表基本都是在千萬級別的數據量，同時還有單臺數據庫服務器每秒幾千的寫入壓力。

在這種場景下，在線上走一個MySQL的DDL語句試一試？奉勸你們千萬別胡亂嘗試，由於數據查詢團隊裏的年輕同窗，幹過這個事兒。

實際的結果就是，DDL咔嚓一執行，對線上表結構進行修改，直接致使實時計算平臺的寫入數據庫的性能急劇降低10倍以上。。。

而後連帶致使實時計算平臺的數據分片計算任務大量的延遲。再而後，由於實時計算以後的數據沒法儘快反饋到存儲中，沒法被用戶查詢到，致使了大量的線上投訴。

而且，DDL語句執行的還特別的慢，耗時數十分鐘才執行完畢，這就致使數十分鐘裏，整套系統出現了大規模的計算延遲，數據延遲。

一直到數十分鐘以後DDL語句執行完畢，實時計算平臺才經過自身的自動延遲調度恢復機制慢慢恢復了正常的計算。

orz......因而今後以後，數據查詢平臺的攻城獅，必須得當心翼翼的在天天凌晨2點~3點之間進行相關的數據庫運維操做，避免影響線上系統的性能穩定性。

可是，難道人家年輕工程師沒有女友？難道年長工程師沒有老婆孩子？常常在凌晨3點看看窗外的風景，而後打個滴滴回家，估計沒任何人願意。

其實上述問題，說白了，仍是由於兩套系統直接經過存儲耦合在了一塊兒，致使了任何一個系統只要有點異動，直接就會影響另一個系統。耦合！耦合！仍是耦合！

系統耦合痛點N。。。

其實上面只不過是挑了其中兩個系統耦合痛點來講明而已，文章篇幅有限，很難把上述長達數月的耦合狀態下的各類痛點一一說明，實際線上生產環境的痛點還包括不限於：

• 實時計算平臺自身寫入機制有bug致使的數據丟失，結果讓數據查詢平臺的同窗去排查；

• 實時計算平臺對緩存集羣和數據庫集羣進行雙寫的時候，雙寫一致性的保證機制，竟然還須要本身來實現，直接致使本身的代碼裏混合了大量不屬於本身的業務邏輯；

• 數據查詢平臺有時候作了分庫分表運維操做以後，好比擴容庫和表，竟然還得讓實時計算平臺的同窗配合着一塊兒修改代碼配置，一塊兒測試和部署上線

• 數據查詢平臺和實時計算平臺兩個team的同窗在上述大量耦合場景下，常常每天一塊兒加班到凌晨深夜，各自的女友都覺得他們打算在一塊兒了，但實際狀況是一堆大老爺兒們每天被搞的焦頭爛額，苦不堪言，都不肯意多看對方一眼

• 由於系統耦合致使的各類問題，兩個team都要抽時間精力來解決，影響了本身那套系統的架構演進進度，無法集中人力和時間作真正有價值和意義的事情

4、下集預告

下一篇文章，咱們就來聊一聊針對這些痛點，如何靈活的運用MQ消息中間件技術來進行復雜系統之間的解耦，同時解耦事後如何來自行對流量數據進行管控，解決各類系統耦合的問題。

敬請期待：

• 億級流量系統架構之如何在上萬併發場景下設計可擴展架構（中）？
• 億級流量系統架構之如何在上萬併發場景下設計可擴展架構（下）？

END

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

一大波微服務、分佈式、高併發、高可用的原創系列文章正在路上

歡迎掃描下方二維碼，持續關注：

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

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

推薦閱讀：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1五、億級流量系統架構之如何設計每秒十萬查詢的高併發架構

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

1七、七張圖完全講清楚ZooKeeper分佈式鎖的實現原理

1八、大白話聊聊Java併發面試問題之volatile究竟是什麼？

1九、大白話聊聊Java併發面試問題之Java 8如何優化CAS性能？

20、大白話聊聊Java併發面試問題之談談你對AQS的理解？

2一、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？

2二、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化

2三、互聯網公司的面試官是如何360°無死角考察候選人的？（上篇）

2四、互聯網公司面試官是如何360°無死角考察候選人的？（下篇）

2五、Java進階面試系列之一：哥們，大家的系統架構中爲何要引入消息中間件？

2六、【Java進階面試系列之二】：哥們，那你說說系統架構引入消息中間件有什麼缺點？

2七、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷

2八、【Java進階面試系列之三】哥們，消息中間件在大家項目裏是如何落地的？

2九、【Java進階面試系列之四】扎心！線上服務宕機時，如何保證數據100%不丟失？

30、一次JVM FullGC的背後，竟隱藏着驚心動魄的線上生產事故！

3一、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？

3二、【Java進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c1e51fd6fb9a049a81f4f35 來源：掘金 著做權歸做者全部，轉載請聯繫做者得到受權