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

單路存在的問題

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

多路復用的優點

多路復用可以在一個連接上同時處理多個請求響應，這樣可以大大的減少連接的數量，并提高了網絡的處理能力。由于是共享連接不同請求響應數據包可以合并到一個IO上處理，這樣可以大大降低IO的處理量，讓性能表現得更出色。

通過多路復用實現百萬級RPS

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

測試消息結構

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

請求消息

響應消息

** 服務端處理代碼**

服務響應對象內容

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

客戶端請求代碼

客戶端測試發起代碼

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

測試配置

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

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

Dotnet core版本是:2.14

測試結果

客戶端統計結果

服務端統計信息

帶寬統計

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

下載測試代碼：https://github.com/IKende/BeetleX/blob/master/samples/MultiplexingConnectionTest.zip

原文地址:?https://www.cnblogs.com/smark/p/9836104.html

---

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的.net core通过多路复用实现单服务百万级别RPS吞吐的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。