【面試必問】支撐百萬併發的"IO多路複用"技術你瞭解嗎？

多路複用其實並非什麼新技術，它的做用是在一個通信鏈接的基礎上能夠同時進行多個請求響應處理。對於網絡通信來其實不存在這一說法，由於網絡層面只負責數據傳輸；因爲上層應用協議的制訂問題，致使了不少傳統服務並不能支持多路複用；如：http1.1,sqlserver和redis等等，雖然有些服務提供批量處理，但這些處理都基於一個RPS（每秒請求數）下。下面經過圖解來了解釋單路和多路複用的區別。

 

1、單路存在的問題

每一個請求響應獨佔一個鏈接，並獨佔鏈接網絡讀寫；這樣致使鏈接在有大量時間被閒置沒法更好地利用網絡資源。因爲是獨佔讀寫IO，這樣致使RPS處理量由必須由IO承擔,IO操做起來比較損耗性能，這樣在高RPS處理就出現性能問題。因爲不能有效的合併IO也會致使在通信中的帶寬存在浪費狀況，特別對於比較小的請求數據包。通信上的延時當要持大量的RPS那就必需要有更多鏈接支撐，鏈接數增長也對資源的開銷有所增長。

2、多路複用的優勢

多路複用能夠在一個鏈接上同時處理多個請求響應，這樣能夠大大的減小鏈接的數量，並提升了網絡的處理能力。因爲是共享鏈接不一樣請求響應數據包能夠合併到一個IO上處理，這樣能夠大大下降IO的處理量，讓性能表現得更出色。

3、經過多路複用實現百萬級RPS

多路複用是否是真的如此出色呢，如下在.net core上使用多路複用實現單服務百萬RPS吞吐，並能達到比較低的延時性。如下是測試流程：

 

因爲基礎通信不具有消息包合併功能，因此在BeetleX的基礎上作集成測試，主要BeetleX會自動合併消息到一個Buffer上，從而下降IO的讀寫。

4、測試消息結構

本測試使用了Protobuf做爲基礎交互消息，畢竟Protobuf已是一個二進制序列化標準了。

4.一、請求消息

 

4.二、響應消息

 

4.三、服務端處理代碼

 

4.四、服務響應對象內容

 

接收消息後放入隊列，而後由隊列處理響應，設置請求相應請求時間並記錄總處理消息計數。

4.五、客戶端請求代碼

 

4.六、客戶端測試發起代碼

 

整個測試開啓了10個鏈接，在這10個鏈接的基礎上進行請求響應複用。

5、測試配置

測試環境是兩臺服務器，配置是阿里雲上的12核服務器(對應的物理機應該是6核12線程)

服務和客戶端的系統都是:Ubuntu 16.04

Dotnet core版本是:2.14

6、測試結果

6.一、客戶端統計結果

 

6.二、服務端統計信息

 

6.三、帶寬統計

 

測試使用了10個鏈接進行多路複用，每秒接收響應量在100W，大部分響應延時在1-3毫秒之間；

6.四、測試代碼

https://github.com/IKende/BeetleX/blob/master/samples/MultiplexingConnectionTest.zip