Unix IO模型分類

• Blocking IO - 阻塞IO
• NoneBlocking IO - 非阻塞IO
• IO multiplexing - IO多路復用
• signal driven IO - 信號驅(qū)動IO
• asynchronous IO - 異步IO

阻塞IO - Blocking IO

最傳統(tǒng)的一種IO模型，即在讀寫數(shù)據(jù)過程中會發(fā)生阻塞現(xiàn)象。

當用戶線程發(fā)出IO請求之后，內(nèi)核會去查看數(shù)據(jù)是否就緒，如果沒有就緒就會等待數(shù)據(jù)就緒，而用戶線程就會處于阻塞狀態(tài)，用戶線程交出CPU。當數(shù)據(jù)就緒之后，內(nèi)核會將數(shù)據(jù)拷貝到用戶線程，并返回結(jié)果給用戶線程，用戶線程才解除block狀態(tài)。

也許有人會說，可以采用多線程+ 阻塞IO 來解決效率問題，但是由于在多線程 + 阻塞IO 中，每個socket對應一個線程，這樣會造成很大的資源占用，并且尤其是對于長連接來說，線程的資源一直不會釋放，如果后面陸續(xù)有很多連接的話，就會造成性能上的瓶頸。

非阻塞IO - NoneBlocking IO

當用戶線程發(fā)起一個 IO 操作后，并不需要等待，而是馬上就得到一個結(jié)果。如果結(jié)果是一個 error 時，它就知道數(shù)據(jù)還沒有準備好，于是它可以再次發(fā)送 IO 操作。一旦內(nèi)核中的數(shù)據(jù)準備好了，并且又再次收到了用戶線程的請求，那么它馬上就將數(shù)據(jù)拷貝到了用戶線程，然后返回。

在非阻塞IO 模型中，用戶線程需要不斷地詢問內(nèi)核數(shù)據(jù)是否就緒，也就說非阻塞IO不會交出CPU，而會一直占用CPU。

與阻塞IO的區(qū)別：

• 無數(shù)據(jù)時是否會直接返回
• 是否會交出CPU

對于非阻塞IO就有一個非常嚴重的問題，在while循環(huán)中需要不斷地去詢問內(nèi)核數(shù)據(jù)是否就緒，這樣會導致CPU占用率非常高，因此一般情況下很少使用while循環(huán)這種方式來讀取數(shù)據(jù)。

非阻塞IO核心流程：

• 非阻塞式主要體現(xiàn)在用戶進程發(fā)起recvfrom系統(tǒng)調(diào)用的時候,這個時候系統(tǒng)內(nèi)核還沒有接收到數(shù)據(jù)報,直接返回錯誤給用戶進程,告訴“當前還沒有數(shù)據(jù)報可達,晚點再來”

• 用戶進程接收到信息,但是用戶進程不知道什么時候數(shù)據(jù)報可達,于是就開始不斷輪詢(polling)向系統(tǒng)內(nèi)核發(fā)起recvfrom的系統(tǒng)調(diào)用“詢問數(shù)據(jù)來了沒”,如果沒有則繼續(xù)返回錯誤

• 用戶進程輪詢發(fā)起recvfrom系統(tǒng)調(diào)用直至數(shù)據(jù)報可達,這個時候需要等待系統(tǒng)內(nèi)核復制數(shù)據(jù)報到用戶進程的緩沖區(qū),復制完成之后將返回成功提示

IO多路復用 - IO multiplexing

IO 多路復用是一種同步IO模型，實現(xiàn)一個線程可以監(jiān)視多個文件句柄；一旦某個文件句柄就緒，就能夠通知應用程序進行相應的讀寫操作；沒有文件句柄就緒就會阻塞應用程序，交出CPU。多路是指網(wǎng)絡連接，復用指的是同一個線程。

? 不管是同步阻塞還是同步非阻塞，對系統(tǒng)性能的提升都是很小的。而通過復用可以使一個或一組線程（線程池）處理多個TCP連接。IO多路復用使用兩個系統(tǒng)調(diào)用（select/poll/epoll和recvfrom），blocking IO只調(diào)用了recvfrom。select/poll/epoll核心是可以同時處理多個connection，而不是更快，所以連接數(shù)不高的話，性能不一定比多線程+阻塞IO好。

由于非阻塞IO的弊端的存在，所以出現(xiàn)了IO多路復用。在多路復用IO模型中，會有一個內(nèi)核線程不斷地去輪詢多個 socket 的狀態(tài)，只有當真正讀寫事件發(fā)送時，才真正調(diào)用實際的IO讀寫操作。因為在多路復用IO模型中，只需要使用一個線程就可以管理多個socket，系統(tǒng)不需要建立新的進程或者線程，也不必維護這些線程和進程，并且只有真正有讀寫事件進行時，才會使用IO資源，所以它大大減少了CPU資源占用。

信號驅(qū)動IO - signal driven IO

在信號驅(qū)動IO模型中，當用戶線程發(fā)起一個IO請求操作，會給對應的socket注冊一個信號函數(shù)，然后用戶線程會繼續(xù)執(zhí)行，當內(nèi)核數(shù)據(jù)就緒時會發(fā)送一個信號給用戶線程，用戶線程接收到信號后，便在信號函數(shù)中調(diào)用IO讀寫操作來進行實際的IO請求操作。這個一般用于UDP中，對TCP套接字幾乎沒用，原因是該信號產(chǎn)生得過于頻繁，并且該信號的出現(xiàn)并沒有告訴我們發(fā)生了什么請求。

用戶進程可以使用信號方式，當系統(tǒng)內(nèi)核描述符就緒時將會發(fā)送SIGNO給到用戶空間，這個時候再發(fā)起recvfrom的系統(tǒng)調(diào)用等待返回成功提示，流程如下：

• 先開啟套接字的信號IO啟動功能，并通過一個內(nèi)置安裝信號處理函數(shù)的signaction系統(tǒng)調(diào)用，當發(fā)起調(diào)用之后會直接返回；
• 其次，等待內(nèi)核從網(wǎng)絡中接收數(shù)據(jù)報之后，向用戶空間發(fā)送當前數(shù)據(jù)可達的信號給信號處理函數(shù)；
• 信號處理函數(shù)接收到信息就發(fā)起recvfrom系統(tǒng)調(diào)用等待內(nèi)核數(shù)據(jù)復制數(shù)據(jù)報到用戶空間的緩沖區(qū)；
• 接收到復制完成的返回成功提示之后，應用進程就可以開始從網(wǎng)絡中讀取數(shù)據(jù)。

異步IO - asynchronous IO

前面四種IO模型實際上都屬于同步IO，只有最后一種是真正的異步IO，因為無論是多路復用IO還是信號驅(qū)動模型，IO操作的第2個階段都會引起用戶線程阻塞，也就是內(nèi)核進行數(shù)據(jù)拷貝的過程都會讓用戶線程阻塞。

• 由POSIX規(guī)范定義，告知系統(tǒng)內(nèi)核啟動某個操作，并讓內(nèi)核在整個操作包含數(shù)據(jù)等待以及數(shù)據(jù)復制過程的完成之后通知用戶進程數(shù)據(jù)已經(jīng)準備完成，可以進行讀取數(shù)據(jù)；
• 與上述的信號IO模型區(qū)分在于異步是通知我們何時IO操作完成,而信號IO是通知我們何時可以啟動一個IO操作

同步與異步的定義

• 同步:發(fā)起一個fn的調(diào)用,需要等待調(diào)用結(jié)果返回,該調(diào)用結(jié)果要么是期望的結(jié)果要么是異常拋出的結(jié)果,可以說是原子性操作(要么成功要么失敗返回)
• 異步: 發(fā)起一個fn調(diào)用,無需等待結(jié)果就直接返回,只有當被調(diào)用者執(zhí)行處理程序之后通過“喚醒”手段通知調(diào)用方獲取結(jié)果(喚醒的方式有回調(diào),事件通知等)
• 小結(jié): 同步和異步關(guān)注的是程序之間的通信

阻塞與非阻塞的定義

• 阻塞: 無數(shù)據(jù)時會阻塞等待有數(shù)據(jù)才返回
• 非阻塞: 無數(shù)據(jù)時直接返回無數(shù)據(jù)，無需等待
• 小結(jié): 阻塞與非阻塞更關(guān)注是程序等待結(jié)果的狀態(tài)
• 由此可知,同步、異步與阻塞、非阻塞之間不存在關(guān)聯(lián),關(guān)注的目標是不一樣的

IO多路復用有哪些實現(xiàn)

• select
• poll
• epoll

IO多路復用的大致實現(xiàn)

select是內(nèi)核提供的多路分離函數(shù)，使用它可以避免同步非阻塞IO中輪詢等待問題。

用戶首先將需要進行IO操作的socket添加到select中，然后阻塞等待select系統(tǒng)調(diào)用返回。當數(shù)據(jù)到達時，socket被激活，select函數(shù)返回，用戶線程正式發(fā)起read請求，讀取數(shù)據(jù)并繼續(xù)執(zhí)行。

這么一看，這種方式和同步阻塞IO并沒有太大區(qū)別，甚至還多了添加監(jiān)視socket以及調(diào)用select函數(shù)的額外操作，效率更差。但是使用select以后，用戶可以在一個線程內(nèi)同時處理多個socket的IO請求，這就是它的最大優(yōu)勢。用戶可以注冊多個socket，然后不斷調(diào)用select讀取被激活的socket，即可達到同一個線程同時處理多個IO請求的目的。而在同步阻塞模型中，必須通過多線程方式才能達到這個目的。所以IO多路復用設計目的其實不是為了快，而是為了解決線程/進程數(shù)量過多對服務器開銷造成的壓力。

雖然這種方式允許單線程內(nèi)處理多個IO請求，但是每個IO請求的過程還是阻塞的（在select函數(shù)上阻塞），平均時間甚至比同步阻塞IO模型還要長。如果用戶線程只注冊自己感興趣的socket，然后去做自己的事情，等到數(shù)據(jù)到來時在進行處理，則可以提高CPU利用率。

通過Reactor方式，用戶線程輪詢IO操作狀態(tài)的工作統(tǒng)一交給handle_events事件循環(huán)處理。用戶線程注冊事件處理器之后可以繼續(xù)執(zhí)行做其他的工作（異步），而Reactor線程負責調(diào)用內(nèi)核的select函數(shù)檢查socket狀態(tài)。當有socket被激活時，則通知相應的用戶線程（或執(zhí)行用戶線程的回調(diào)函數(shù)），執(zhí)行handel_envent進行數(shù)據(jù)的讀取、處理工作。

由于select函數(shù)是阻塞的，因此多路IO復用模型就被稱為異步阻塞IO模型，這里阻塞不是指socket。因為使用IO多路復用時，socket都設置NONBLOCK，不過不影響，因為用戶發(fā)起IO請求時，數(shù)據(jù)已經(jīng)到達了，用戶線程一定不會被阻塞。

? IO多路復用是最常用的IO模型，但其異步程度還不徹底，因為它使用了會阻塞線程的select系統(tǒng)調(diào)用。因此IO多路復用只能稱為異步阻塞IO，而非真正的異步IO。

select

select函數(shù)監(jiān)視的文件描述符有三類，readfds，writefds，exceptfds。調(diào)用后函數(shù)會阻塞，直到有文件描述符就緒（有數(shù)據(jù)讀、寫、或者有except），或者超時（timeout指定時間，如果立即返回設置null），函數(shù)才會返回。當select函數(shù)返回后，可以通過便利fdset，來找到就緒的描述符。

? 優(yōu)點：良好的跨平臺性。

? 缺點：單個進程能夠監(jiān)視的文件描述符的數(shù)量存在最大限制，在Linux上為1024，可以通過修改宏定義甚至重新編譯內(nèi)核的方式提升這一限制，但這樣會造成效率的降低。有文件描述符就緒時需要遍歷fd集合獲取對應就緒的文件描述符，隨著文件描述符的增加遍歷的時間也會增加。

poll

與select使用三個位圖來表示fdset，poll使用一個pollfd的指針實現(xiàn)。pollfd結(jié)構(gòu)包含了要監(jiān)視的event和發(fā)生的event，不在使用select參數(shù)傳值的方式。同時pollfd并沒有最大數(shù)量的限制（但數(shù)量過大性能也會下降）。和select一樣，poll返回后，需要輪詢pollfd來或許就緒的描述符。

• 優(yōu)點：無需再傳遞文件描述符集合；文件描述符的最大數(shù)量不再受到限制。
• 缺點：依然需要遍歷文件描述符集合；

epoll

epoll是select和poll的增強版本，相比于前兩者，它更加的靈活，沒有描述符的限制。epoll使用一個事件表管理多個描述符，將用戶關(guān)系的文件描述符的事件存放到內(nèi)核的一個事件表中，這樣在用戶空間和內(nèi)核空間的copy只需要一次。

當用戶請求時將請求注冊到事件表中，然后用戶就可以處理其他事情了，內(nèi)核有專門的線程處理事件列表中的事件，當有文件事件準備就緒時就根據(jù)注冊的事件信息通知對應的應用程序進行對應的操作事件。這樣就解決了select、poll中剛開始sock請求的阻塞問題，但是在數(shù)據(jù)獲取的請求中依然是阻塞的。

redis的線程模型

為什么 Redis 中要使用 I/O 多路復用

為什么 Redis 中要使用 I/O 多路復用這種技術(shù)呢？因為 Redis 是跑在單線程中的，所有的操作都是按照順序線性執(zhí)行的，但是由于讀寫操作等待用戶輸入 或 輸出都是阻塞的，所以 I/O 操作在一般情況下往往不能直接返回，這會出現(xiàn)當某一文件的 I/O 阻塞時，導致整個進程無法對其它客戶端提供服務。而 I/O 多路復用就是為了解決這個問題而出現(xiàn)的。為了讓單線程(進程)的服務端應用同時處理多個客戶端的事件，Redis 采用了 IO 多路復用機制。

redis線程模型實現(xiàn)

Redis基于Reactor模式的epoll實現(xiàn)開發(fā)了網(wǎng)絡事件處理器，這個處理器被稱為文件事件處理器。它的組成結(jié)構(gòu)為4部分：多個套接字、IO多路復用程序、文件事件分派器、事件處理器。因為文件事件分派器隊列的消費是單線程的，所以Redis才叫單線程模型。

消息處理流程

多個 socket 可能會并發(fā)產(chǎn)生不同的操作，每個操作對應不同的文件事件，但是 IO多路復用程序會監(jiān)聽多個 socket，會將產(chǎn)生事件的 socket 順序、每次一個放入隊列中排隊，并且在一個事件執(zhí)行結(jié)束后才放另一個事件，事件分派器每次從隊列中取出一個 socket，根據(jù) socket 的事件類型交給對應的事件處理器進行處理。

盡管多個文件事件可能會并發(fā)地出現(xiàn)，但I/O多路復用程序總是會將所有產(chǎn)生事件的套接字都推到一個隊列里面，然后通過這個隊列，以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向文件事件分派器傳送套接字：當上一個套接字產(chǎn)生的事件被處理完畢之后（該套接字為事件所關(guān)聯(lián)的事件處理器執(zhí)行完畢）， I/O多路復用程序才會繼續(xù)向文件事件分派器傳送下一個套接字。

I/O 多路復用程序的實現(xiàn)

Redis的I/O多路復用程序的所有功能是通過包裝select、epoll、evport和kqueue這些I/O多路復用函數(shù)庫來實現(xiàn)的，每個I/O多路復用函數(shù)庫在Redis源碼中都對應一個單獨的文件，比如ae_select.c、ae_epoll.c、ae_kqueue.c等。因為Redis為每個I/O多路復用函數(shù)庫都實現(xiàn)了相同的API，所以I/O多路復用程序的底層實現(xiàn)是可以互換的。

文件事件的類型

I/O 多路復用程序可以監(jiān)聽多個套接字的ae.h/AE_READABLE事件和ae.h/AE_WRITABLE事件，這兩類事件和套接字操作之間的對應關(guān)系如下：

• 當套接字變得可讀時（客戶端對套接字執(zhí)行write操作，或者執(zhí)行close操作），或者有新的可應答（acceptable）套接字出現(xiàn)時（客戶端對服務器的監(jiān)聽套接字執(zhí)行connect操作），套接字產(chǎn)生AE_READABLE 事件。

• 當套接字變得可寫時（客戶端對套接字執(zhí)行read操作），套接字產(chǎn)生AE_WRITABLE事件。I/O多路復用程序允許服務器同時監(jiān)聽套接字的AE_READABLE事件和AE_WRITABLE事件，如果一個套接字同時產(chǎn)生了這兩種事件，那么文件事件分派器會優(yōu)先處理AE_READABLE事件，等到AE_READABLE事件處理完之后，才處理AE_WRITABLE 事件。這也就是說，如果一個套接字又可讀又可寫的話，那么服務器將先讀套接字，后寫套接字。

文件事件的處理器

Redis為文件事件編寫了多個處理器，這些事件處理器分別用于實現(xiàn)不同的網(wǎng)絡通訊需求，常用的處理器如下：

• 為了對連接服務器的各個客戶端進行應答， 服務器要為監(jiān)聽套接字關(guān)聯(lián)連接應答處理器。
• 為了接收客戶端傳來的命令請求， 服務器要為客戶端套接字關(guān)聯(lián)命令請求處理器。
• 為了向客戶端返回命令的執(zhí)行結(jié)果， 服務器要為客戶端套接字關(guān)聯(lián)命令回復處理器。

連接應答處理器

連接應答處理器用于對連接服務器監(jiān)聽套接字的客戶端進行應答，具體實現(xiàn)為sys/socket.h/accept函數(shù)的包裝。

當Redis服務器進行初始化的時候，程序會將這個連接應答處理器和服務器監(jiān)聽套接字的AE_READABLE事件關(guān)聯(lián)起來，當有客戶端用sys/socket.h/connect函數(shù)連接服務器監(jiān)聽套接字的時候， 套接字就會產(chǎn)生AE_READABLE 事件， 引發(fā)連接應答處理器執(zhí)行， 并執(zhí)行相應的套接字應答操作。

命令請求處理器

命令請求處理器負責從套接字中讀入客戶端發(fā)送的命令請求內(nèi)容， 具體實現(xiàn)為unistd.h/read函數(shù)的包裝。

當一個客戶端通過連接應答處理器成功連接到服務器之后， 服務器會將客戶端套接字的AE_READABLE事件和命令請求處理器關(guān)聯(lián)起來，當客戶端向服務器發(fā)送命令請求的時候，套接字就會產(chǎn)生 AE_READABLE事件，引發(fā)命令請求處理器執(zhí)行，并執(zhí)行相應的套接字讀入操作。

在客戶端連接服務器的整個過程中，服務器都會一直為客戶端套接字的AE_READABLE事件關(guān)聯(lián)命令請求處理器。

命令回復處理器

命令回復處理器負責將服務器執(zhí)行命令后得到的命令回復通過套接字返回給客戶端，具體實現(xiàn)為unistd.h/write函數(shù)的包裝。

當服務器有命令回復需要傳送給客戶端的時候，服務器會將客戶端套接字的AE_WRITABLE事件和命令回復處理器關(guān)聯(lián)起來，當客戶端準備好接收服務器傳回的命令回復時，就會產(chǎn)生AE_WRITABLE事件，引發(fā)命令回復處理器執(zhí)行，并執(zhí)行相應的套接字寫入操作。

當命令回復發(fā)送完畢之后， 服務器就會解除命令回復處理器與客戶端套接字的 AE_WRITABLE 事件之間的關(guān)聯(lián)。

一次完整的客戶端與服務器連接事件示例

假設Redis服務器正在運作，那么這個服務器的監(jiān)聽套接字的AE_READABLE事件應該正處于監(jiān)聽狀態(tài)之下，而該事件所對應的處理器為連接應答處理器。

如果這時有一個Redis客戶端向Redis服務器發(fā)起連接，那么監(jiān)聽套接字將產(chǎn)生AE_READABLE事件， 觸發(fā)連接應答處理器執(zhí)行：處理器會對客戶端的連接請求進行應答， 然后創(chuàng)建客戶端套接字，以及客戶端狀態(tài)，并將客戶端套接字的 AE_READABLE 事件與命令請求處理器進行關(guān)聯(lián)，使得客戶端可以向主服務器發(fā)送命令請求。

之后，客戶端向Redis服務器發(fā)送一個命令請求，那么客戶端套接字將產(chǎn)生 AE_READABLE事件，引發(fā)命令請求處理器執(zhí)行，處理器讀取客戶端的命令內(nèi)容， 然后傳給相關(guān)程序去執(zhí)行。

執(zhí)行命令將產(chǎn)生相應的命令回復，為了將這些命令回復傳送回客戶端，服務器會將客戶端套接字的AE_WRITABLE事件與命令回復處理器進行關(guān)聯(lián)：當客戶端嘗試讀取命令回復的時候，客戶端套接字將產(chǎn)生AE_WRITABLE事件， 觸發(fā)命令回復處理器執(zhí)行， 當命令回復處理器將命令回復全部寫入到套接字之后， 服務器就會解除客戶端套接字的AE_WRITABLE事件與命令回復處理器之間的關(guān)聯(lián)。

總結(jié)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論