Linux IO 多路復用是什麽意思？
寫在前面：本文整理於知乎，原文鏈接為http://www.zhihu.com/question/32163005/answer/55772739，作者：羅誌宇
再次向作者表示感謝~~
假設你是一個機場的空管， 你須要管理到你機場的全部的航線。 包含進港，出港， 有些航班須要放到停機坪等待，有些航班須要去登機口接乘客。
你會怎麽做?
那麽問題就來了：
非常快你就發現空管塔裏面聚集起來一大票的空管員，交通略微繁忙一點，新的空管員就已經擠不進來了。
空管員之間須要協調，屋子裏面就1, 2個人的時候還好，幾十號人以後 。基本上就成菜市場了。
空管員常常須要更新一些公用的東西。比方起飛顯示屏，比方下一個小時後的出港排期。最後你會非常驚奇的發現，每個人的時間最後都花在了搶這些資源上。
現實上我們的空管同一時候管幾十架飛機稀松尋常的事情， 他們怎麽做的呢？
他們用這個東西
這個東西叫flight progress strip. 每個塊代表一個航班，不同的槽代表不同的狀態，然後一個空管員能夠管理一組這種塊（一組航班），而他的工作。就是在航班信息有新的更新的時候。把相應的塊放到不同的槽子裏面。
這個東西如今還沒有淘汰哦，僅僅是變成電子的了而已。
。
是不是認為一下子效率高了非常多，一個空管塔裏能夠調度的航線能夠是前一種方法的幾倍到幾十倍。
假設你把每個航線當成一個Sock(I/O 流), 空管當成你的服務端Sock管理代碼的話.
第一種方法就是最傳統的多進程並發模型 (每進來一個新的I/O流會分配一個新的進程管理。)
另外一種方法就是I/O多路復用 (單個線程，通過記錄跟蹤每個I/O流(sock)的狀態，來同一時候管理多個I/O流 。
)
事實上“I/O多路復用”這個坑爹翻譯可能是這個概念在中文裏面如此難理解的原因。所謂的I/O多路復用在英文中事實上叫 I/O multiplexing. 假設你搜索multiplexing啥意思，基本上都會出這個圖：
於是大部分人都直接聯想到”一根網線。多個sock復用” 這個概念，包含上面的幾個回答。 事實上無論你用多進程還是I/O多路復用。 網線都僅僅有一根好伐。多個Sock復用一根網線這個功能是在內核＋驅動層實現的。
重要的事情再說一遍： I/O multiplexing 這裏面的 multiplexing 指的事實上是在單個線程通過記錄跟蹤每個Sock(I/O流)的狀態(相應空管塔裏面的Fight progress strip槽)來同一時候管理多個I/O流. 發明它的原因，是盡量多的提高server的吞吐能力。
是不是聽起來好拗口，看個圖就懂了.
在同一個線程裏面， 通過撥開關的方式。來同一時候傳輸多個I/O流。 (學過EE的人如今能夠站出來義正嚴辭說這個叫“時分復用”了）。
什麽，你還沒有搞懂“一個請求到來了，nginx使用epoll接收請求的過程是如何的”。 多看看這個圖就了解了。
提醒下，ngnix會有非常多鏈接進來， epoll會把他們都監視起來，然後像撥開關一樣。誰有數據就撥向誰。然後調用相應的代碼處理。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
了解這個主要的概念以後，其它的就非常好解釋了。
select, poll, epoll 都是I/O多路復用的詳細的實現。之所以有這三個鬼存在，事實上是他們出現是有先後順序的。
I/O多路復用這個概念被提出來以後。 select是第一個實現 (1983 左右在BSD裏面實現的)。
select 被實現以後，非常快就暴露出了非常多問題。
select 會改動傳入的參數數組。這個對於一個須要調用非常多次的函數，是非常不友好的。
select 假設不論什麽一個sock(I/O stream)出現了數據，select 僅僅會返回，但是並不會告訴你是那個sock上有數據，於是你僅僅能自己一個一個的找，10幾個sock可能還好。要是幾萬的sock每次都找一遍，這個無謂的開銷就頗有海天盛筵的豪氣了。
select 僅僅能監視1024個鏈接。 這個跟草榴沒啥關系哦。linux 定義在頭文件裏的，參見FD_SETSIZE。
select 不是線程安全的，假設你把一個sock增加到select, 然後突然另外一個線程發現。尼瑪。這個sock不用。要收回。對不起。這個select 不支持的，假設你喪心病狂的居然關掉這個sock, select的標準行為是。。
呃。。不可預測的， 這個但是寫在文檔中的哦.
“If a file descriptor being monitored by select() is closed in another thread, the result is unspecified”
霸不霸氣
於是14年以後(1997年）一幫人又實現了poll, poll 修復了select的非常多問題，比方
poll 去掉了1024個鏈接的限制，於是要多少鏈接呢， 主人你開心就好。
poll 從設計上來說。不再改動傳入數組，只是這個要看你的平臺了，所以行走江湖。還是小心為妙。
事實上拖14年那麽久也不是效率問題， 而是那個時代的硬件實在太弱，一臺server處理1千多個鏈接簡直就是神一樣的存在了，select非常長段時間已經滿足需求。
但是poll仍然不是線程安全的， 這就意味著，無論server有多強悍。你也僅僅能在一個線程裏面處理一組I/O流。你當然能夠那多進程來配合了，只是然後你就有了多進程的各種問題。
於是5年以後, 在2002, 大神 Davide Libenzi 實現了epoll.
epoll 能夠說是I/O 多路復用最新的一個實現，epoll 修復了poll 和select絕大部分問題, 比方：
epoll 如今是線程安全的。
epoll 如今不僅告訴你sock組裏面數據，還會告訴你詳細哪個sock有數據，你不用自己去找了。
epoll 當年的patch，如今還在，以下鏈接能夠看得到：
/dev/epoll Home Page
貼一張霸氣的圖。看看當年神一樣的性能（測試代碼都是死鏈了。 假設有人能夠刨墳找出來。能夠研究下細節怎麽測的).
橫軸Dead connections 就是鏈接數的意思。叫這個名字僅僅是它的測試工具叫deadcon. 縱軸是每秒處理請求的數量，你能夠看到。epoll每秒處理請求的數量基本不會隨著鏈接變多而下降的。poll 和/dev/poll 就非常慘了。
但是epoll 有個致命的缺點。
。僅僅有linux支持。
比方BSD上面相應的實現是kqueue。
事實上有些國內知名廠商把epoll從安卓裏面裁掉這種腦殘的事情我會主動告訴你嘛。
什麽，你說沒人用安卓做server。尼瑪你是看不起p2p軟件了啦。
而ngnix 的設計原則裏面， 它會使用目標平臺上面最高效的I/O多路復用模型咯，所以才會有這個設置。普通情況下，假設可能的話，盡量都用epoll/kqueue吧。
詳細的在這裏:
Connection processing methods
PS: 上面全部這些比較分析。都建立在大並發以下。假設你的並發數太少，用哪個，事實上都沒有差別。
假設像是在歐朋數據中心裏面的轉碼server那種動不動就是幾萬幾十萬的並發，不用epoll我能夠直接去撞墻了。
作者：羅誌宇
鏈接：http://www.zhihu.com/question/32163005/answer/55772739
來源：知乎
著作權歸作者全部。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
Linux IO 多路復用是什麽意思？