我們這里先介紹 一下相關(guān)的知識點

1.Httpd MPM

? httpd MPM：
? prefork：進程模型，兩級結(jié)構(gòu)跷车，主進程master負責(zé)生成子進程，每個子進程負責(zé)響應(yīng)一個請求
? worker：線程模型，三級結(jié)構(gòu)溪厘，主進程master負責(zé)生成子進程狮鸭，每個子進程負責(zé)生成多個線程合搅，每個線程響應(yīng)一個請求
? event：主進程master負責(zé)生成子進程，每個子進程響應(yīng)多個請求

2.I/O介紹

? I/O:
? 網(wǎng)絡(luò)IO：本質(zhì)是socket讀取
? 磁盤IO：
? 每次IO歧蕉，都要經(jīng)由兩個階段：
? 第一步：將數(shù)據(jù)從文件先加載至內(nèi)核內(nèi)存空間（緩沖區(qū)）灾部，等待數(shù)據(jù)準備完成，時間較長
? 第二步：將數(shù)據(jù)從內(nèi)核緩沖區(qū)復(fù)制到用戶空間的進程的內(nèi)存中惯退，時間較短

3.I/O模型

? 同步/異步：關(guān)注的是消息通信機制
? 同步：synchronous赌髓，調(diào)用者自已主動等待被調(diào)用者返回消息，才能繼續(xù)執(zhí)行
? 異步：asynchronous催跪，被調(diào)用者通過狀態(tài)锁蠕、通知或回調(diào)機制主動通知調(diào)用者被調(diào)用者的運行狀態(tài)
? 阻塞/非阻塞：關(guān)注調(diào)用者在等待結(jié)果返回之前所處的狀態(tài)
? 阻塞：blocking，指IO操作需要徹底完成后才返回到用戶空間懊蒸，調(diào)用結(jié)果返回之前荣倾，調(diào)用者被掛起
? 非阻塞：nonblocking，指IO操作被調(diào)用后立即返回給用戶一個狀態(tài)值骑丸，無需等到IO操作徹底完成舌仍，最終的調(diào)用結(jié)果返回之前，調(diào)用者不會被掛起
I/O模型:
阻塞型通危、非阻塞型抡笼、復(fù)用型、信號驅(qū)動型黄鳍、異步

同步阻塞IO模型

Paste_Image.png

同步阻塞IO模型
? 同步阻塞IO模型是最簡單的IO模型推姻，用戶線程在內(nèi)核進行IO操作時被阻塞。
? 用戶線程通過系統(tǒng)調(diào)用read發(fā)起IO讀操作框沟，由用戶空間轉(zhuǎn)到內(nèi)核空間藏古。內(nèi)核等到數(shù)據(jù)包到達后，然后將接收的數(shù)據(jù)拷貝到用戶空間忍燥，完成read操作拧晕。
? 用戶需要等待read將數(shù)據(jù)讀取到buffer后，才繼續(xù)處理接收的數(shù)據(jù)梅垄。整個IO請求的過程中厂捞，用戶線程是被阻塞的，這導(dǎo)致用戶在發(fā)起IO請求時，不能做任何事情靡馁，對CPU的資源利用率不夠欲鹏。

同步非阻塞IO模型

Paste_Image.png

同步非阻塞IO模型
? 用戶線程發(fā)起IO請求時立即返回。但并未讀取到任何數(shù)據(jù)臭墨，用戶線程需要不斷地發(fā)起IO請求赔嚎，直到數(shù)據(jù)到達后，才真正讀取到數(shù)據(jù)胧弛，繼續(xù)執(zhí)行尤误。即 “輪詢”機制
? 整個IO請求的過程中，雖然用戶線程每次發(fā)起IO請求后可以立即返回结缚，但是為了等到數(shù)據(jù)损晤，仍需要不斷地輪詢、重復(fù)請求红竭，消耗了大量的CPU的資源
? 是比較浪費CPU的方式尤勋，一般很少直接使用這種模型，而是在其他IO模型中使用非阻塞IO這一特性

IO多路復(fù)用模型

Paste_Image.png

I/O多路復(fù)用模型
? 本模型會阻塞進程德崭，但是進程是阻塞在select或者poll這兩個系統(tǒng)調(diào)用上斥黑，而不是阻塞在真正的IO操作上
? 用戶首先將需要進行IO操作添加到select中揖盘，繼續(xù)執(zhí)行做其他的工作（異步）眉厨，同時等待select系統(tǒng)調(diào)用返回。當數(shù)據(jù)到達時兽狭，IO被激活憾股，select函數(shù)返回。用戶線程正式發(fā)起read請求箕慧，讀取數(shù)據(jù)并繼續(xù)執(zhí)行服球。
? 從流程上來看，使用select函數(shù)進行IO請求和同步阻塞模型沒有太大的區(qū)別颠焦，甚至還多了添加監(jiān)視IO斩熊，以及調(diào)用select函數(shù)的額外操作，效率更差伐庭。并且阻塞了兩次粉渠，但是第一次阻塞在select上時，select可以監(jiān)控多個IO上是否已有IO操作準備就緒圾另，即可達到在同一個線程內(nèi)同時處理多個IO請求的目的霸株。而不像阻塞IO那種，一次只能監(jiān)控一個IO
? 雖然上述方式允許單線程內(nèi)處理多個IO請求集乔，但是每個IO請求的過程還是阻塞的（在select函數(shù)上阻塞）去件，平均時間甚至比同步阻塞IO模型還要長。如果用戶線程只是注冊自己需要的IO請求，然后去做自己的事情尤溜，等到數(shù)據(jù)到來時再進行處理倔叼，則可以提高CPU的利用率
? IO多路復(fù)用是最常使用的IO模型，但是其異步程度還不夠“徹底”靴跛，因為它使用了會阻塞線程的select系統(tǒng)調(diào)用缀雳。因此IO多路復(fù)用只能稱為異步阻塞IO模型，而非真正的異步IO

多路I/O復(fù)用

? IO多路復(fù)用是指內(nèi)核一旦發(fā)現(xiàn)進程指定的一個或者多個IO條件準備讀取梢睛，它就通知該進程
? IO多路復(fù)用適用如下場合：
? 當客戶處理多個描述符時（一般是交互式輸入和網(wǎng)絡(luò)套接口）肥印，必須使用I/O復(fù)用
? 當一個客戶同時處理多個套接口時，這種情況是可能的绝葡，但很少出現(xiàn)
? 當一個TCP服務(wù)器既要處理監(jiān)聽套接口深碱，又要處理已連接套接口，一般也要用到I/O復(fù)用藏畅。
? 當一個服務(wù)器即要處理TCP敷硅，又要處理UDP，一般要使用I/O復(fù)用
? 當一個服務(wù)器要處理多個服務(wù)或多個協(xié)議愉阎，一般要使用I/O復(fù)用

信號驅(qū)動IO模型

Paste_Image.png

信號驅(qū)動IO模型
? 信號驅(qū)動IO：signal-driven I/O
? 就是說用戶進程可以通過sigaction系統(tǒng)調(diào)用注冊一個信號處理程序绞蹦，然后主程序可以繼續(xù)向下執(zhí)行，當有IO操作準備就緒時榜旦，由內(nèi)核通知觸發(fā)一個SIGIO信號處理程序執(zhí)行幽七，然后將用戶進程所需要的數(shù)據(jù)從內(nèi)核空間拷貝到用戶空間
? 此模型的優(yōu)勢在于等待數(shù)據(jù)報到達期間進程不被阻塞。用戶主程序可以繼續(xù)執(zhí)行溅呢，只要等待來自信號處理函數(shù)的通知
? 該模型并不常用

異步IO模型

Paste_Image.png

異步IO模型
? 異步IO與信號驅(qū)動IO最主要的區(qū)別是信號驅(qū)動IO是由內(nèi)核通知何時可以進行IO操作澡屡，而異步IO則是由內(nèi)核告訴我們IO操作何時完成了。具體來說就是咐旧，信號驅(qū)動IO當內(nèi)核通知觸發(fā)信號處理程序時驶鹉，信號處理程序還需要阻塞在從內(nèi)核空間緩沖區(qū)拷貝數(shù)據(jù)到用戶空間緩沖區(qū)這個階段，而異步IO直接是在第二個階段完成后內(nèi)核直接通知可以進行后續(xù)操作了
? 相比于IO多路復(fù)用模型铣墨，異步IO并不十分常用室埋，不少高性能并發(fā)服務(wù)程序使用IO多路復(fù)用模型+多線程任務(wù)處理的架構(gòu)基本可以滿足需求。況且目前操作系統(tǒng)對異步IO支持并非特別完善伊约，更多的是采用IO多路復(fù)用模型模擬異步IO的方式（IO事件觸發(fā)時不直接通知用戶線程姚淆，而是將數(shù)據(jù)讀寫完畢后放到用戶指定的緩沖區(qū)中）

五種I/O模型

Paste_Image.png

4.I/O模型的具體實現(xiàn)

? 主要實現(xiàn)方式有以下幾種：
? Select：Linux實現(xiàn)對應(yīng)，I/O復(fù)用模型
? Poll：Linux實現(xiàn)碱妆，對應(yīng)I/O復(fù)用模型
? Epoll：Linux實現(xiàn)肉盹，對應(yīng)I/O復(fù)用模型，具有信號驅(qū)動I/O模型的某些特性
? Kqueue：FreeBSD實現(xiàn)疹尾，對應(yīng)I/O復(fù)用模型上忍，具有信號驅(qū)動I/O模型的某些特性
? /dev/poll：SUN的Solaris實現(xiàn)骤肛，對應(yīng)I/O復(fù)用模型，具有信號驅(qū)動I/O模型的某些特性
? Iocp Windows實現(xiàn)窍蓝，對應(yīng)第5種（異步I/O）模型

select/poll/epoll

Paste_Image.png

? Select:

POSIX所規(guī)定腋颠，目前幾乎在所有的平臺上支持，其良好跨平臺支持也是它的一個優(yōu)點吓笙，本質(zhì)上是通過設(shè)置或者檢查存放fd標志位的數(shù)據(jù)結(jié)構(gòu)來進行下一步處理
? 缺點
? 單個進程可監(jiān)視的fd數(shù)量被限制淑玫，即能監(jiān)聽端口的數(shù)量有限
cat /proc/sys/fs/file-max
? 對socket是線性掃描，即采用輪詢的方法面睛，效率較低
? select 采取了內(nèi)存拷貝方法來實現(xiàn)內(nèi)核將 FD 消息通知給用戶空間絮蒿，這樣一個用來存放大量fd的數(shù)據(jù)結(jié)構(gòu)，這樣會使得用戶空間和內(nèi)核空間在傳遞該結(jié)構(gòu)時復(fù)制開銷大

?poll

? 本質(zhì)上和select沒有區(qū)別叁鉴，它將用戶傳入的數(shù)組拷貝到內(nèi)核空間土涝，然后查詢每個fd對應(yīng)的設(shè)備狀態(tài)
? 其沒有最大連接數(shù)的限制，原因是它是基于鏈表來存儲的
? 大量的fd的數(shù)組被整體復(fù)制于用戶態(tài)和內(nèi)核地址空間之間幌墓，而不管這樣的復(fù)制是不是有意義
? poll特點是“水平觸發(fā)”但壮，如果報告了fd后，沒有被處理常侣，那么下次poll時會再次報告該fd
? 邊緣觸發(fā)：只通知一次

? epoll：在Linux 2.6內(nèi)核中提出的select和poll的增強版本

? 支持水平觸發(fā)和邊緣觸發(fā)蜡饵，最大的特點在于邊緣觸發(fā)，它只告訴進程哪些fd剛剛變?yōu)榫托钁B(tài)胳施，并且只會通知一次
? 使用“事件”的就緒通知方式溯祸，通過epoll_ctl注冊fd，一旦該fd就緒巾乳，內(nèi)核就會采用類似callback的回調(diào)機制來激活該fd您没，epoll_wait便可以收到通知
? 優(yōu)點:
? 沒有最大并發(fā)連接的限制：能打開的FD的上限遠大于1024(1G的內(nèi)存能監(jiān)聽約10萬個端口)
? 效率提升：非輪詢的方式鸟召，不會隨著FD數(shù)目的增加而效率下降胆绊；只有活躍可用的FD才會調(diào)用callback函數(shù)，即epoll最大的優(yōu)點就在于它只管理“活躍”的連接欧募，而跟連接總數(shù)無關(guān)
? 內(nèi)存拷貝压状，利用mmap()文件映射內(nèi)存加速與內(nèi)核空間的消息傳遞；即epoll使用mmap減少復(fù)制開銷