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

一、單路存在的問題

每個請求響應獨佔一個連線，並獨佔連線網路讀寫；這樣導致連線在有大量時間被閒置無法更好地利用網路資源。由於是獨佔讀寫IO，這樣導致RPS處理量由必須由IO承擔,IO操作起來比較損耗效能，這樣在高RPS處理就出現效能問題。由於不能有效的合併IO也會導致在通訊中的頻寬存在浪費情況，特別對於比較小的請求資料包。通訊上的延時當要持大量的RPS那就必須要有更多連線支撐，連線數增加也對資源的開銷有所增加。

二、多路複用的優點

多路複用可以在一個連線上同時處理多個請求響應，這樣可以大大的減少連線的數量，並提高了網路的處理能力。由於是共享連線不同請求響應資料包可以合併到一個IO上處理，這樣可以大大降低IO的處理量，讓效能表現得更出色。

三、通過多路複用實現百萬級RPS

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

由於基礎通訊不具備訊息包合併功能，所以在BeetleX的基礎上做整合測試，主要BeetleX會自動合併訊息到一個Buffer上，從而降低IO的讀寫。

四、測試訊息結構

本測試使用了Protobuf作為基礎互動訊息，畢竟Protobuf已經是一個二進位制序列化標準了。

4.1、請求訊息

4.2、響應訊息

4.3、服務端處理程式碼

4.4、服務響應物件內容

接收訊息後放入佇列，然後由佇列處理響應，設定請求相應請求時間並記錄總處理訊息計數。

4.5、客戶端請求程式碼

4.6、客戶端測試發起程式碼

整個測試開啟了10個連線，在這10個連線的基礎上進行請求響應複用。

五、測試配置

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

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

Dotnet core版本是:2.14

六、測試結果

6.1、客戶端統計結果

6.2、服務端統計資訊

6.3、頻寬統計

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

6.4、測試程式碼

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

歡迎工作一到五年的Java工程師朋友們加入Java填坑之路：860113481

群內提供免費的Java架構學習資料（裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！