【生產實踐總結】支撐百萬鏈接的系統應該如何設計其高併發架構？【石杉的架構筆記】

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

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

精品學習資料獲取通道，參見文末

目錄

一、到底什麼是鏈接？

二、爲何每次發送請求都要創建鏈接？

三、長鏈接模式下須要耗費大量資源

四、Kafka遇到的問題：應對大量客戶端鏈接

五、Kafka的架構實踐：Reactor多路複用

六、優化後的架構是如何支撐大量鏈接的

「 這篇文章，給你們聊聊：若是你設計一個系統須要支撐百萬用戶鏈接，應該如何來設計其高併發請求處理架構？

（1）到底什麼是鏈接？

假如說如今你有一個系統，他須要鏈接不少不少的硬件設備，這些硬件設備都要跟你的系統來通訊。

那麼，怎麼跟你的系統通訊呢？

首先，他必定會跟你的系統創建鏈接，而後會基於那個鏈接發送請求給你的系統。

接着你的系統會返回響應給那個系統，最後是你們一塊兒把鏈接給斷開，釋放掉網絡資源。

因此咱們來看一下下面的那個圖，感覺一下這個所謂的鏈接究竟是個什麼概念。

（2）爲何每次發送請求都要創建鏈接？

可是你們看着上面的那個圖，是否是感受有一個很大的問題。

什麼問題呢？那就是爲啥每次發送請求，都必需要創建一個鏈接，而後再斷開一個鏈接？

要知道，網絡鏈接的創建和鏈接涉及到屢次網絡通訊，本質是一個比較耗費資源的過程。

因此說我們徹底不必每次發送請求都要創建一次鏈接，斷開一次鏈接。

咱們徹底能夠創建好一個鏈接，而後設備就不停的發送請求過來，系統就經過那個鏈接返回響應。

你們徹底能夠屢次經過一個鏈接發送請求和返回響應，這就是所謂的長鏈接。

也就是說，若是你一個鏈接創建以後，而後發送請求，接着就斷開，那這個鏈接維持的時間是很短的，這個就是所謂的短鏈接。

那若是一個設備跟你的系統創建好一個鏈接，而後接着就不停的經過這個鏈接發送請求接收響應，就能夠避免不停的建立鏈接和斷開鏈接的開銷了。

你們看下面的圖，體驗一下這個過程。在圖裏面，兩次鏈接之間，有不少次發送請求和接收響應的過程，這樣就能夠利用一個鏈接可是進行屢次通訊了。

（3）長鏈接模式下須要耗費大量線程資源

可是如今問題又來了，長鏈接的模式確實是不錯的，可是若是說每一個設備都要跟系統長期維持一個鏈接，那麼對於系統來講就須要搞一個線程，這個線程須要去維護一個設備的長鏈接，而後經過這個鏈接跟一個設備不停的通訊，接收人家發送過來的請求，返回響應給人家。

你們看下面的圖，每一個設備都要跟系統維持一個鏈接，那麼對於每一個設備的鏈接，系統都會有一個獨立的線程來維護這個鏈接。

由於你必需要有一個線程不停的嘗試從網絡鏈接中讀取請求，接着要處理請求，最後還要返回響應給設備。

那麼這種模式有什麼缺點呢？

缺點是很顯而易見的，假如說此時你有上百萬個設備要跟你的系統進行鏈接，假設你的系統作了集羣部署一共有100個服務實例，難道每一個服務實例要維持1萬個鏈接支撐跟1萬個設備的通訊？

若是這樣的話，每一個服務實例不就是要維持1萬個線程來維持1萬個鏈接了嗎？你們以爲這個事兒靠譜嗎？

根據線上的生產經驗，通常4核8G的標準服務用的虛擬機，本身開闢的工做線程在一兩百個就會讓CPU負載很高了，最佳的建議就是在幾十個工做線程就差很少。

因此要是指望每一個服務實例來維持上萬個線程，那幾乎是不可能的，因此這種模式最大的問題就在於這裏，無法支撐大量鏈接。

（4）Kafka遇到的問題：應對大量客戶端鏈接

實際上，對於大名鼎鼎的消息系統Kafka來講，他也是會面對一樣的問題，由於他須要應對大量的客戶端鏈接。

有不少生產者和消費者都要跟Kafka創建相似上面的長鏈接，而後基於一個鏈接，一直不停的通訊。

舉個例子，好比生產者須要經過一個鏈接，不停的發送數據給Kafka。而後Kafka也要經過這個鏈接不停的返回響應給生產者。

消費者也須要經過一個鏈接不停的從Kafka獲取數據，Kafka須要經過這個鏈接不停的返回數據給消費者。

你們看下面的圖，感覺一下Kafka的生產現場。

那假如Kafka就簡單的按照這個架構來處理，若是你的公司裏有幾萬幾十萬個的生產者或者消費者的服務實例，難道Kafka集羣就要爲了幾萬幾十萬個鏈接來維護這麼多的線程嗎？

一樣，這是不現實的，由於線程是昂貴的資源，不可能在集羣裏使用那麼多的線程。

（5）Kafka的架構實踐：Reactor多路複用

針對這個問題，大名鼎鼎的Kafka採用的架構策略是Reactor多路複用模型。

簡單來講，就是搞一個acceptor線程，基於底層操做系統的支持，實現鏈接請求監聽。

若是有某個設備發送了創建鏈接的請求過來，那麼那個線程就把這個創建好的鏈接交給processor線程。

每一個processor線程會被分配N多個鏈接，一個線程就能夠負責維持N多個鏈接，他一樣會基於底層操做系統的支持監聽N多鏈接的請求。

若是某個鏈接發送了請求過來，那麼這個processor線程就會把請求放到一個請求隊列裏去。

接着後臺有一個線程池，這個線程池裏有工做線程，會從請求隊列裏獲取請求，處理請求，接着將請求對應的響應放到每一個processor線程對應的一個響應隊列裏去。

最後，processor線程會把本身的響應隊列裏的響應發送回給客戶端。

說了這麼多，仍是來一張圖，你們看下面的圖，就能夠理解上述整個過程了。

（6）優化後的架構是如何支撐大量鏈接的？

那麼上面優化後的那套架構，是如何支撐大量鏈接的呢？

其實很簡單。這裏最關鍵的一個因素，就是processor線程是一我的維持N個線程，基於底層操做系統的特殊機制的支持，一我的能夠監聽N個鏈接的請求。

這是極爲關鍵的一個步驟，就僅此一個步驟就可讓一個線程支持多個鏈接了，不須要一個鏈接一個線程來支持。

並且那個processor線程僅僅是接收請求和發送響應，全部的請求都會入隊列排隊，交給後臺線程池來處理。

好比說按照100萬鏈接來計算，若是有100臺機器來處理，按照老的模式，每臺機器須要維持1萬個線程來處理1萬個鏈接。

可是若是按照這種多路複用的模式，可能就好比10個processor + 40個線程的線程池，一共50個線程就能夠上萬鏈接。

在這種模式下，每臺機器有限的線程數量能夠抗住大量的鏈接。

所以實際上咱們在設計這種支撐大量鏈接的系統的時候，徹底能夠參考這種架構，設計成多路複用的模式，用幾十個線程處理成千上萬個鏈接，最終實現百萬鏈接的處理架構。

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進階面試系列之五】消息中間件集羣崩潰，如何保證百萬生產數據不丟失？

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

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

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

3六、億級流量架構第二彈：你的系統真的無懈可擊嗎？

3七、億級流量系統架構之如何保證百億流量下的數據一致性（上）

3八、億級流量系統架構之如何保證百億流量下的數據一致性（中）？

3九、億級流量系統架構之如何保證百億流量下的數據一致性（下）？

40、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（1）

4一、互聯網面試必殺：如何保證消息中間件全鏈路數據100%不丟失（2）

4二、面試大殺器：消息中間件如何實現消費吞吐量的百倍優化？

4三、高併發場景下，如何保證生產者投遞到消息中間件的消息不丟失？

4四、兄弟，用大白話給你講小白都能看懂的分佈式系統容錯架構

4五、從團隊自研的百萬併發中間件系統的內核設計看Java併發性能優化

4六、【非廣告，純乾貨】英語差的程序員如何才能無障礙閱讀官方文檔？

4七、若是20萬用戶同時訪問一個熱點緩存，如何優化你的緩存架構？

4八、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？

4九、拜託，面試請不要再問我分佈式搜索引擎的架構原理！

50、【金三銀四跳槽季】Java工程師如何在1個月內作好面試準備？

5一、【offer收割機必備】我簡歷上的Java項目都好low，怎麼辦？

5二、【offer去哪了】我一連面試了十個Java崗，通通石沉大海！

5三、高階Java開發必備：分佈式系統的惟一id生成算法你瞭解嗎？

5四、支撐日活百萬用戶的高併發系統，應該如何設計其數據庫架構？

5五、尷尬了！Spring Cloud微服務註冊中心Eureka 2.x中止維護了咋辦？

5六、【Java高階必備】如何優化Spring Cloud微服務註冊中心架構？

5七、面試官：消息中間件如何實現每秒幾十萬的高併發寫入？

5八、【非廣告，純乾貨】三四十歲的大齡程序員，應該如何保持本身的職場競爭力？

做者：石杉的架構筆記 連接：https://juejin.im/post/5c6a9f25518825787e69e70a 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。