本文的主要目的是闡述在單機上如何進行高并發、高性能消息傳輸系統的框架設計，以及該系統的常用技術，希望對您的學習有所幫助。

　　1 引言

　　随着互聯網和物聯網的高速發展，使用網絡的人數和電子設備的數量急劇增長，其也對互聯網後台服務程序提出了更高的性能和并發要求。如您有更好的設計方案和思路，望共分享之！[注：此篇用select來講解，雖在大并發的情況下，epoll擁有更高的效率，但整體設計思路是一緻的]

　　首先來看看課本和學習資料上關于處理并發網絡編程的三種常用方案，以及對應的大體思路和優缺點：

　　1) IO多路複用模型

　　-思路：單進程（非多線程）調用select()函數來處理多個連接請求。

　　-優點：單進程（非多線程）可支持同時處理多個網絡連接請求。

　　-缺點：最大并發為1024個，當并發數較大時，其處理性能很低。

　　2) 多進程模型

　　-思路：當連接請求過來時，主進程fork産生一個子進程，讓子進程負責與客戶端連接進行數據通信，當客戶端主動關閉連接後，子進程結束運行。

　　-優點：模式簡單，易于理解；連接請求很小時，效率較高。

　　-缺點：當連接請求過多時，系統資源很快被耗盡。比如：當連接請求達到10k時，難道要啟動10k個進程嗎？

　　3) 多線程模型

　　-思路：首先啟動多個工作線程，而主線程負責接收客戶端連接請求，工作線程負責與客戶端通信；當連接請求過來時，ACCEPT線程将sckid放入一個數組中，工作線程中的空閑線程從數組中取走一個sckid，對應的工作線程再與客戶端連接進行數據通信，當客戶端主動關閉連接後，此工作線程又去從指定數組中取sckid，依次重複運行。

　　-優點：擁有方案２)的優點，且能夠解決方案２)的缺點。

　　-缺點：不能支持并發量大的請求和量稍大的長連接請求。

　　通過對以上三種方案的分析，以上方案均不能滿足高并發、高性能的服務器的處理要求。針對以上設計方案問題的存在，該如何設計才能做到高并發、高性能的處理要求呢？

　　2 設計方案

　　2.1 大體框架

　　為提高并發量和處理性能，在此采用2層的設計架構。第一層由接收線程組成，負責接收客戶端數據；第二層由工作線程組成，負責對接收的數據進行相應處理。為了減少數據的複制和IO操作，将接收到的客戶端數據使用隊列進行存儲；工作線程收到處理指令後，從指令中提取相應的參數，便可知道到哪個線程的隊列中獲取數據。因此，系統的大體架構如下所示：

　　1) 框架－1

　　優點：

　　1)、有效避免接收線程之間出現鎖競争的情況。

　　每個接收線程對應一個接收隊列，每個接收線程将接收到的數據隻放在自己對應的隊列中；

　　2)、在數據量不是很大的情況下，此框架結構還是能夠滿足處理要求。

　　缺點：

　　1)、在連接數量很少、而數據量很大時，将會造成鎖沖突嚴重，緻使性能急劇下降。

　　假如：當前系統中隻有1個TCP連接，由RECV線程2負責接收該連接中的所有數據。Recv線程2每收到一條數據，就将随機通知工作線程到該隊列上取數據。在某個時刻，該連接的客戶端發來大量數據，将造成所有工作線程同時到Recv隊列2中來取數據。此時将會出現嚴重的鎖沖突現象，性能急劇下降。

　　2) 框架－2

　　優點：

　　1)、有效避免工作線程之間出現鎖競争的情況。

　　每個工作線程對應一個接收隊列，每個接收線程将接收到的數據隻放在自己對應的隊列中；

　　2)、工作線程數 = 2*接收線程數 時，能夠有效的減少接收線程之間的鎖競争的情況

　　在這種情況下，我想你可以得到你想要的處理性能！

　　缺點：

　　1)、需要為更高的性能，付出更多的系統資源(主要:内存和CPU)。

　　2.2 如何提高并發量

　　“并發量”是指系統可接受的TCP連接請求數。首先需要明确的是：高并發隻是一個相對概念。如：有些系統1K并發就算是高并發，而有些系統100K并發也不能滿足要求。因此，在此隻給出提高并發量的設計思路。

　　衆所周知，IO多路複用中1個select函數最多可管理FD_SETSIZE(該值一般為1024)個SOCKET套接字，而如果要求并發量達到100K時，顯然已大大超過了1個select的管理能力，那該如何解決？

　　答案是：使用多個select可以有效的解決以上問題。100K約等于100 * 1024，故需大約100個select才能有效管理100k并發。那該如何調用100個select來管理100k的并發呢？

　　因FD的管理在進程之間是獨立的，雖然子進程在創建之時，會繼承父進程的FD，但後續連接産生的FD卻無法讓子進程繼續繼承，因此，要實現對100k并發的有效管理，使用多線程實現高并發是理想的選擇。即：每個線程調用1個select，而每個select可以管理1024個并發。

　　在理想情況下，啟動N個接收線程，系統便可處理N *1024的并發。如：啟動100個接收線程，單機便可處理100 * 1024 = 100k的網絡并發。但需要注意的是：線程越多，消耗的資源越多，操作系統調度的開銷越大，如果調度開銷超過多線程帶來的性能提升，随着線程的增加，将導緻系統性能越低。(如果要求處理5k以上的請求，我将毫不猶豫的選擇多線程 epoll的方式)

　　2.3 如何提高處理性能

　　1) Recv流程

　　為了提高Recv線程接收來自客戶端的數據的性能，其處理過程需要使用到：IO多路複用技術，非阻塞IO技術、内存池技術、加鎖技術、事件觸發機制、負載均衡策略、UNINX-UDP技術、設計模式等，這需要研發人員對各技術有深刻的認識和理解。Recv線程的大體處理流程：

　　為了減少數據的複制，可以在接收數據開始時，Recv線程就為将要接收的數據從接收隊列中分配一塊空間。當Recv線程接收到一條完整的客戶端數據後，則通過UNINX-UDP發送消息，告知某一Work線程到指定接收隊列中取走數據進行處理。Recv線程通知Work線程的過程需要采用負載均衡策略。

　　2) Work流程

　　在無處理消息到來之前，一直處在阻塞狀态，當有Recv線程的處理通知時，則接收消息内容，對消息進行分析，再根據消息的内容到指定的接收隊列中取數據，再對數據進行相應的處理。其大體流程如下圖所示：

　　2.3 鍊路分發

　　說了這麼多，但一直未提到各Recv線程是如何分配和獲取客戶端通信SOCKET的。衆所周知，當一個線程通過TCP方式綁定指定端口後，其他線程或進程想再次綁定該端口時，必将返回錯誤。而如果讓一個Listen套接字同時加入到多個Recv線程的select的可讀集合進行監聽，又會出現“驚群現象：當有1個新的客戶端連接請求到來時，所有的Recv線程都會被驚醒 —— 這顯然是應該避免的。為了避免驚群的出現，通常有如下2種方案：

　　方案1) 創建鍊路分發模塊

　　當有客戶端連接請求過來時，該線程調用accept接收來自客戶端的連接，再将新SOCKET-FD分發給某1個Recv線程，該Recv線程再将FD加入select的FD_SET中進行監聽，從而實現Recv線程與客戶端的通信。

　　方案2) Lsn套接字流轉偵聽

　　當一個線程/進程搶占到該Listen套接字後，該線程/進程将會開始接收來自客戶端的連接請求和監聽産生的套接字以及後續的數據接收等工作，當該線程接收的套接字超過一定量時，該線程将會主動放棄對Listen套接字的監聽，而讓其他線程/進程去搶占Listen套接字。NGINX采用的就是此方案。

　　在此采用的是方案1)的解決辦法：Listen線程将接收的客戶端請求産生的通信SOCKET均衡的分發給RECV線程[采用UNINX-UDP的方式發送]。其大體框架如下：

　　3 方案總結

　　以上設計方案适合客戶端向服務端傳輸大量數據的場景，如果需要服務端反饋最終的處理結果，則需為Recv線程增加一個與之對應發送隊列，在此不再贅述。總之，要做到高并發、高性能的網絡通信系統，往往需要以下技術做支撐，這需要研發人員對以下技術擁有深刻的理解和認識，當然這還遠遠不夠。

　　1)IO多路複用技術 2)非阻塞IO技術 3)事件驅動機制 4)線程池技術 5)負載均衡策略 6)内存池技術 7)緩存技術 8)鎖技術 9)設計模式 10)高效算法和技巧的使用等等

　　原文鍊接：http://www.uml.org.cn/zjjs/201912191.asp

　　,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!