Linux常用的併發模型

Linux 下設計併發網路程式，有典型的 Apache 模型（ Process Per Connection ，簡稱 PPC ）， TPC （ Thread Per Connection ）模型，以及 select 模型， poll 模型和epoll模型。
1 、PPC/TPC 模型
這兩種模型思想類似，就是讓每一個到來的連線一邊自己做事去，別再來煩我 。只是 PPC 是為它開了一個程序，而 TPC 開了一個執行緒。可是別煩我是有代價的，它要時間和空間啊，連線多了之後，那麼多的程序 / 執行緒切換，這開銷就上來了；因此這類模型能接受的最大連線數都不會高，一般在幾百個左右。

2 、select 模型
1. 最大併發數限制，因為一個程序所開啟的 FD （檔案描述符）是有限制的，由 FD_SETSIZE 設定，預設值是 1024/2048 ，因此 Select 模型的最大併發數就被相應限制了。當然自己可以修改這個 FD_SETSIZE 但是仍然存在其他的問題。
2. 效率問題， select 每次呼叫都會線性掃描全部的 FD 集合，這樣效率就會呈現線性下降，把 FD_SETSIZE 改大的後果就是，線性掃描時間會增大從而可能導致超時
3. 核心 / 使用者空間 記憶體拷貝問題，如何讓核心把 FD 訊息通知給使用者空間呢？在這個問題上 select 採取了記憶體拷貝方法。
3、 poll 模型

基本上效率和 select 是相同的， select 缺點的 2 和 3 它都沒有改掉。
4.epoll模型
epoll最大的好處在於它不會隨著監聽fd數目的增長而降低效率。Epoll 的改進之處如下
1. Epoll 沒有最大併發連線的限制，上限是最大可以開啟檔案的數目，這個數字一般遠大於 2048, 一般來說這個數目和系統記憶體關係很大 ，具體數目可以 cat /proc/sys/fs/file-max 察看。

2. 效率提升， Epoll 最大的優點就在於它只管你“活躍”的連線 ，而跟連線總數無關，因此在實際的網路環境中， Epoll 的效率就會遠遠高於 select 和 poll 。
3. 記憶體拷貝， Epoll 在這點上使用了“共享記憶體 ”，這個記憶體拷貝也省略了。

基於這樣的考慮，爬蟲的IO複用模型是採用epoll模型，下面在深入理解一下epoll模型

EPOLL

Epoll 為什麼高效
Epoll 的高效和其資料結構的設計是密不可分的。
首先回憶一下 select 模型，當有 I/O 事件到來時， select 通知應用程式有事件到了快去處理，而應用程式必須輪詢所有的 FD 集合，測試每個 FD 是否有事件發生，並處理事件。
epoll的資料結構

struct epoll_event {
   __uint32_t events;      // Epollevents
   epoll_data_t data;      // Userdata variable
};
typedef union epoll_data {
   void *ptr;
   int fd;
   __uint32_t u32;
   __uint64_t u64;
} epoll_data_t;

int res = select(maxfd+1, &readfds, NULL, NULL, 120);
if (res > 0)
{//這裡必須遍歷所有，包括活躍和不活躍的事件
    for (int i = 0; i < MAX_CONNECTION; i++)
    {
        if (FD_ISSET(allConnection[i], &readfds))
        {
            handleEvent(allConnection[i]);
        }
    }
}
// if(res == 0) handle timeout, res < 0 handle error

Epoll 不僅會告訴應用程式有I/0 事件到來，還會告訴應用程式相關的資訊，這些資訊是應用程式填充的，因此根據這些資訊應用程式就能直接定位到事件，而不必遍歷整個FD 集合。

int res = epoll_wait(epfd, events, 20, 120);
for (int i = 0; i < res;i++)
{//epoll_wait返回的都是活躍的事件
    handleEvent(events[n]);
}

epoll的介面
epoll的介面非常簡單，一共就三個函式：

1. int epoll_create(int size);

建立一個epoll的控制代碼，size用來告訴核心這個監聽的數目一共有多大（自從linux2.6.8之後，size引數是被忽略的）。這個引數不同於select()中的第一個引數，給出最大監聽的fd+1的值。需要注意的是，當建立好epoll控制代碼後，它就是會佔用一個fd值，在linux下如果檢視/proc/程序id/fd/，是能夠看到這個fd的，所以在使用完epoll後，必須呼叫close()關閉，否則可能導致fd被耗盡。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件註冊函式，它不同與select()是在監聽事件時告訴核心要監聽什麼型別的事件，而是在這裡先註冊要監聽的事件型別。控制某個 Epoll 檔案描述符上的事件：註冊、修改、刪除。

第一個引數是epoll_create()的返回值，建立 Epoll 專用的檔案描述符。相對於 select 模型中的 FD_SET 和 FD_CLR 巨集。
第二個引數表示動作，用三個巨集來表示：
EPOLL_CTL_ADD：註冊新的fd到epfd中；
EPOLL_CTL_MOD：修改已經註冊的fd的監聽事件；
EPOLL_CTL_DEL：從epfd中刪除一個fd；
第三個引數是需要監聽的fd，
第四個引數是告訴核心需要監聽什麼事，struct epoll_event結構如下：

struct epoll_event {
  __uint32_t events;  /* Epoll events */
  epoll_data_t data;  /* User data variable */
};

events可以是以下幾個巨集的集合：
EPOLLIN ： 表示對應的檔案描述符可以讀（包括對端SOCKET正常關閉）；
EPOLLOUT： 表示對應的檔案描述符可以寫；
EPOLLPRI： 表示對應的檔案描述符有緊急的資料可讀（這裡應該表示有帶外資料到來）；
EPOLLERR： 表示對應的檔案描述符發生錯誤；
EPOLLHUP： 表示對應的檔案描述符被結束通話；
EPOLLET： 將EPOLL設為邊緣觸發(Edge Triggered)模式，這是相對於水平觸發(Level Triggered)來說的。
EPOLLONESHOT： 只監聽一次事件，當監聽完這次事件之後，如果還需要繼續監聽這個socket的話，需要再次把這個socket加入到EPOLL佇列裡

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

等待 I/O 事件的發生；引數說明：
epfd: 由 epoll_create() 生成的 Epoll 專用的檔案描述符；
epoll_event: 用於回傳代處理事件的陣列；
maxevents: 每次能處理的事件數；
timeout: 等待 I/O 事件發生的超時值；
返回發生事件數。
相對於 select 模型中的 select 函式。

引數events用來從核心得到事件的集合，maxevents告之核心這個events有多大，這個maxevents的值不能大於建立epoll_create()時的size，引數timeout是超時時間（毫秒，0會立即返回，-1將不確定，也有說法說是永久阻塞）。該函式返回需要處理的事件數目，如返回0表示已超時。

生成一個 Epoll 專用的檔案描述符，其實是申請一個核心空間，用來存放你想關注的 socket fd 上是否發生以及發生了什麼事件。 size 就是你在這個 Epoll fd 上能關注的最大 socket fd 數，大小自定，只要記憶體足夠。
EPOLL的兩種模式
epoll有兩種工作模式，這個和觸發器的叫法差不多，分為LT（電平觸發）和ET（邊沿觸發）
Edge Triggered (ET) 邊沿觸發 只有資料到來，才觸發，不管快取區中是否還有資料。
Level Triggered (LT) 電平觸發 只要有資料都會觸發。
這個觸發方式和觸發器類似，不難理解。下面看看從別處看到的一個例子
例如：
1. 我們已經把一個用來從管道中讀取資料的檔案控制代碼(RFD)新增到epoll描述符
2. 這個時候從管道的另一端被寫入了2KB的資料
3. 呼叫epoll_wait(2)，並且它會返回RFD，說明它已經準備好讀取操作
4. 然後我們讀取了1KB的資料
5. 呼叫epoll_wait(2)……

Edge Triggered 工作模式：
如果我們在第1步將RFD新增到epoll描述符的時候使用了EPOLLET標誌，那麼在第5步呼叫epoll_wait(2)之後將有可能會掛起，因為剩餘的資料還存在於檔案的輸入緩衝區內，而且資料發出端還在等待一個針對已經發出資料的反饋資訊。只有在監視的檔案控制代碼上發生了某個事件的時候 ET 工作模式才會彙報事件。因此在第5步的時候，呼叫者可能會放棄等待仍在存在於檔案輸入緩衝區內的剩餘資料。在上面的例子中，會有一個事件產生在RFD控制代碼上，因為在第2步執行了一個寫操作，然後，事件將會在第3步被銷燬。因為第4步的讀取操作沒有讀空檔案輸入緩衝區內的資料，因此我們在第5步呼叫 epoll_wait(2)完成後，是否掛起是不確定的。epoll工作在ET模式的時候，必須使用非阻塞套介面，以避免由於一個檔案控制代碼的阻塞讀/阻塞寫操作把處理多個檔案描述符的任務餓死。最好以下面的方式呼叫ET模式的epoll介面，在後面會介紹避免可能的缺陷。
i 基於非阻塞檔案控制代碼
ii 只有當read(2)或者write(2)返回EAGAIN時才需要掛起，等待。但這並不是說每次read()時都需要迴圈讀，直到讀到產生一個EAGAIN才認為此次事件處理完成，當read()返回的讀到的資料長度小於請求的資料長度時，就可以確定此時緩衝中已沒有資料了，也就可以認為此事讀事件已處理完成。

Level Triggered 工作模式
相反的，以LT方式呼叫epoll介面的時候，它就相當於一個速度比較快的poll(2)，並且無論後面的資料是否被使用，因此他們具有同樣的職能。因為即使使用ET模式的epoll，在收到多個chunk的資料的時候仍然會產生多個事件。呼叫者可以設定EPOLLONESHOT標誌，在 epoll_wait(2)收到事件後epoll會與事件關聯的檔案控制代碼從epoll描述符中禁止掉。因此當EPOLLONESHOT設定後，使用帶有 EPOLL_CTL_MOD標誌的epoll_ctl(2)處理檔案控制代碼就成為呼叫者必須作的事情。
詳細解釋ET, LT:
LT(level triggered)是預設的工作方式，並且同時支援block和no-block socket.在這種做法中，核心告訴你一個檔案描述符是否就緒了，然後你可以對這個就緒的fd進行IO操作。如果你不作任何操作，核心還是會繼續通知你的，所以，這種模式程式設計出錯誤可能性要小一點。傳統的select/poll都是這種模型的代表．
ET(edge-triggered)是高速工作方式，只支援no-block socket。在這種模式下，當描述符從未就緒變為就緒時，核心通過epoll告訴你。然後它會假設你知道檔案描述符已經就緒，並且不會再為那個檔案描述符傳送更多的就緒通知，直到你做了某些操作導致那個檔案描述符不再為就緒狀態了(比如，你在傳送，接收或者接收請求，或者傳送接收的資料少於一定量時導致了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，核心不會發送更多的通知(only once),不過在TCP協議中，ET模式的加速效用仍需要更多的benchmark確認。
值得注意的事，每種模型並沒有絕對的好壞之分，各種模型均有他的價值，要依據不同的工作場景選擇不同的模型
在許多測試中我們會看到如果沒有大量的idle -connection或者dead-connection，epoll的效率並不會比select/poll高很多，但是當我們遇到大量的idle- connection(例如WAN環境中存在大量的慢速連線)，就會發現epoll的效率大大高於select/poll。

另外，當使用epoll的ET模型來工作時，當產生了一個EPOLLIN事件後，
讀資料的時候需要考慮的是當recv()返回的大小如果等於請求的大小，那麼很有可能是緩衝區還有資料未讀完，也意味著該次事件還沒有處理完，所以還需要再次讀取：

while(rs)
{
  buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
  if(buflen < 0)
  {
    // 由於是非阻塞的模式,所以當errno為EAGAIN時,表示當前緩衝區已無資料可讀
    // 在這裡就當作是該次事件已處理處.
    if(errno == EAGAIN)
     break;
    else
     return;
   }
   else if(buflen == 0)
   {
     // 這裡表示對端的socket已正常關閉.
   }
   if(buflen == sizeof(buf)
     rs = 1;   // 需要再次讀取
   else
     rs = 0;
}

還有，假如傳送端流量大於接收端的流量(意思是epoll所在的程式讀比轉發的socket要快),由於是非阻塞的socket,那麼send()函式雖然返回,但實際緩衝區的資料並未真正發給接收端,這樣不斷的讀和發，當緩衝區滿後會產生EAGAIN錯誤(參考man send),同時,不理會這次請求傳送的資料.所以,需要封裝socket_send()的函式用來處理這種情況,該函式會盡量將資料寫完再返回，返回-1表示出錯。在socket_send()內部,當寫緩衝已滿(send()返回-1,且errno為EAGAIN),那麼會等待後再重試.這種方式並不很完美,在理論上可能會長時間的阻塞在socket_send()內部,但暫沒有更好的辦法.

ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
  ssize_t tmp;
  size_t total = buflen;
  const char *p = buffer;
  while(1)
  {
    tmp = send(sockfd, p, total, 0);
    if(tmp < 0)
    {
      // 當send收到訊號時,可以繼續寫,但這裡返回-1.
      if(errno == EINTR)
        return -1;
      // 當socket是非阻塞時,如返回此錯誤,表示寫緩衝佇列已滿,
      // 在這裡做延時後再重試.
      if(errno == EAGAIN)
      {
        usleep(1000);
        continue;
      }
      return -1;
    }
    if((size_t)tmp == total)
      return buflen;
    total -= tmp;
    p += tmp;
  }

  return tmp;
}

參考文章