目錄

• 一 IO操作本質
• 二 IO模型
  • BIO – 阻塞模式I/O
  • NIO – 非阻塞模式I/O
  • IO Multiplexing - I/O多路複用模型
  • AIO – 非同步I/O模型
  • select poll 和epoll
• 三 同步I/O與非同步I/O
• 四 併發-並行-同步-非同步-阻塞-非阻塞
• 五 IO設計模式
  • Reactor模式
  • Proactor模式
  • 對比分析

一 IO操作本質

資料複製的過程中不會消耗CPU

# 1 記憶體分為核心緩衝區和使用者緩衝區
# 2 使用者的應用程式不能直接操作核心緩衝區，需要將資料從核心拷貝到使用者才能使用
# 3 而IO操作、網路請求載入到記憶體的資料一開始是放在核心緩衝區的

二 IO模型

BIO – 阻塞模式I/O

使用者程序從發起請求，到最終拿到資料前，一直掛起等待； 資料會由使用者程序完成拷貝

'''
舉個例子：一個人去 商店買一把菜刀，
他到商店問老闆有沒有菜刀（發起系統呼叫）
如果有（表示在核心緩衝區有需要的資料）
老闆直接把菜刀給買家（從核心緩衝區拷貝到使用者緩衝區）
這個過程買家一直在等待

如果沒有，商店老闆會向工廠下訂單（IO操作，等待資料準備好）
工廠把菜刀運給老闆（進入到核心緩衝區）
老闆把菜刀給買家（從核心緩衝區拷貝到使用者緩衝區）
這個過程買家一直在等待
是同步io
'''

NIO – 非阻塞模式I/O

使用者程序發起請求，如果資料沒有準備好，那麼立刻告知使用者程序未準備好；此時使用者程序可選擇繼續發起請求、或者先去做其他事情，稍後再回來繼續發請求，直到被告知資料準備完畢，可以開始接收為止； 資料會由使用者程序完成拷貝

'''
舉個例子：一個人去 商店買一把菜刀，
他到商店問老闆有沒有菜刀（發起系統呼叫）
老闆說沒有，在向工廠進貨（返回狀態）
買家去別地方玩了會，又回來問，菜刀到了麼（發起系統呼叫）
老闆說還沒有（返回狀態）
買家又去玩了會（不斷輪詢）
最後一次再問，菜刀有了（資料準備好了）
老闆把菜刀遞給買家（從核心緩衝區拷貝到使用者緩衝區）

整個過程輪詢+等待：輪詢時沒有等待，可以做其他事，從核心緩衝區拷貝到使用者緩衝區需要等待
是同步io

同一個執行緒，同一時刻只能監聽一個socket，造成浪費，引入io多路複用，同時監聽讀個socket
'''

IO Multiplexing - I/O多路複用模型

類似BIO，只不過找了一個代理，來掛起等待，並能同時監聽多個請求； 資料會由使用者程序完成拷貝

'''
舉個例子：多個人去 一個商店買菜刀，
多個人給老闆打電話，說我要買菜刀（發起系統呼叫）
老闆把每個人都記錄下來（放到select中）
老闆去工廠進貨（IO操作）
有貨了，再挨個通知買到的人，來取刀（通知/返回可讀條件）
買家來到商店等待，老闆把到給買家（從核心緩衝區拷貝到使用者緩衝區）

多路複用：老闆可以同時接受很多請求（select模型最大1024個，epoll模型），
但是老闆把到給買家這個過程，還需要等待，
是同步io

'''

AIO – 非同步I/O模型

發起請求立刻得到回覆，不用掛起等待； 資料會由核心程序主動完成拷貝

'''
舉個例子：還是買菜刀
現在是網上下單到商店（系統呼叫）
商店確認（返回）
商店去進貨（io操作）
商店收到貨把貨發個賣家（從核心緩衝區拷貝到使用者緩衝區）
買家收到貨（指定訊號）

整個過程無等待
非同步io

AIO框架在windows下使用windows IOCP技術，在Linux下使用epoll多路複用IO技術模擬非同步IO

市面上多數的高併發框架，都沒有使用非同步io而是用的io多路複用，因為io多路複用技術很成熟且穩定，並且在實際的使用過程中，非同步io並沒有比io多路複用效能提升很多，沒有達到很明顯的程度
並且，真正的AIO編碼難度比io多路複用高很多
'''

select poll 和epoll

#  1 select poll 和epoll都是io多路複用技術
select, poll , epoN都是io多路複用的機制。I/O多路複用就是通過一種機 制個程序可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程式進行相應的讀寫操作。但select, poll , epoll本質上都是同步I/O ,因為他們都需要在讀寫事件就緒後自己負責進行讀寫， 也就是說這個讀寫過程是阻塞的，而非同步I/O則無需自己負責進行讀寫，異 步I/O的實現會負責把資料從核心拷貝到使用者空間。

# 2 select
select函式監視的檔案描述符分3類，分別是writefds、readfds、和 exceptfds。呼叫後select函式會阻塞，直到有描述副就緒（有資料可讀、 可寫、或者有except）,或者超時（timeout指定等待時間，如果立即返回 設為null即可），函式返回。當select函式返回後，可以通過遍歷fdset,來 找到就緒的描述符。
select目前幾乎在所有的平臺上支援，其良好跨平臺支援也是它的一個 優點。select的一個缺點在於單個程序能夠監視的檔案描述符的數量存在最大限制，在Linux上一般為1024 ,可以通過修改巨集定義甚至重新編譯核心的 方式提升這一限制，但是這樣也會造成效率的降低。
# 3 poll
不同於select使用三個點陣圖來表示三個fdset的方式，poll使用一個 pollfd的指標實現。
pollfd結構包含了要監視的event和發生的event,不再使用select '引數-值'傳遞的方式。同時，pollfd並沒有最大數量限制（但是數量過大後 效能也是會下降）。和select函式一樣，poll返回後，需要輪詢pollfd來獲取就緒的描述符。
從上面看，select和poll都需要在返回後，通過遍歷檔案描述符來獲取 已經就緒的socket。事實上，同時連線的大量客戶端在一時刻可能只有很少的處於就緒狀態，因此隨著監視的描述符數量的增長，其效率也會線性下降

# 4 epoll
epoll是在linux2.6核心中提出的，是之前的select和poll的增強版本。相對 於select和poll來說，epoll更加靈活，沒有描述符限制。epoll使用一個文 件描述符管理多個描述符，將使用者關係的檔案描述符的事件存放到核心的一個事件表中，這樣在使用者空間和核心空間的copy只需一次。

# 5 更好的例子理解
老師檢查同學作業，一班50個人，一個一個問，同學，作業寫完了沒？select，poll
老師檢查同學作業，一班50個人，同學寫完了主動舉手告訴老師，老師去檢查 epoll

# 6 總結
在併發高的情況下，連線活躍度不高，epoll比select好，網站http的請求，連了就斷掉
併發性不高，同時連線很活躍，select比epoll好，websocket的連線，長連線，遊戲開發

三 同步I/O與非同步I/O

• 同步I/O
  • 概念：導致請求程序阻塞的I/O操作，直到I/O操作任務完成
  • 型別：BIO、NIO、IO Multiplexing
• 非同步I/O
  • 概念：不導致程序阻塞的I/O操作
  • 型別：AIO

注意：

• 同步I/O與非同步I/O判斷依據是，是否會導致使用者程序阻塞
• BIO中socket直接阻塞等待（使用者程序主動等待，並在拷貝時也等待）
• NIO中將資料從核心空間拷貝到使用者空間時阻塞（使用者程序主動詢問，並在拷貝時等待）
• IO Multiplexing中select等函式為阻塞、拷貝資料時也阻塞（使用者程序主動等待，並在拷貝時也等待）
• AIO中從始至終使用者程序都沒有阻塞（使用者程序是被動的）

四 併發-並行-同步-非同步-阻塞-非阻塞

# 1 併發
併發是指一個時間段內，有幾個程式在同一個cpu上執行，但是同一時刻，只有一個程式在cpu上執行
跑步，鞋帶開了，停下跑步，繫鞋帶
# 2 並行
指任意時刻點上，有多個程式同時執行在多個cpu上
跑步，邊跑步邊聽音樂
# 3 同步：
指程式碼呼叫io操作時，必須等待io操作完成才返回的呼叫方式
# 4 非同步
非同步是指程式碼呼叫io操作時，不必等io操作完成就返回呼叫方式
# 6 阻塞
指呼叫函式時候，當前執行緒別掛起
# 6 非阻塞
指呼叫函式時候，當前執行緒不會被掛起，而是立即返回

# 區別：
同步和非同步是訊息通訊的機制
阻塞和非阻塞是函式呼叫機制

五 IO設計模式

 Reactor模式，基於同步I/O實現
- Proactor模式，基於非同步I/O實現

Reactor模式通常採用IO多路複用機制進行具體實現

- kqueue、epoll、poll、select等機制

Proactor模式通常採用OS Asynchronous IO(AIO)的非同步機制進行實現

- 前提是對應作業系統支援AIO，比如支援非同步IO的linux(不太成熟)、具備IOCP的windows server(非常成熟)

Reactor模式和Proactor模式都是事件驅動，主要實現步驟：

1. 事件註冊：將事件與事件處理器進行分離。將事件註冊到事件迴圈中，將事件處理器單獨管理起來，記錄其與事件的對應關係。
2. 事件監聽：啟動事件迴圈，一旦事件已經就緒/完成，就立刻通知事件處理器
3. 事件分發：當收到事件就緒/完成的訊號，便立刻啟用與之對應的事件處理器
4. 事件處理：在程序/執行緒/協程中執行事件處理器

使用過程中，使用者通常只負責定義事件和事件處理器並將其註冊以及一開始的事件迴圈的啟動，這個過程就會是以非同步的形式執行任務。

Reactor模式

Proactor模式

對比分析

Reactor模型處理耗時長的操作會造成事件分發的阻塞，影響到後續事件的處理；

Proactor模型實現邏輯複雜；依賴作業系統對非同步的支援，目前實現了純非同步操作的作業系統少，實現優秀的如windows IOCP，但由於其windows系統用於伺服器的侷限性，目前應用範圍較小；而Unix/Linux系統對純非同步的支援有限，因而應用事件驅動的主流還是基於select/epoll等實現的reactor模式

Python中：如asyncio、gevent、tornado、twisted等非同步模組都是依據事件驅動模型設計，更多的都是使用reactor模型，其中部分也支援proactor模式，當然需要根據當前執行的作業系統環境來進行手動配置