深入理解Linux IO复用之epoll
?
作者：后端技術指南針 來自：后端技術指南針
0.概述
通過本篇文章將了解到以下內容:
I/O復用的定義和產生背景Linux系統的I/O復用工具epoll設計的基本構成epoll高性能的底層實現epoll的ET模式和LT模式
1.復用技術和I/O復用
復用的概念復用技術(multiplexing)并不是新技術而是一種設計思想，在通信和硬件設計中存在頻分復用、時分復用、波分復用、碼分復用等，在日常生活中復用的場景也非常多，因此不要被專業(yè)術語所迷惑。
從本質上來說，復用就是為了解決有限資源和過多使用者的不平衡問題，且此技術的理論基礎是資源的可釋放性。
資源的可釋放性舉個實際生活的例子：
不可釋放場景：ICU病房的呼吸機作為有限資源，病人一旦占用且在未脫離危險之前是無法放棄占用的，因此不可能幾個情況一樣的病人輪流使用。
可釋放場景：對于一些其他資源比如醫(yī)護人員就可以實現對多個病人的同時監(jiān)護，理論上不存在一個病人占用醫(yī)護人員資源不釋放的場景。
理解IO復用I/O的含義：在計算機領域常說的IO包括磁盤IO和網絡IO，我們所說的IO復用主要是指網絡IO，在Linux中一切皆文件，因此網絡IO也經常用文件描述符FD來表示。
復用的含義：那么這些文件描述符FD要復用什么呢？在網絡場景中復用的就是任務處理線程，所以簡單理解就是多個IO共用1個線程。
IO復用的可行性：IO請求的基本操作包括read和write，由于網絡交互的本質性，必然存在等待，換言之就是整個網絡連接中FD的讀寫是交替出現的，時而可讀可寫，時而空閑，所以IO復用是可用實現的。
綜上認為，IO復用技術就是協調多個可釋放資源的FD交替共享任務處理線程完成通信任務，實現多個fd對應1個任務處理線程。
現實生活中IO復用就像一只邊牧管理幾百只綿羊一樣：
?
IO復用的設計原則和產生背景高效IO復用機制要滿足：協調者消耗最少的系統資源、最小化FD的等待時間、最大化FD的數量、任務處理線程最少的空閑、多快好省完成任務等。
在網絡并發(fā)量非常小的原始時期，即使per req per process地處理網絡請求也可以滿足要求，但是隨著網絡并發(fā)量的提高，原始方式必將阻礙進步，所以就刺激了IO復用機制的實現和推廣。
2.Linux中IO復用工具
在Linux中先后出現了select、poll、epoll等，FreeBSD的kqueue也是非常優(yōu)秀的IO復用工具，kqueue的原理和epoll很類似，本文以Linux環(huán)境為例，并且不討論過多select和poll的實現機制和細節(jié)。
開拓者selectselect大約是2000年初出現的，其對外的接口定義：
?
作為第一個IO復用系統調用，select使用一個宏定義函數按照bitmap原理填充fd，默認大小是1024個，因此對于fd的數值大于1024都可能出現問題，看下官方預警:
?
也就是說當fd的數值大于1024時在將不可控，官方不建議超過1024，但是我們也無法控制fd的絕對數值大小，之前針對這個問題做過一些調研，結論是系統對于fd的分配有自己的策略，會大概率分配到1024以內，對此我并沒有充分理解，只是提及一下這個坑。
存在的問題:
可協調fd數量和數值都不超過1024 無法實現高并發(fā)使用O(n)復雜度遍歷fd數組查看fd的可讀寫性 效率低涉及大量kernel和用戶態(tài)拷貝 消耗大每次完成監(jiān)控需要再次重新傳入并且分事件傳入 操作冗余綜上可知，select以樸素的方式實現了IO復用，將并發(fā)量提高的最大K級，但是對于完成這個任務的代價和靈活性都有待提高。無論怎么樣select作為先驅對IO復用有巨大的推動，并且指明了后續(xù)的優(yōu)化方向，不要無知地指責select。
繼承者epollepoll最初在2.5.44內核版本出現，后續(xù)在2.6.x版本中對代碼進行了優(yōu)化使其更加簡潔，先后面對外界的質疑在后續(xù)增加了一些設置來解決隱藏的問題，所以epoll也已經有十幾年的歷史了。
在《Unix網絡編程》第三版(2003年)還沒有介紹epoll，因為那個時代epoll還沒有出現，書中只介紹了select和poll，epoll對select中存在的問題都逐一解決，簡單來說epoll的優(yōu)勢包括：
對fd數量沒有限制(當然這個在poll也被解決了)拋棄了bitmap數組實現了新的結構來存儲多種事件類型無需重復拷貝fd 隨用隨加 隨棄隨刪采用事件驅動避免輪詢查看可讀寫事件綜上可知，epoll出現之后大大提高了并發(fā)量對于C10K問題輕松應對，即使后續(xù)出現了真正的異步IO，也并沒有(暫時沒有)撼動epoll的江湖地位，主要是因為epoll可以解決數萬數十萬的并發(fā)量，已經可以解決現在大部分的場景了，異步IO固然優(yōu)異，但是編程難度比epoll更大，權衡之下epoll仍然富有生命力。
3.epoll的基本實現
epoll的api定義：
?
epoll_create是在內核區(qū)創(chuàng)建一個epoll相關的一些列結構，并且將一個句柄fd返回給用戶態(tài)，后續(xù)的操作都是基于此fd的，參數size是告訴內核這個結構的元素的大小，類似于stl的vector動態(tài)數組，如果size不合適會涉及復制擴容，不過貌似4.1.2內核之后size已經沒有太大用途了；epoll_ctl是將fd添加/刪除于epoll_create返回的epfd中，其中epoll_event是用戶態(tài)和內核態(tài)交互的結構，定義了用戶態(tài)關心的事件類型和觸發(fā)時數據的載體epoll_data；epoll_wait是阻塞等待內核返回的可讀寫事件，epfd還是epoll_create的返回值，events是個結構體數組指針存儲epoll_event，也就是將內核返回的待處理epoll_event結構都存儲下來，maxevents告訴內核本次返回的最大fd數量，這個和events指向的數組是相關的；epoll_event是用戶態(tài)需監(jiān)控fd的代言人，后續(xù)用戶程序對fd的操作都是基于此結構的；
通俗描述：可能上面的描述有些抽象，不過其實很好理解，舉個現實中的例子：
epoll_create場景：大學開學第一周，你作為班長需要幫全班同學領取相關物品，你在學生處告訴工作人員，我是xx學院xx專業(yè)xx班的班長，這時工作人員確定你的身份并且給了你憑證，后面辦的事情都需要用到(也就是調用epoll_create向內核申請了epfd結構，內核返回了epfd句柄給你使用)；epoll_ctl場景：你拿著憑證在辦事大廳開始辦事，分揀辦公室工作人員說班長你把所有需要辦理事情的同學的學生冊和需要辦理的事情都記錄下來吧，于是班長開始在每個學生手冊單獨寫對應需要辦的事情：李明需要開實驗室權限、孫大熊需要辦游泳卡......就這樣班長一股腦寫完并交給了工作人員(也就是告訴內核哪些fd需要做哪些操作)；epoll_wait場景：你拿著憑證在領取辦公室門前等著，這時候廣播喊xx班長你們班孫大熊的游泳卡辦好了速來領取、李明實驗室權限卡辦好了速來取....還有同學的事情沒辦好，所以班長只能繼續(xù)(也就是調用epoll_wait等待內核反饋的可讀寫事件發(fā)生并處理)；官方DEMO通過man epoll可以看到官方的demo：
?
?
?
?
?
在epoll_wait時需要區(qū)分是主監(jiān)聽線程fd的新連接事件還是已連接事件的讀寫請求，進而單獨處理。
4.epoll的底層實現
epoll底層實現最重要的兩個數據結構:epitem和eventpoll。
可以簡單的認為epitem是和每個用戶態(tài)監(jiān)控IO的fd對應的,eventpoll是用戶態(tài)創(chuàng)建的管理所有被監(jiān)控fd的結構，詳細的定義如下：
?
?
?
底層調用過程epoll_create會創(chuàng)建一個類型為struct eventpoll的對象，并返回一個與之對應文件描述符，之后應用程序在用戶態(tài)使用epoll的時候都將依靠這個文件描述符，而在epoll內部也是通過該文件描述符進一步獲取到eventpoll類型對象，再進行對應的操作，完成了用戶態(tài)和內核態(tài)的貫穿。
epoll_ctl底層主要調用epoll_insert實現操作:
創(chuàng)建并初始化一個strut epitem類型的對象，完成該對象和被監(jiān)控事件以及epoll對象eventpoll的關聯;將struct epitem類型的對象加入到epoll對象eventpoll的紅黑樹中管理起來;將struct epitem類型的對象加入到被監(jiān)控事件對應的目標文件的等待列表中，并注冊事件就緒時會調用的回調函數，在epoll中該回調函數就是ep_poll_callback();ovflist主要是暫態(tài)處理，比如調用ep_poll_callback()回調函數的時候發(fā)現eventpoll的ovflist成員不等于EP_UNACTIVE_PTR，說明正在掃描rdllist鏈表，這時將就緒事件對應的epitem加入到ovflist鏈表暫存起來，等rdllist鏈表掃描完再將ovflist鏈表中的元素移動到rdllist鏈表中；如圖展示了紅黑樹、雙鏈表、epitem之間的關系:
?
注:rbr表示rb_root，rbn表示rb_node 上文給出了其在內核中的定義
epoll_wait的數據拷貝常見錯誤觀點:epoll_wait返回時，對于就緒的事件，epoll使用的是共享內存的方式，即用戶態(tài)和內核態(tài)都指向了就緒鏈表，所以就避免了內存拷貝消耗網上抄來抄去的觀點
關于epoll_wait使用共享內存的方式來加速用戶態(tài)和內核態(tài)的數據交互，避免內存拷貝的觀點，并沒有得到2.6內核版本代碼的證實，并且關于這次拷貝的實現是這樣的：
?
5.ET模式和LT模式
簡單理解默認采用LT模式，LT支持阻塞和非阻塞套，ET模式只支持非阻塞套接字，其效率要高于LT模式，并且LT模式更加安全。
LT和ET模式下都可以通過epoll_wait方法來獲取事件，LT模式下將事件拷貝給用戶程序之后，如果沒有被處理或者未處理完，那么在下次調用時還會反饋給用戶程序，可以認為數據不會丟失會反復提醒；
ET模式下如果沒有被處理或者未處理完，那么下次將不再通知到用戶程序，因此避免了反復被提醒，卻加強了對用戶程序讀寫的要求；
深入理解上面的簡單理解在網上隨便找一篇都會講到，但是LT和ET真正使用起來，還是存在一定難度的。
LT的讀寫操作LT對于read操作比較簡單，有read事件就讀，讀多讀少都沒有問題，但是write就不那么容易了，一般來說socket在空閑狀態(tài)時發(fā)送緩沖區(qū)一定是不滿的，假如fd一直在監(jiān)控中，那么會一直通知寫事件，不勝其煩。
所以必須保證沒有數據要發(fā)送的時候，要把fd的寫事件監(jiān)控從epoll列表中刪除，需要的時候再加入回去，如此反復。
天下沒有免費的午餐，總是無代價地提醒是不可能的，對應write的過度提醒，需要使用者隨用隨加，否則將一直被提醒可寫事件。
ET的讀寫操作fd可讀則返回可讀事件，若開發(fā)者沒有把所有數據讀取完畢，epoll不會再次通知read事件，也就是說如果沒有全部讀取所有數據，那么導致epoll不會再通知該socket的read事件，事實上一直讀完很容易做到。
若發(fā)送緩沖區(qū)未滿，epoll通知write事件，直到開發(fā)者填滿發(fā)送緩沖區(qū)，epoll才會在下次發(fā)送緩沖區(qū)由滿變成未滿時通知write事件。
ET模式下只有socket的狀態(tài)發(fā)生變化時才會通知，也就是讀取緩沖區(qū)由無數據到有數據時通知read事件，發(fā)送緩沖區(qū)由滿變成未滿通知write事件。
一道面試題
使用Linux epoll模型的LT水平觸發(fā)模式，當socket可寫時，會不停的觸發(fā)socket可寫的事件，如何處理？網絡流傳的騰訊面試題
這道題目對LT和ET考察比較深入，驗證了前文說的LT模式write問題。
普通做法：
當需要向socket寫數據時，將該socket加入到epoll等待可寫事件。接收到socket可寫事件后，調用write()或send()發(fā)送數據，當數據全部寫完后， 將socket描述符移出epoll列表，這種做法需要反復添加和刪除。
改進做法:
向socket寫數據時直接調用send()發(fā)送，當send()返回錯誤碼EAGAIN，才將socket加入到epoll，等待可寫事件后再發(fā)送數據，全部數據發(fā)送完畢，再移出epoll模型，改進的做法相當于認為socket在大部分時候是可寫的，不能寫了再讓epoll幫忙監(jiān)控。
上面兩種做法是對LT模式下write事件頻繁通知的修復，本質上ET模式就可以直接搞定，并不需要用戶層程序的補丁操作。
ET模式的線程饑餓問題如果某個socket源源不斷地收到非常多的數據，在試圖讀取完所有數據的過程中，有可能會造成其他的socket得不到處理，從而造成饑餓問題。
解決辦法：為每個已經準備好的描述符維護一個隊列，這樣程序就可以知道哪些描述符已經準備好了但是并沒有被讀取完，然后程序定時或定量的讀取，如果讀完則移除，直到隊列為空，這樣就保證了每個fd都被讀到并且不會丟失數據，流程如圖:
?
EPOLLONESHOT設置A線程讀完某socket上數據后開始處理這些數據，此時該socket上又有新數據可讀，B線程被喚醒讀新的數據，造成2個線程同時操作一個socket的局面 ，EPOLLONESHOT保證一個socket連接在任一時刻只被一個線程處理。
兩種模式的選擇通過前面的對比可以看到LT模式比較安全并且代碼編寫也更清晰，但是ET模式屬于高速模式，在處理大高并發(fā)場景使用得當效果更好，具體選擇什么根據自己實際需要和團隊代碼能力來選擇，如果并發(fā)很高且團隊水平較高可以選擇ET模式，否則建議LT模式。
6.epoll的驚群問題
在2.6.18內核中accept的驚群問題已經被解決了，但是在epoll中仍然存在驚群問題，表現起來就是當多個進程/線程調用epoll_wait時會阻塞等待，當內核觸發(fā)可讀寫事件，所有進程/線程都會進行響應，但是實際上只有一個進程/線程真實處理這些事件。
在epoll官方沒有正式修復這個問題之前，Nginx作為知名使用者采用全局鎖來限制每次可監(jiān)聽fd的進程數量，每次只有1個可監(jiān)聽的進程，后來在Linux 3.9內核中增加了SO_REUSEPORT選項實現了內核級的負載均衡，Nginx1.9.1版本支持了reuseport這個新特性，從而解決驚群問題。
EPOLLEXCLUSIVE是在2016年Linux 4.5內核新添加的一個 epoll 的標識，Ngnix 在 1.11.3 之后添加了NGX_EXCLUSIVE_EVENT選項對該特性進行支持。EPOLLEXCLUSIVE標識會保證一個事件發(fā)生時候只有一個線程會被喚醒，以避免多偵聽下的驚群問題。
總結
以上是生活随笔為你收集整理的深入理解Linux IO复用之epoll的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ElasticSearch查询 基础篇
- 下一篇： linux 其他常用命令