歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
精品學習資料獲取通道，參見文末
目錄
1、到底什麼是連線？
2、為什麼每次傳送請求都要建立連線？
3、長連線模式下需要耗費大量資源
4、Kafka遇到的問題：應對大量客戶端連線
5、Kafka的架構實踐：Reactor多路複用
6、優化後的架構是如何支撐大量連線的
“ 這篇文章，給大家聊聊：如果你設計一個系統需要支撐百萬使用者連線，應該如何來設計其高併發請求處理架構？
（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架構經驗傾囊相授
推薦閱讀：
2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務當機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
37、億級流量系統架構之如何保證百億流量下的資料一致性（上）
38、億級流量系統架構之如何保證百億流量下的資料一致性（中）？
39、億級流量系統架構之如何保證百億流量下的資料一致性（下）？
40、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（1）
41、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（2）
42、面試大殺器：訊息中介軟體如何實現消費吞吐量的百倍優化？
43、高併發場景下，如何保證生產者投遞到訊息中介軟體的訊息不丟失？
45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化
46、【非廣告，純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件？
47、如果20萬使用者同時訪問一個熱點快取，如何優化你的快取架構？
48、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？
50、【金三銀四跳槽季】Java工程師如何在1個月內做好面試準備？
51、【offer收割機必備】我簡歷上的Java專案都好low，怎麼辦？
52、【offer去哪了】我一連面試了十個Java崗，統統石沉大海！
53、高階Java開發必備：分散式系統的唯一id生成演算法你瞭解嗎？
54、支撐日活百萬使用者的高併發系統，應該如何設計其資料庫架構？
55、尷尬了！Spring Cloud微服務註冊中心Eureka 2.x停止維護了咋辦？
作者：石杉的架構筆記
連結：https://juejin.im/post/5c6a9f25518825787e69e70a
來源：掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。