㈠ epoll使用實例：TCP服務端處理多個客戶端請求
epoll的全稱是eventpoll，是linux內核實現IO多路復用的一種高效方式。相較於select和poll，epoll改進了工作方式，提高了效率。在本篇文章中，我們將基於上一篇文章中的Unix域socket通信實例，學習如何在TCP服務端使用epoll實現對多個客戶端請求的處理。
在epoll中，服務端可以通過創建一個epoll實例，並將監聽fd加入該實例，從而實現監聽功能。事件設置時，通過epoll_event結構體，可以配置事件類型，如讀、寫或異常。監聽事件由epoll_wait函數觸發，該函數等待事件產生，並返回處理事件的數量。
下面是一個基於上篇Unix域socket通信代碼修改的TCP服務端實例。原先的服務端僅處理單個客戶端連接，現在修改為服務端能夠接收並處理多個客戶端的數據。
首先，服務端代碼需要增加epoll監聽功能。在listen之後，創建epoll實例，將服務端socket加入監聽。這樣服務端就可以監聽多個客戶端的連接請求。
為驗證epoll功能，編寫主程序以啟動多個客戶端線程，與服務端建立連接。此處使用了3個客戶端進行測試。
在Ubuntu環境下編譯運行程序，服務端將依次接受客戶端的連接請求，並接收客戶端發送的數據。測試結果表明，服務端成功處理了多個客戶端請求。
總結，通過本篇的學習，了解了epoll在Linux軟體開發中的應用，特別是其在TCP服務端實現多路復用功能的優越性。通過簡單的代碼修改，服務端能夠高效地處理多個客戶端的並發請求。
㈡ Handler消息機制（一）：Linux的epoll機制
在linux 沒有實現epoll事件驅動機制之前，我們一般選擇用select或者poll等IO多路復用的方法來實現並發服務程序。在linux新的內核中，有了一種替換它的機制，就是epoll。
相比select模型， poll使用鏈表保存文件描述符，因此沒有了監視文件數量的限制 ，但其他三個缺點依然存在。
假設我們的伺服器需要支持100萬的並發連接，則在__FD_SETSIZE 為1024的情況下，則我們至少需要開辟1k個進程才能實現100萬的並發連接。除了進程間上下文切換的時間消耗外，從內核/用戶空間大量的無腦內存拷貝、數組輪詢等，是系統難以承受的。因此，基於select模型的伺服器程序，要達到10萬級別的並發訪問，是一個很難完成的任務。
由於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萬個連接的句柄數據，內核也不需要去遍歷全部的連接。
當某一進程調用epoll_create方法時，Linux內核會創建一個eventpoll結構體，這個結構體中有兩個成員與epoll的使用方式密切相關。eventpoll結構體如下所示：
每一個epoll對象都有一個獨立的eventpoll結構體，用於存放通過epoll_ctl方法向epoll對象中添加進來的事件。這些事件都會掛載在紅黑樹中，如此，重復添加的事件就可以通過紅黑樹而高效的識別出來(紅黑樹的插入時間效率是lgn，其中n為樹的高度)。
而所有 添加到epoll中的事件都會與設備(網卡)驅動程序建立回調關系，也就是說，當相應的事件發生時會調用這個回調方法 。這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。
在epoll中，對於每一個事件，都會建立一個epitem結構體，如下所示：
當調用epoll_wait檢查是否有事件發生時，只需要檢查eventpoll對象中的rdlist雙鏈表中是否有epitem元素即可。如果rdlist不為空，則把發生的事件復制到用戶態，同時將事件數量返回給用戶。
epoll結構示意圖
通過紅黑樹和雙鏈表數據結構，並結合回調機制，造就了epoll的高效。
events可以是以下幾個宏的集合：
EPOLLIN：觸發該事件，表示對應的文件描述符上有可讀數據。(包括對端SOCKET正常關閉)；
EPOLLOUT：觸發該事件，表示對應的文件描述符上可以寫數據；
EPOLLPRI：表示對應的文件描述符有緊急的數據可讀（這里應該表示有帶外數據到來）；
EPOLLERR：表示對應的文件描述符發生錯誤；
EPOLLHUP： 表示對應的文件描述符被掛斷；
EPOLLET：將EPOLL設為邊緣觸發(EdgeTriggered)模式，這是相對於水平觸發(Level Triggered)來說的。
EPOLLONESHOT： 只監聽一次事件，當監聽完這次事件之後，如果還需要繼續監聽這個socket的話，需要再次把這個socket加入到EPOLL隊列里。
示例：
ET(EdgeTriggered) :高速工作模式，只支持no_block(非阻塞模式)。在此模式下，當描述符從未就緒變為就緒時，內核通過epoll告知。然後它會假設用戶知道文件描述符已經就緒，並且不會再為那個文件描述符發送更多的就緒通知，直到某些操作導致那個文件描述符不再為就緒狀態了。(觸發模式只在數據就緒時通知一次，若數據沒有讀完，下一次不會通知，直到有新的就緒數據)
LT(LevelTriggered) :預設工作方式，支持blocksocket和no_blocksocket。在LT模式下內核會告知一個文件描述符是否就緒了，然後可以對這個就緒的fd進行IO操作。如果不作任何操作，內核還是會繼續通知！若數據沒有讀完，內核也會繼續通知，直至設備數據為空為止！
1.我們已經把一個用來從管道中讀取數據的文件句柄(RFD)添加到epoll描述符
2. 這個時候從管道的另一端被寫入了2KB的數據
3. 調用epoll_wait(2)，並且它會返回RFD，說明它已經准備好讀取操作
4. 然後我們讀取了1KB的數據
5. 調用epoll_wait(2)……
ET工作模式：
如果我們在第1步將RFD添加到epoll描述符的時候使用了EPOLLET標志，在第2步執行了一個寫操作，第三步epoll_wait會返回同時通知的事件會銷毀。因為第4步的讀取操作沒有讀空文件輸入緩沖區內的數據，因此我們在第5步調用epoll_wait(2)完成後，是否掛起是不確定的。epoll工作在ET模式的時候，必須使用非阻塞套介面，以避免由於一個文件句柄的阻塞讀/阻塞寫操作把處理多個文件描述符的任務餓死。
只有當read(2)或者write(2)返回EAGAIN時(認為讀完)才需要掛起，等待。但這並不是說每次read()時都需要循環讀，直到讀到產生一個EAGAIN才認為此次事件處理完成，當read()返回的讀到的數據長度小於請求的數據長度時(即小於sizeof(buf))，就可以確定此時緩沖中已沒有數據了，也就可以認為此事讀事件已處理完成。
LT工作模式：
LT方式調用epoll介面的時候，它就相當於一個速度比較快的poll(2)，並且無論後面的數據是否被使用，因此他們具有同樣的職能。
當調用 epoll_wait檢查是否有發生事件的連接時，只是檢查 eventpoll對象中的 rdllist雙向鏈表是否有 epitem元素而已，如果 rdllist鏈表不為空，則把這里的事件復制到用戶態內存中，同時將事件數量返回給用戶。因此，epoll_wait的效率非常高。epoll_ctl在向 epoll對象中添加、修改、刪除事件時，從 rbr紅黑樹中查找事件也非常快，也就是說，epoll是非常高效的，它可以輕易地處理百萬級別的並發連接。
1.減少用戶態和內核態之間的文件句柄拷貝；
2.減少對可讀可寫文件句柄的遍歷。
https://cloud.tencent.com/developer/information/linux%20epoll%E6%9C%BA%E5%88%B6
https://blog.csdn.net/u010657219/article/details/44061629
https://jiahao..com/s?id=1609322251459722004&wfr=spider&for=pc
㈢ Linux內核源碼解析---EPOLL實現3之epoll_wait水平觸發與邊緣觸發
深入分析 Linux 內核源碼中的 EPOLL 實現，本文聚焦於關鍵函數 epoll_wait。核心邏輯在 eventpoll.c 文件中實現。
EPOLL_WAIT 方法通過轉移數據，具體步驟如下：首先，從准備好的鏈表中依次找到 epitem，並將其與新建的 txlink 連接起來，隨後返回已准備的事件數量。
接著，將 txlist 鏈表中的已掛載事件集合轉移到用戶指定的 events 中。默認情況下，用戶傳入的事件通常會帶上 POLLERR 和 POLLHUP 標志。
在完成事件轉移後，對 epoll_wait 方法的分析轉向 ep_send_events。此階段，epoll 利用 txlist 鏈表進行操作，根據觸發模式決定後續行為。在水平觸發模式下，epitem 需要被重新加入 rdllist，此模式正是 Java 中的 selector 所採用的。
水平觸發模式的優勢在於，當用戶未完全處理讀或寫事件時，epoll 會再次通知用戶，便於持續監控。例如，netty 的 NIO 產品通常使用 remove 標記清除讀/寫狀態，確保事件僅被處理一次。
綜上所述，epoll_wait 的功能在於等待事件的發生，通過高效地管理事件並觸發用戶回調，確保系統在多任務環境下保持穩定運行。這一機制簡化了並發編程的復雜性，提高了系統整體性能。
㈣ linux下 C++ 使用 epoll 實現高性能的tcpserver
實現高性能的TCP伺服器時，Linux系統提供了多種多路復用技術，如select、poll、epoll等。雖然每種技術都有其特點和適用場景，但epoll在高並發場景下性能最優，這也使得它在眾多伺服器軟體中被廣泛應用，如著名的Nginx。本文將聚焦於如何使用epoll來構建一個高性能的TCP伺服器，旨在提供一個易於理解的指南，幫助讀者掌握epoll的使用方法，而無需深入探討其底層原理。
首先，需要明確的是，epoll是Linux內核提供的系統調用功能，因此，它在Windows系統上不可用。如果讀者對在Windows中實現類似功能感興趣，歡迎分享相關經驗。
為了實現TCP伺服器，我們需要使用epoll提供的三個關鍵函數。同時，需要准備了解epoll的兩種事件模型：Level Triggered (LT) 和 Edge Triggered (ET)。在設置socket為非阻塞模式時，可以通過以下步驟操作：
c
int flags = fcntl(fd, F_GETFL, 0);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);
在編寫代碼前，請確保引入相應的頭文件。
接著，我們需要簡要了解epoll的工作原理。雖然本文不涉及過深的底層技術，但可以通過示意圖來直觀理解epoll的工作流程。epoll可以被視為操作系統提供的一個事件管理容器，通過將自定義的事件結構體（epoll_event）添加到容器中，用戶可以指定要監聽的事件類型。當容器檢測到特定事件發生時，epoll會通過epoll_wait()函數通知用戶。
對於簡單的epoll實現，我們發現即使未注冊可寫事件，直接向socket中寫入數據也是可行的。這表明在某些情況下，無需在epoll中進行復雜的事件注冊。
為了驗證這一行為，我們參考了相關資料，並對結果進行了總結。另外，我們還提供了一個面向對象封裝的epoll tcpserver 示例代碼，該代碼已上傳至GitHub和碼雲，供讀者進一步研究和使用。
最後，為了簡化文章的閱讀體驗，本文提供了一個簡潔的示例代碼，展示了如何使用epoll和C/C++語言實現一個簡單的TCP伺服器。代碼示例包含基本的網路連接、事件監聽以及數據處理邏輯，為讀者提供了實際操作的參考。