讀緩衝區不爲空時, 讀事件觸發。
寫緩衝區不爲滿時, 寫事件觸發。
處理流程linux
accept新的鏈接, 監聽讀事件。
讀事件到達, 處理讀事件。
須要寫入數據, 向fd中寫數據, 一次沒法寫完, 開啓寫事件監聽。
寫事件到達, 繼續寫入數據, 寫完後關閉寫事件。
優缺點nginx
不會遺漏事件, 易編程。
長鏈接須要寫入的數據量大時, 會頻繁開啓關閉寫事件。redis
讀緩衝區狀態變化時, 讀事件觸發, 網卡接受到新數據。
寫緩衝區狀態變化時, 寫事件觸發, 網卡發出了新數據。
處理流程編程
accept新的鏈接, 同時監聽讀寫事件。
讀事件到達, 須要一直讀取數據, 直到返回EAGAIN。
寫事件到達, 無數據處理則不處理, 有數據待寫入則一直寫入,直到寫完或者返回EAGAIN。
優缺點緩存
不須要頻繁開啓關閉事件, 效率較高。
讀寫事件處理不當, 可能致使事件丟失, 編程教複雜。.net
對於讀事件而言,整體而言, 採用水平觸發方式較好。應用程序在讀取數據時,可能會一次沒法讀取所有數據,邊沿觸發在下一次可能不會觸發。若是可以保證一次讀取緩存的所有數據,能夠採用邊沿觸發,效率更高, 但同時編程複雜度也高。
對於寫事件,當客戶端服務端採用短鏈接或者採用長鏈接但發送的數據量比較少時(例如: Redis), 採用水平觸發便可。當客戶端與服務端是長鏈接而且數據寫入的量比較大時(例如: nginx), 採用邊沿觸發, 由於邊沿觸發效率更高。
目前,linux不支持讀寫事件分別設置不一樣的觸發方式,具體採用哪一種方式觸發,須要根據具體需求。
監聽套接字事件設置blog
監聽套接字不須要監聽寫事件,只須要監聽讀事件。
監聽套接字通常採用水平觸發方式。(nginx開啓multi_accept時,會把監聽套接字全部可讀的事件所有讀取,此時可使用邊沿觸發。但爲了保證鏈接不丟失,nginx仍然採用水平觸發)
通訊套接字設置事件
redis對於與客戶端通訊使用的套接字默認使用水平觸發。
nginx對於與客戶端通訊使用的套接字默認採用邊沿觸發。get