摘要：一基礎水平觸發基本概念讀緩沖區不為空時讀事件觸發。開啟時，會把監聽套接字所有可讀的事件全部讀取，此時可以使用邊沿觸發。但為了保證連接不丟失，仍然采用水平觸發通信套接字設置對于與客戶端通信使用的套接字默認使用水平觸發。

讀緩沖區不為空時, 讀事件觸發。
寫緩沖區不為滿時, 寫事件觸發。
處理流程

accept新的連接, 監聽讀事件。
讀事件到達, 處理讀事件。
需要寫入數據, 向fd中寫數據, 一次無法寫完, 開啟寫事件監聽。
寫事件到達, 繼續寫入數據, 寫完后關閉寫事件。
優缺點

不會遺漏事件, 易編程。
長連接需要寫入的數據量大時, 會頻繁開啟關閉寫事件。

讀緩沖區狀態變化時, 讀事件觸發, 網卡接受到新數據。
寫緩沖區狀態變化時, 寫事件觸發, 網卡發出了新數據。
處理流程

accept新的連接, 同時監聽讀寫事件。
讀事件到達, 需要一直讀取數據, 直到返回EAGAIN。
寫事件到達, 無數據處理則不處理, 有數據待寫入則一直寫入，直到寫完或者返回EAGAIN。
優缺點

不需要頻繁開啟關閉事件, 效率較高。
讀寫事件處理不當, 可能導致事件丟失, 編程教復雜。

對于讀事件而言，總體而言, 采用水平觸發方式較好。應用程序在讀取數據時，可能會一次無法讀取全部數據，邊沿觸發在下一次可能不會觸發。如果能夠保證一次讀取緩存的全部數據，可以采用邊沿觸發，效率更高, 但同時編程復雜度也高。
對于寫事件，當客戶端服務端采用短連接或者采用長連接但發送的數據量比較少時(例如: Redis), 采用水平觸發即可。當客戶端與服務端是長連接并且數據寫入的量比較大時(例如: nginx), 采用邊沿觸發, 因為邊沿觸發效率更高。
目前，linux不支持讀寫事件分別設置不同的觸發方式，具體采用哪種方式觸發，需要根據具體需求。
監聽套接字事件設置

監聽套接字不需要監聽寫事件，只需要監聽讀事件。
監聽套接字一般采用水平觸發方式。(nginx開啟multi_accept時，會把監聽套接字所有可讀的事件全部讀取，此時可以使用邊沿觸發。但為了保證連接不丟失，nginx仍然采用水平觸發)
通信套接字設置

redis對于與客戶端通信使用的套接字默認使用水平觸發。
nginx對于與客戶端通信使用的套接字默認采用邊沿觸發。

https://blog.csdn.net/dongfuy...