系統架構 之 高性能數據傳輸系統的框架設計

• 作者：鄒祁峯
• 郵箱：[email protected]
• 博客：http://blog.csdn.net/qifengzou
• 日期：2014.05.04
• 轉載請註明來自"祁峯"的CSDN博客

1 引言

   隨着互聯網和物聯網的高速發展，使用網絡的人數和電子設備的數量急劇增長，其也對互聯網後臺服務程序提出了更高的性能和併發要求。本文的主要目的是闡述在單機上如何進行高併發、高性能消息傳輸系統的框架設計，以及該系統的常用技術，但不對其技術細節進行討論。如您有更好的設計方案和思路，望共分享之！[注：此篇用select來講解，雖在大併發的情況下，epoll擁有更高的效率，但整體設計思路是一致的]

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

  1) IO多路複用模型

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

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

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

  2) 多進程模型

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

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

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

   3) 多線程模型

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

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

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

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

2 設計方案

2.1 大體框架

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

1) 框架－1

圖1 大體框架-01

[注：接收線程數:接收隊列數:工作線程數 = N:N:X]

優點：

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

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

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

缺點：

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

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

2) 框架－2

圖2 大體框架-02

[注：接收線程數:接收隊列數:工作線程數 = X:Y:Y]

優點：

   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線程的大體處理流程：

圖2 Recv線程處理流程

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

2) Work流程

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

圖3 Work線程處理流程

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的方式發送]。其大體框架如下：

圖4 鏈路分發

3 方案總結

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

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