再谈Linux epoll惊群问题的原因和解决方案
差別是什么？差別只是西裝！
緣起
近期排查了一個問題，epoll驚群的問題，起初我并不認為這是驚群導致，因為從現象上看，只是體現了CPU不均衡。一共fork了20個Server進程，在請求負載中等的時候，有三四個Server進程呈現出比較高的CPU利用率，其余的Server進程的CPU利用率都是非常低。
中斷，軟中斷都是均衡的，網卡RSS和CPU之間進行了bind之后依然如故，既然系統層面查不出個所以然，只能從服務的角度來查了。
自上而下的排查首先就想到了strace，沒想到一下子就暴露了原形：
accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable)如果僅僅strace accept，即加上“-e trace=accept”參數的話，偶爾會有accept成功的現象：
accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, {sa_family=AF_INET, sin_port=htons(39306), sin_addr=inet_addr("172.16.1.202")}, [16]) = 19 accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable) accept(4, 0x9ecd930, [16]) = -1 EAGAIN (Resource temporarily unavailable)大量的CPU空轉，進一步加大請求負載，CPU空轉明顯降低，這說明在預期的空轉期間，新來的請求降低了空轉率…現象明顯偏向于這就是驚群導致的之判斷！
本文將詳細說一下關于epoll的細節。現在開始！
關于epoll的文章，我很早前寫過一篇總結性的，可以參考這里：
Linux內核中網絡數據包的接收-第二部分 select/poll/epoll：https://blog.csdn.net/dog250/article/details/50528373
不過這篇文章主要是原理性的介紹，對于一開始并不充分理解epoll機制的人來講，可讀性并不強，所以我準備寫一篇稍微接地氣的，比如帶有一些“源碼分析”的文章，雖然我并不是很喜歡源碼分析，但有時對于快速理解為什么這樣還是必要的。
題目中為什么是“再談”，因為這個話題別人已經聊過很多了，我順勢繼續下去而已。
簡單介紹驚群和事件模型
關于什么是驚群，這里不再做概念上的解釋，能搜到這篇文章的想必已經有所了解，如果仍有概念上的疑惑，自行百度或者谷歌。
驚群問題一般出現在那些web服務器上，曾經Linux系統有個經典的accept驚群問題困擾了大家非常久的時間，這個問題現在已經在內核曾經得以解決，具體來講就是當有新的連接進入到accept隊列的時候，內核喚醒且僅喚醒一個進程來處理，這是通過以下的代碼來實現的：
list_for_each_entry_safe(curr, next, &q->task_list, task_list) {unsigned flags = curr->flags;if (curr->func(curr, mode, wake_flags, key) &&(flags & WQ_FLAG_EXCLUSIVE) && !--nr_exclusive)break;}是的，添加了一個WQ_FLAG_EXCLUSIVE標記，告訴內核進行排他性的喚醒，即喚醒一個進程后即退出喚醒的過程，問題得以解決。
然而，沒有哪個web服務器會傻到多個進程直接阻塞在accept上準備接收請求，在更高層次上，多路復用的需求讓select，poll，epoll等事件模型更為受到歡迎，所謂的事件模型即阻塞在事件上而不是阻塞在事務上。內核僅僅通知發生了某件事，具體發生了什么事，則有處理進程或者線程自己來poll。如此一來，這個事件模型(無論其實現是select，poll，還是epoll)便可以一次搜集多個事件，從而滿足多路復用的需求。
好了，基本原理就介紹到這里，下面我將來詳細談一下Linux epoll中的驚群問題，我們知道epoll在實際中要比直接accept實用性強很多，據我所知，除非編程學習或者驗證性小demo，幾乎沒有直接accept的代碼，所有的線上代碼幾乎都使用了事件模型。然而由于select，poll沒有可擴展性，存在O(n)O(n)問題，因此在帶寬越來越高，服務器性能越來越強的趨勢下，越來越多的代碼將收斂到使用epoll的情形，所以有必要對其進行深入的討論。
Linux epoll驚群問題
知乎上有一個問題：
Linux 3.x 中epoll的驚群問題？：https://www.zhihu.com/question/24169490/answers/created
建議先看一下，但不要看回答，因為知乎上上的很多回答往往會讓事情變得更加混亂，除非你自己對這個問題已經有了自己的答案或者觀點，否則還是不要去指望在諸多的答案中選一個自己滿意的來用，還是要自己先思考。
下面我來就這個問題給一個答案，這也是我自己思考的答案：
What？使用方法不對？
是的，使用方法不對。若想了解Why，則必須對epoll的實現細節以及其對外提供的API的語義有充分的理解，接下來我們就循著這個思路來擼個所以然。請繼續閱讀。
Linux epoll的實現機制
說起實現原理，很多人喜歡擼源碼分析，我并不喜歡，我認為源碼是自己看看就行了，搞這個行業的能看懂代碼是一個最最基本的能力，我比較在意的是對某種機制內在邏輯的深入理解，而這個通過代碼是體現不出來的，我一般會做下面幾件事：
- 運行起來并測得預期的數據
- 看懂代碼并畫出原理圖
- 自己重新實現一版(時間精力允許的情況下)
- 寫個demo驗證一些具體邏輯細節
不多說。
下面是我總結的一張關于Linux epoll的原理圖：
要說代碼實現上，其實也比較簡單，大致有以下的幾個邏輯：
來，一個一個說
1.創建epoll句柄，初始化相關數據結構
這里主要就是創建一個epoll文件描述符，注意，后面操作epoll的時候，就是用這個epoll的文件描述符來操作的，所以這就是epoll的句柄，精簡過后的epoll結構如下：
struct eventpoll {// 阻塞在epoll_wait的task的睡眠隊列wait_queue_head_t wq;// 存在就緒文件句柄的list，該list上的文件句柄事件將會全部上報給應用struct list_head rdllist;// 存放加入到此epoll句柄的文件句柄的紅黑樹容器struct rb_root rbr;// 該epoll結構對應的文件句柄，應用通過它來操作該epoll結構struct file *file; };2.為epoll句柄添加文件句柄，注冊睡眠entry的回調
這個步驟中其實有兩個子步驟：
1). 添加文件句柄
將一個文件句柄，比如socket添加到epoll的rbr紅黑樹容器中，注意，這里的文件句柄最終也是一個包裝結構，和epoll的結構體類似：
以上結構實例就是epi，將被添加到epoll的rbr容器中的邏輯如下：
struct eventpoll *ep = 待加入文件句柄所屬的epoll句柄; struct file *tfile = 待加入的文件句柄file結構體; int fd = 待加入的文件描述符ID;struct epitem *epi = kmem_cache_alloc(epi_cache, GFP_KERNEL); INIT_LIST_HEAD(&epi->rdllink); INIT_LIST_HEAD(&epi->fllink); INIT_LIST_HEAD(&epi->pwqlist); epi->ep = ep; ep_set_ffd(&epi->ffd, tfile, fd); ... ep_rbtree_insert(ep, epi);2). 注冊睡眠entry回調并poll文件句柄
在第一個子步驟的代碼邏輯中，我有一段“…”省略掉了，這部分比較關鍵，所以我單獨抽取了出來作為第二個子步驟。
我們知道，Linux內核的sleep/wakeup機制非常重要，幾乎貫穿了所有的內核子系統，值得注意的是，這里的sleep/wakeup依然采用了OO的思想，并沒有限制睡眠的entry一定要是一個task，而是將睡眠的entry做了一層抽象，即：
以上的這個entry，最終要睡眠在下面的數據結構實例化的一個鏈表上：
struct __wait_queue_head {spinlock_t lock;struct list_head task_list; };顯然，在這里，一個文件句柄均有自己睡眠隊列用于等待自己發生事件的entry在沒有發生事件時來歇息，對于TCP socket而言，該睡眠隊列就是其sk_wq，通過以下方式取到：
static inline wait_queue_head_t *sk_sleep(struct sock *sk) {return &rcu_dereference_raw(sk->sk_wq)->wait; }我們需要一個entry將來在發生事件的時候從上述wait_queue_head_t中被喚醒，執行特定的操作，即將自己放入到epoll句柄的“就緒鏈表”中。下面的函數可以完成該邏輯的框架：
// 此處的whead就是上面例子中的sk_sleep返回的wait_queue_head_t實例。 static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,poll_table *pt) {struct epitem *epi = ep_item_from_epqueue(pt);struct eppoll_entry *pwq;if (pwq = kmem_cache_alloc(pwq_cache, GFP_KERNEL)) {// 發生事件即調用ep_poll_callback回調函數，該回調函數會將自己這個epitem加入到epoll的“就緒鏈表”中去。init_waitqueue_func_entry(&pwq->wait, ep_poll_callback);// 是否排他喚醒取決于用戶的配置，有些IO是希望喚醒所有entry來處理，有些則不必。注意，這里是針對文件句柄IO而言的，并不是針對epoll句柄的。if (epi->event.events & EPOLLEXCLUSIVE)add_wait_queue_exclusive(whead, &pwq->wait);elseadd_wait_queue(whead, &pwq->wait);} }至于說什么時候調用上面的函數，Linux的poll機制仍然是采用了分層抽象的思想，即上述函數會作為另一個回調在相關文件句柄的poll函數中被調用。即：
static inline unsigned int ep_item_poll(struct epitem *epi, poll_table *pt) {pt->_key = epi->event.events;return epi->ffd.file->f_op->poll(epi->ffd.file, pt) & epi->event.events; }
對于TCP socket而言，其file_operations的poll回調即：
unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait) {unsigned int mask;struct sock *sk = sock->sk;const struct tcp_sock *tp = tcp_sk(sk);// 此函數會調用poll_wait->wait._qproc// 而wait._qproc就是ep_ptable_queue_procsock_poll_wait(file, sk_sleep(sk), wait);... }現在，我們可以把子步驟1中的邏輯補全了：
struct eventpoll *ep = 待加入文件句柄所屬的epoll句柄; struct file *tfile = 待加入的文件句柄file結構體; int fd = 待加入的文件描述符ID;struct epitem *epi = kmem_cache_alloc(epi_cache, GFP_KERNEL); INIT_LIST_HEAD(&epi->rdllink); INIT_LIST_HEAD(&epi->fllink); INIT_LIST_HEAD(&epi->pwqlist); epi->ep = ep; ep_set_ffd(&epi->ffd, tfile, fd); // 這里會將wait._qproc初始化成ep_ptable_queue_proc init_poll_funcptr(&epq.pt, ep_ptable_queue_proc); // 這里會調用wait._qproc即ep_ptable_queue_proc，安排entry的回調函數ep_poll_callback，并將entry“睡眠”在socket的sk_wq這個睡眠隊列上。 revents = ep_item_poll(epi, &epq.pt); ep_rbtree_insert(ep, epi); // 如果剛才的ep_item_poll取出了事件，隨即將該item掛入“就緒隊列”中，并且wakeup阻塞在epoll_wait系統調用中的task！ if ((revents & event->events) && !ep_is_linked(&epi->rdllink)) {list_add_tail(&epi->rdllink, &ep->rdllist);if (waitqueue_active(&ep->wq))wake_up_locked(&ep->wq); }3.事件發生，喚醒相關文件句柄睡眠隊列的entry，調用其回調
上面已經很詳細地描述了epoll的基礎設施了，現在我們假設一個TCP Listen socket上來了一個連接請求，已經完成了三次握手，內核希望通知epoll_wait返回，然后去取accept。
內核在wakeup這個socket的sk_wq時，最終會調用到ep_poll_callback回調，這個函數我們說了好幾次了，現在看看它的真面目：
沒什么好多說的。現在“就緒鏈表”已經有epi了，接下來就要喚醒epoll_wait進程去處理了。
4.喚醒epoll睡眠隊列的task，搜集并上報數據
這個邏輯主要集中在ep_poll函數，精簡版如下：
其中關鍵在ep_send_events，這個函數實現了非常重要的邏輯，包括LT和ET的邏輯，我不打算深入去解析這個函數，只是大致說下流程：
ep_scan_ready_list() {// 遍歷“就緒鏈表”ready_list_for_each() {// 將epi從“就緒鏈表”刪除list_del_init(&epi->rdllink);// 實際獲取具體的事件。// 注意，睡眠entry的回調函數只是通知有“事件”，具體需要每一個文件句柄的特定poll回調來獲取。revents = ep_item_poll(epi, &pt);if (revents) {if (__put_user(revents, &uevent->events) ||__put_user(epi->event.data, &uevent->data)) {// 如果沒有完成，則將epi重新加回“就緒鏈表”等待下次。list_add(&epi->rdllink, head);return eventcnt ? eventcnt : -EFAULT;}// 如果是LT模式，則無論如何都會將epi重新加回到“就緒鏈表”，等待下次重新再poll以確認是否仍然有未處理的事件。這也符合“水平觸發”的邏輯，即“只要你不處理，我就會一直通知你”。if (!(epi->event.events & EPOLLET)) {list_add_tail(&epi->rdllink, &ep->rdllist);}}}// 如果“就緒鏈表”上仍有未處理的epi，且有進程阻塞在epoll句柄的睡眠隊列，則喚醒它！(這將是LT驚群的根源)if (!list_empty(&ep->rdllist)) {if (waitqueue_active(&ep->wq))wake_up_locked(&ep->wq);} }這里的代碼邏輯的分析過程就到此為止了。以對這個代碼邏輯的充分理解為基礎，接下來我們就可以看具體的問題細節了。
下面一小節先從LT(水平觸發模式)以及ET(即邊沿觸發模式)開始。
epoll的LT和ET以及相關細節問題
簡單點解釋：
- LT水平觸發
如果事件來了，不管來了幾個，只要仍然有未處理的事件，epoll都會通知你。 - ET邊沿觸發
如果事件來了，不管來了幾個，你若不處理或者沒有處理完，除非下一個事件到來，否則epoll將不會再通知你。
理解了上面說的兩個模式，便可以很明確地展示可能會遇到的問題以及解決方案了，這將非常簡單。
LT水平觸發模式的問題以及解決
下面是epoll使用中非常常見的代碼框架，我將問題注釋于其中：
// 否則會阻塞在IO系統調用，導致沒有機會再epoll set_socket_nonblocking(sd); epfd = epoll_create(64); event.data.fd = sd; epoll_ctl(epfd, EPOLL_CTL_ADD, sd, &event); while (1) {epoll_wait(epfd, events, 64, xx);... // 危險區域！如果有共享同一個epfd的進程/線程調用epoll_wait，它們也將會被喚醒！// 這個accept將會有多個進程/線程調用，如果并發請求數很少，那么將僅有幾個進程會成功：// 1. 假設accept隊列中有n個請求，則僅有n個進程能成功，其它將全部返回EAGAIN (Resource temporarily unavailable)// 2. 如果n很大(即增加請求負載)，雖然返回EAGAIN的比率會降低，但這些進程也并不一定取到了epoll_wait返回當下的那個預期的請求。csd = accept(sd, &in_addr, &in_len); ... }這一切為什么會發生？
我們結合理論和代碼一起來分析。
再看一遍LT的描述“如果事件來了，不管來了幾個，只要仍然有未處理的事件，epoll都會通知你。”，顯然，epoll_wait剛剛取到事件的時候的時候，不可能馬上就調用accept去處理，事實上，邏輯在epoll_wait函數調用的ep_poll中還沒返回的，這個時候，顯然符合“仍然有未處理的事件”這個條件，顯然這個時候為了實現這個語義，需要做的就是通知別的同樣阻塞在同一個epoll句柄睡眠隊列上的進程！在實現上，這個語義由兩點來保證：
我們來看一個情景分析。
假設LT模式下有10個進程共享同一個epoll句柄，此時來了一個請求client進入到accept隊列，我們發現上述的1和2是一個循環喚醒的過程：
1).假設進程a的epoll_wait首先被ep_poll_callback喚醒，那么滿足1和2，則喚醒了進程B；
2).進程B在處理ep_scan_ready_list的時候，發現依然滿足1和2，于是喚醒了進程C….
3).上面1)和2)的過程一直到之前某個進程將client取出，此時下一個被喚醒的進程在ep_scan_ready_list中的ep_item_poll調用中將得不到任何事件，此時便不會再將該epi加回“就緒鏈表”了，LT水平觸發結束，結束了這場悲傷的夢！
問題非常明確了，但是怎么解決呢？也非常簡單，讓不同進程的epoll_waitI調用互斥即可。
但是且慢！
上面的情景分析所展示的是一個“驚群效應”嗎？其實并不是！對于Listen socket，當然要避免這種情景，但是對于很多其它的I/O文件句柄，說不定還指望著大家一起來read數據呢…所以說，要說互斥也僅僅要針對Listen socket的epoll_wait調用而言。
換句話說，這里epoll LT模式下有進程被不必要喚醒，這一點并不是內核無意而為之的，內核肯定是知道這件事的，這個并不像之前accept驚群那樣算是內核的一個缺陷。epoll LT模式只是提供了一種模式，誤用這種模式將會造成類似驚群那樣的效應。但是不管怎么說，為了討論上的方便，后面我們姑且將這種效應稱作epoll LT驚群吧。
除了epoll_wait互斥之外，還有一種解決問題的方案，即使用ET邊沿觸發模式，但是會遇到新的問題，我們接下來來描述。
ET邊沿觸發模式的問題以及解決
ET模式不滿足上述的“保證1”，所以不會將已經上報事件的epi重新鏈接回“就緒鏈表”，也就是說，只要一個“就緒隊列”上的epi上的事件被上報了，它就會被刪除出“就緒隊列”。
由于epi entry的callback即ep_poll_callback所做的事情僅僅是將該epi自身加入到epoll句柄的“就緒鏈表”，同時喚醒在epoll句柄睡眠隊列上的task，所以這里并不對事件的細節進行計數，比如說，如果ep_poll_callback在將一個epi加入“就緒鏈表”之前發現它已經在“就緒鏈表”了，那么就不會再次添加，因此可以說，一個epi可能pending了多個事件，注意到這點非常重要！
一個epi上pending多個事件，這個在LT模式下沒有任何問題，因為獲取事件的epi總是會被重新添加回“就緒鏈表”，那么如果還有事件，在下次check的時候總會取到。然而對于ET模式，僅僅將epi從“就緒鏈表”刪除并將事件本身上報后就返回了，因此如果該epi里還有事件，則只能等待再次發生事件，進而調用ep_poll_callback時將該epi加入“就緒隊列”。這意味著什么？
這意味著，應用程序，即epoll_wait的調用進程必須自己在獲取事件后將其處理干凈后方可再次調用epoll_wait，否則epoll_wait不會返回，而是必須等到下次產生事件的時候方可返回。即，依然以accept為例，必須這樣做：
// 否則會阻塞在IO系統調用，導致沒有機會再epoll set_socket_nonblocking(sd); epfd = epoll_create(64); event.data.fd = sd; // 添加ET標記 event.events |= EPOLLET; epoll_ctl(epfd, EPOLL_CTL_ADD, sd, &event); while (1) {epoll_wait(epfd, events, 64, xx);while ((csd = accept(sd, &in_addr, &in_len)) > 0) {do_something(...);} ... }好了，解釋完了。
以上就是epoll的LT，ET相關的兩個問題和解決方案。接下來的一節，我將用一個小小的簡單Demo來重現上面描述的理論和代碼。
測試demo
是時候給出一個實際能run的代碼了：
#include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <sys/epoll.h> #include <netdb.h> #include <fcntl.h> #include <sys/wait.h> #include <time.h> #include <signal.h>#define COUNT 1int mode = 0; int slp = 0;int pid[COUNT] = {0}; int count = 0;void server(int epfd) {struct epoll_event *events;int num, i;struct timespec ts;events = calloc(64, sizeof(struct epoll_event));while (1) {int sd, csd;struct sockaddr in_addr;num = epoll_wait(epfd, events, 64, -1);if (num <= 0) {continue;}/*ts.tv_sec = 0;ts.tv_nsec = 1;if(nanosleep(&ts, NULL) != 0) {perror("nanosleep");exit(1);}*/// 用于測試ET模式下丟事件的情況if (slp) {sleep(slp);}sd = events[0].data.fd;socklen_t in_len = sizeof(in_addr);csd = accept(sd, &in_addr, &in_len);if (csd == -1) {// 打印這個說明中了epoll LT驚群的招了。printf("shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:%d\n", getpid()); continue;}// 本進程一共成功處理了多少個請求。count ++;printf("get client:%d\n", getpid()); close(csd);} }static void siguser_handler(int sig) {// 在主進程被Ctrl-C退出的時候，每一個子進程均要打印自己處理了多少個請求。printf("pid:%d count:%d\n", getpid(), count);exit(0); }static void sigint_handler(int sig) {int i = 0;// 給每一個子進程發信號，要求其打印自己處理了多少個請求。for (i = 0; i < COUNT; i++) {kill(pid[i], SIGUSR1);} }int main (int argc, char *argv[]) {int ret = 0;int listener;int c = 0;struct sockaddr_in saddr;int port;int status;int flags;int epfd;struct epoll_event event;if (argc < 4) {exit(1);}// 0為LT模式，1為ET模式mode = atoi(argv[1]);port = atoi(argv[2]);// 是否在處理accept之前耽擱一會兒，這個參數更容易重現問題slp = atoi(argv[3]);signal(SIGINT, sigint_handler);listener = socket(PF_INET, SOCK_STREAM, 0);saddr.sin_family = AF_INET;saddr.sin_port = htons(port);saddr.sin_addr.s_addr = INADDR_ANY;bind(listener, (struct sockaddr*)&saddr, sizeof(saddr));listen(listener, SOMAXCONN);flags = fcntl (listener, F_GETFL, 0);flags |= O_NONBLOCK;fcntl (listener, F_SETFL, flags);epfd = epoll_create(64);if (epfd == -1) {perror("epoll_create");abort();}event.data.fd = listener;event.events = EPOLLIN;if (mode == 1) {event.events |= EPOLLET;} else if (mode == 2) {event.events |= EPOLLONESHOT;} ret = epoll_ctl(epfd, EPOLL_CTL_ADD, listener, &event);if (ret == -1) {perror("epoll_ctl");abort();}for(c = 0; c < COUNT; c++) {int child;child = fork();if(child == 0) {// 安裝打印count值的信號處理函數signal(SIGUSR1, siguser_handler);server(epfd);}pid[c] = child;printf("server:%d pid:%d\n", c+1, child);}wait(&status);sleep(1000000);close (listener); }編譯之，為a.out。
測試客戶端選用了簡單webbench，首先我們看一下LT水平觸發模式下的問題：
[zhaoya@shit ~/test]$ sudo ./a.out 0 112 0 server:1 pid:9688 server:2 pid:9689 server:3 pid:9690 server:4 pid:9691 server:5 pid:9692 server:6 pid:9693 server:7 pid:9694 server:8 pid:9695 server:9 pid:9696 server:10 pid:9697另起一個終端運行webbench，并發10，測試5秒：
[zhaoya@shit ~/test]$ webbench -c 10 -t 5 http://127.0.0.1:112/ Webbench - Simple Web Benchmark 1.5 Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.Benchmarking: GET http://127.0.0.1:112/ 10 clients, running 5 sec.而a.out的終端有以下輸出：
... get client:9690 get client:9688 get client:9691 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9693 get client:9692 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9689 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9697 get client:9691 get client:9696 get client:9690 get client:9690 get client:9695 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9697 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9689 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9692 get client:9696 get client:9688 get client:9695 get client:9693 get client:9689 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9691 get client:9695 get client:9691 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:9692 get client:9690 get client:9694 get client:9693 ...所有的“shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:”的行均是被epoll LT驚群不必要喚醒的進程打印的。
接下來用ET模式運行：
[zhaoya@shit ~/test]$ sudo ./a.out 1 112 0對應的輸出如下：
... get client:14462 get client:14462 get client:14464 get client:14464 get client:14462 get client:14462 get client:14467 get client:14469 get client:14468 get client:14468 get client:14464 get client:14467 get client:14467 get client:14469 get client:14469 get client:14469 get client:14464 get client:14464 get client:14466 get client:14466 get client:14469 get client:14469 ...沒有任何一行是shit，即沒有被不必要喚醒的驚群現象發生。
以上兩個case確認了epoll LT模式的驚群效應是可以通過改用ET模式來解決的，接下來我們確認ET模式非循環處理會丟失事件。
用ET模式運行a.out，這時將slp參數設置為1，即在epoll_wait返回和實際accept之間耽擱1秒，這樣可以讓一個epi在被加入到“就緒鏈表”中之后，在其被實際accept處理之前，積累更多的未決事件，即未處理的請求，而我們實驗的目的則是，epoll ET會丟失這些事件。
webbench的參數依然如故，a.out的輸出如下：
[zhaoya@shit ~/test]$ sudo ./a.out 1 114 1 server:1 pid:31161 server:2 pid:31162 server:3 pid:31163 server:4 pid:31164 server:5 pid:31165 server:6 pid:31166 server:7 pid:31167 server:8 pid:31168 server:9 pid:31169 server:10 pid:31170 get client:31170 get client:31170 get client:31167 get client:31169 get client:31166 get client:31165 get client:31170 get client:31167 get client:31169 get client:31165 get client:31168 get client:31170 get client:31167 get client:31165 get client:31169 get client:31170 get client:31167 get client:31169 get client:31170 get client:31167 get client:31169^Cpid:31170 count:6 pid:31169 count:5 pid:31163 count:0 pid:31168 count:1 pid:31167 count:5 pid:31165 count:3 pid:31166 count:1 pid:31161 count:0 pid:31162 count:0 pid:31164 count:0 User defined signal 1同樣的webbench參數，僅僅處理了十幾個請求，可見大多數都丟掉了。如果我們用LT模式，同樣在sleep 1秒導致事件擠壓的情況下，是不是會多處理一些呢？我們的預期應該是肯定的，因為LT模式在事件被處理完之前，會一直促使epoll_wait返回繼續處理，那么讓我們試一下：
[zhaoya@shit ~/test]$ sudo ./a.out 0 115 1 server:1 pid:363 server:2 pid:364 server:3 pid:365 server:4 pid:366 server:5 pid:367 server:6 pid:368 server:7 pid:369 server:8 pid:370 server:9 pid:371 server:10 pid:372 get client:372 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:371 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:365 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:366 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:363 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:367 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:369 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:364 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:368 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:370 get client:370 get client:364 get client:367 get client:368 get client:369 get client:365 get client:371 get client:372 get client:363 get client:366 get client:370 get client:367 get client:364 get client:369 get client:371 get client:368 get client:366 get client:363 get client:365 get client:372 get client:370 get client:367 get client:364 get client:371 get client:369 get client:366 get client:368 get client:363 get client:365 get client:372 get client:370 get client:367 get client:371 get client:364 get client:369 get client:366 get client:365 get client:368 get client:363 get client:372 get client:370 get client:364 get client:371 get client:367 get client:366 get client:369 get client:365 get client:363 get client:368 get client:372 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:371 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:370 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:364 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:367 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:366 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:369 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:365 shit xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:363 ^Cpid:363 count:5 pid:368 count:5 pid:372 count:6 pid:369 count:5 pid:366 count:5 pid:370 count:5 pid:367 count:5 pid:371 count:5 pid:365 count:5 pid:364 count:5 User defined signal 1是的，多處理了很多，但是出現了LT驚群，這也是意料之中的事。
最后，讓我們把這個Demo代碼小改一下，改成循環處理，依然采用ET模式，sleep 1秒，看看情況會怎樣。修改后的代碼如下：
void server(int epfd) {struct epoll_event *events;int num, i;struct timespec ts;events = calloc(64, sizeof(struct epoll_event));while (1) {int sd, csd;struct sockaddr in_addr;num = epoll_wait(epfd, events, 64, -1);if (num <= 0) {continue;}if (slp)sleep(slp);sd = events[0].data.fd;socklen_t in_len = sizeof(in_addr);// 這里循環處理，一直到空。while ((csd = accept(sd, &in_addr, &in_len)) > 0) {count ++;printf("get client:%d\n", getpid());close(csd);}} }改完代碼后，再做同樣參數的測試，結果大大不同：
[zhaoya@shit ~/test]$ sudo ./a.out 0 116 1 ... get client:3640 get client:3645 get client:3640 get client:3641 get client:3641 get client:3641 ^Cpid:3642 count:14 pid:3647 count:33531 pid:3646 count:21824 pid:3648 count:22 pid:3644 count:32219 pid:3645 count:94449 pid:3641 count:8 pid:3640 count:85385 pid:3643 count:13 pid:3639 count:10 User defined signal 1可以看到，大多數的請求都得到了處理，同樣的邏輯，epoll_wait返回后的循環讀和一次讀結果顯然不同。
問題和解決方案都很明確了，可以結單了嗎？我想是的，但是在終結這個話題之前，我還想說一些結論性的東西以供備忘和參考。
結論
曾經，為了實現并發服務器，出現了很多的所謂范式，比如下面的兩個很常見：
- 范式1：設置多個IP地址，多個IP地址同時偵聽相同的端口，前端用4層負載均衡或者反向代理來對這些IP地址進行請求分發；
- 范式2：Master進程創建一個Listen socket，然后fork出來N個worker進程，這N個worker進程同時偵聽這個socket。
第一個范式與本文講的epoll無關，更多的體現一種IP層的技術，這里不談，這里僅僅說一下第二個范式。
為了保證元組的唯一性以及處理的一致性，很長時間以來對于服務器而言，是不允許bind同一個IP地址和端口對的。然而為了可以并發處理多個連接請求，則必須采用某種多處理的方式，為了多個進程可以同時偵聽同一個IP地址端口對，便出現了create listener+fork這種模型，具體來講就是：
sd = create_listen_socket(); for (i = 0; i < N; i++) {if (fork() == 0) {// 繼承了父進程的文件描述符server(sd);} }然而這種模式僅僅是做到了進程級的可擴展性，即一個進程在忙時，其它進程可以介入幫忙處理，底層的socket句柄其實是同一個！簡單點說，這是一個沙漏模型：
這種模型在處理同一個socket的時候，必須互斥，同時內核必須防止潛在的驚群效應，因為互斥的要求，有且僅有一個進程可以處理特定的請求。這就對編程造成了極大的干擾。
以本文所描述的case為例，如果不清楚epoll LT模式和ET模式潛在的問題，那么就很容易誤用epoll導致比較令人頭疼的后果。
非常幸運，reuseport出現后，模型徹底變成了桶狀：
于是乎，使用了reuseport，一切都變得明朗了：
- 不再依賴mem模型
- 不再擔心驚群
為什么reuseport沒有驚群？首先我們要知道驚群發生的原因，就是同時喚醒了多個進程處理一個事件，導致了不必要的CPU空轉。為什么會喚醒多個進程，因為發生事件的文件描述符在多個進程之間是共享的。而reuseport呢，偵聽同一個IP地址端口對的多個socket本身在socket層就是相互隔離的，在它們之間的事件分發是TCP/IP協議棧完成的，所以不會再有驚群發生。
所以，結論是什么？
結論就是全部統一采用reuseport的方式吧，徹底解決驚群問題。
后記
浙江溫州皮鞋濕！
總結
以上是生活随笔為你收集整理的再谈Linux epoll惊群问题的原因和解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SQL Server 数据库之角色、管理
- 下一篇： 工具说明书 - 使用网页生成条码