C#多線程和高並發
阿新 • • 發佈：2017-09-16
tps 似的 反序 ans otn mage 位置 .cn prot
- 在任何 TCP Server 的實現中，一定存在一個 Accept Socket Loop，用於接收 Client 端的 Connect 請求以建立 TCP Connection。
- 在任何 TCP Server 的實現中，一定存在一個 Read Socket Loop，用於接收 Client 端 Write 過來的數據。
如果 Accept 循環阻塞，則會導致無法快速的建立連接，服務端 Pending Backlog 滿，進而導致 Client 端收到 Connect Timeout 的異常。如果 Read 循環阻塞，則顯然會導致無法及時收到 Client 端發過來的數據，進而導致 Client 端 Send Buffer 滿，無法再發送數據。
從實現細節的角度看，能夠導致服務阻塞的位置可能在：
- Accept 到新的 Socket，構建新的 Connection 需要分配各種資源，分配資源慢；
- Accept 到新的 Socket，沒有及時觸發下一次 Accept；
- Read 到新的 Buffer，判定 Payload 消息長度，判定過程長；
- Read 到新的 Buffer，發現 Payload 還沒有收全，繼續 Read，則 "可能" 會導致一次 Buffer Copy；
- Payload 接收完畢，進行 De-Serialization 轉成可識別的 Protocol Message，反序列化慢；
- 由 Business Module 來處理相應的 Protocol Message，處理過程慢；
1-2 涉及到 Accept 過程和 Connection 的建立過程，3-4 涉及到 ReceiveBuffer 的處理過程，5-6 涉及到應用邏輯側的實現。
Java 中著名的 Netty 網絡庫從 4.0 版本開始對於 Buffer 部分做了全新的嘗試，采用了名叫 ByteBuf 的設計，實現 Buffer Zero Copy 以減少高並發條件下 Buffer 拷貝帶來的性能損失和 GC 壓力。DotNetty，Orleans ，Helios 等項目正在嘗試在 C# 中進行類似的 ByteBuf 的實現。
1 單獨測試不停的有新的client連接server時：
測試方法：寫個client創建軟件，調用timer，每隔幾秒就創建一個新的client到server之間的連接，測試時打開多個client創建軟件
異步編程模式leafsoft軟件所寫的服務器在上百萬個可時連接狀態，單單只有連接沒有其他數據交互時，200萬
連接數目到一定程度時，此時server阻塞，無法分配新的資源給接下來的client,相當於server停止監聽，此時client軟件會有異常發生，異常位置在client連接server的方法內，異常如下：
C#多線程和高並發