高併發的socket的高性能設計

時間  2020-12-27
欄目 系統網絡 简体版
原文   原文鏈接

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

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)高效算法和技巧的使用等等

以上轉載自："祁峯"的CSDN博客：http://blog.csdn.net/qifengzou/article/details/23912267


高併發網絡編程之epoll詳解

在linux 沒有實現epoll事件驅動機制之前，我們一般選擇用select或者poll等IO多路複用的方法來實現併發服務程序。在大數據、高併發、集羣等一些名詞唱得火熱之年代，select和poll的用武之地越來越有限，風頭已經被epoll佔盡。

本文便來介紹epoll的實現機制，並附帶講解一下select和poll。通過對比其不同的實現機制，真正理解爲何epoll能實現高併發。

select()和poll() IO多路複用模型

select的缺點：

  1. 單個進程能夠監視的文件描述符的數量存在最大限制，通常是1024，當然可以更改數量，但由於select採用輪詢的方式掃描文件描述符，文件描述符數量越多，性能越差；(在linux內核頭文件中，有這樣的定義：#define __FD_SETSIZE    1024)
  2. 內核 / 用戶空間內存拷貝問題，select需要複製大量的句柄數據結構，產生巨大的開銷；
  3. select返回的是含有整個句柄的數組，應用程序需要遍歷整個數組才能發現哪些句柄發生了事件；
  4. select的觸發方式是水平觸發，應用程序如果沒有完成對一個已經就緒的文件描述符進行IO操作，那麼之後每次select調用還是會將這些文件描述符通知進程。

相比select模型，poll使用鏈表保存文件描述符，因此沒有了監視文件數量的限制，但其他三個缺點依然存在。

拿select模型爲例，假設我們的服務器需要支持100萬的併發連接，則在__FD_SETSIZE 爲1024的情況下，則我們至少需要開闢1k個進程才能實現100萬的併發連接。除了進程間上下文切換的時間消耗外，從內核/用戶空間大量的無腦內存拷貝、數組輪詢等，是系統難以承受的。因此，基於select模型的服務器程序，要達到10萬級別的併發訪問，是一個很難完成的任務。

因此，該epoll上場了。

epoll IO多路複用模型實現機制

由於epoll的實現機制與select/poll機制完全不同，上面所說的 select的缺點在epoll上不復存在。

設想一下如下場景：有100萬個客戶端同時與一個服務器進程保持着TCP連接。而每一時刻，通常只有幾百上千個TCP連接是活躍的(事實上大部分場景都是這種情況)。如何實現這樣的高併發？

在select/poll時代，服務器進程每次都把這100萬個連接告訴操作系統(從用戶態複製句柄數據結構到內核態)，讓操作系統內核去查詢這些套接字上是否有事件發生，輪詢完後，再將句柄數據複製到用戶態，讓服務器應用程序輪詢處理已發生的網絡事件，這一過程資源消耗較大，因此，select/poll一般只能處理幾千的併發連接。

epoll的設計和實現與select完全不同。epoll通過在Linux內核中申請一個簡易的文件系統(文件系統一般用什麼數據結構實現？B+樹)。把原先的select/poll調用分成了3個部分：

1）調用epoll_create()建立一個epoll對象(在epoll文件系統中爲這個句柄對象分配資源)

2）調用epoll_ctl向epoll對象中添加這100萬個連接的套接字

3）調用epoll_wait收集發生的事件的連接

如此一來，要實現上面說是的場景，只需要在進程啓動時建立一個epoll對象，然後在需要的時候向這個epoll對象中添加或者刪除連接。同時，epoll_wait的效率也非常高，因爲調用epoll_wait時，並沒有一股腦的向操作系統複製這100萬個連接的句柄數據，內核也不需要去遍歷全部的連接。

下面來看看Linux內核具體的epoll機制實現思路。

當某一進程調用epoll_create方法時，Linux內核會創建一個eventpoll結構體，這個結構體中有兩個成員與epoll的使用方式密切相關。eventpoll結構體如下所示：

[cpp]  view plain  copy
  1. structeventpoll{  
  2.     ....  
  3.    /*紅黑樹的根節點，這顆樹中存儲着所有添加到epoll中的需要監控的事件*/  
  4.     structrb_root  rbr;  
  5.    /*雙鏈表中則存放着將要通過epoll_wait返回給用戶的滿足條件的事件*/  
  6.     structlist_headrdlist;  
  7.    ....  
  8. };  
每一個epoll對象都有一個獨立的eventpoll結構體，用於存放通過epoll_ctl方法向epoll對象中添加進來的事件。這些事件都會掛載在紅黑樹中，如此，重複添加的事件就可以通過紅黑樹而高效的識別出來(紅黑樹的插入時間效率是lgn，其中n爲樹的高度)。

而所有添加到epoll中的事件都會與設備(網卡)驅動程序建立回調關係，也就是說，當相應的事件發生時會調用這個回調方法。這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。

在epoll中，對於每一個事件，都會建立一個epitem結構體，如下所示：

[cpp]  view plain  copy
  1. structepitem{  
  2.     structrb_node  rbn;//紅黑樹節點  
  3.     structlist_head    rdllink;//雙向鏈表節點  
  4.     structepoll_filefd  ffd;  //事件句柄信息  
  5.     structeventpoll *ep;    //指向其所屬的eventpoll對象  
  6.     structepoll_eventevent;//期待發生的事件類型  
  7. }  
當調用epoll_wait檢查是否有事件發生時，只需要檢查eventpoll對象中的rdlist雙鏈表中是否有epitem元素即可。如果rdlist不爲空，則把發生的事件複製到用戶態，同時將事件數量返回給用戶。

epoll數據結構示意圖

從上面的講解可知：通過紅黑樹和雙鏈表數據結構，並結合回調機制，造就了epoll的高效。

OK，講解完了Epoll的機理，我們便能很容易掌握epoll的用法了。一句話描述就是：三步曲。

第一步：epoll_create()系統調用。此調用返回一個句柄，之後所有的使用都依靠這個句柄來標識。

第二步：epoll_ctl()系統調用。通過此調用向epoll對象中添加、刪除、修改感興趣的事件，返回0標識成功，返回-1表示失敗。

第三部：epoll_wait()系統調用。通過此調用收集收集在epoll監控中已經發生的事件。

最後，附上一個epoll編程實例。(作者爲sparkliang)

[cpp]  view plain  copy
  1. //     
  2. // a simple echo server using epoll in linux    
  3. //     
  4. // 2009-11-05    
  5. // 2013-03-22:修改了幾個問題，1是/n格式問題，2是去掉了原代碼不小心加上的ET模式;  
  6. // 本來只是簡單的示意程序，決定還是加上 recv/send時的buffer偏移  
  7. // by sparkling    
  8. //     
  9. #include <sys/socket.h>    
  10. #include <sys/epoll.h>    
  11. #include <netinet/in.h>    
  12. #include <arpa/inet.h>    
  13. #include <fcntl.h>    
  14. #include <unistd.h>    
  15. #include <stdio.h>    
  16. #include <errno.h>    
  17. #include <iostream>    
  18. using namespace std;    
  19. #define MAX_EVENTS 500    
  20. struct myevent_s    
  21. {    
  22.     int fd;    
  23.     void (*call_back)(int fd, int events, void *arg);    
  24.     int events;    
  25.     void *arg;    
  26.     int status; // 1: in epoll wait list, 0 not in    
  27.     char buff[128]; // recv data buffer    
  28.     int len, s_offset;    
  29.     long last_active; // last active time    
  30. };    
  31. // set event    
  32. void EventSet(myevent_s *ev, int fd, void (*call_back)(int, int, void*), void *arg)    
  33. {    
  34.     ev->fd = fd;    
  35.     ev->call_back = call_back;    
  36.     ev->events = 0;    
  37.     ev->arg = arg;    
  38.     ev->status = 0;  
  39.     bzero(ev->buff, sizeof(ev->buff));  
  40.     ev->s_offset = 0;    
  41.     ev->len = 0;  
  42.     ev->last_active = time(NULL);    
  43. }    
  44. // add/mod an event to epoll    
  45. void EventAdd(int epollFd, int events, myevent_s *ev)    
  46. {    
  47.     struct epoll_event epv = {0, {0}};    
  48.     int op;    
  49.     epv.data.ptr = ev;    
  50.     epv.events = ev->events = events;    
  51.     if(ev->status == 1){    
  52.         op = EPOLL_CTL_MOD;    
  53.     }    
  54.     else{    
  55.         op = EPOLL_CTL_ADD;    
  56.         ev->status = 1;    
  57.     }    
  58.     if(epoll_ctl(epollFd, op, ev->fd, &epv) < 0)    
  59.     struct epoll_event epv = {0, {0}};    
  60.     int op;    
  61.     epv.data.ptr = ev;    
  62.     epv.events = ev->events = events;    
  63.     if(ev->status == 1){    
  64.         op = EPOLL_CTL_MOD;    
  65.     }    
  66.     else{    
  67.         op = EPOLL_CTL_ADD;    
  68.         ev->status = 1;    
  69.     }    
  70.     if(epoll_ctl(epollFd, op, ev->fd, &epv) < 0)    
  71.         printf("Event Add failed[fd=%d], evnets[%d]\n", ev->fd, events);    
  72.     else    
  73.         printf("Event Add OK[fd=%d], op=%d, evnets[%0X]\n", ev->fd, op, events);    
  74. }    
  75. // delete an event from epoll  
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程