【生產實踐總結】支撐百萬連線的系統應該如何設計其高併發架構？【石杉的架構筆記】
歡迎關注個人公眾號：石杉的架構筆記（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
（封面,圖源網路，侵權刪除）