摘要：全稱是多道處理模塊我們都知道是以模塊化方式設計的那么用來決定如何處理用戶請求的是通過一個進程處理一個請求還是一個線程處理一個請求當前有三種可以選擇的方式雖然有以上三種方式但是要注意在任何時間必須有一個而且只能有一個被使用那么下面就介紹一下這

MPM全稱是多道處理模塊,我們都知道apache是以模塊化方式設計的.那么MPM用來決定apache如何處理用戶請求的.是通過一個進程處理一個請求,還是一個線程處理一個請求.當前MPM有三種可以選擇的方式:

prefork

worker

event


雖然有以上三種方式,但是要注意在任何時間,必須有一個,而且只能有一個MPM被使用.那么下面就介紹一下這三種處理方式的區別.

在這種工作模型下,apache進程分為master進程跟worker進程.web服務啟動就是啟動master進程,隨之master進程會啟動若干個worker子進程.master進程的工作就是管理worker子進程.而worker子進程的工作就是處理用戶請求.當用戶發起一個請求,apache就會從空閑的子進程中選擇一個處理這個用戶請求.

這種處理方式有以下幾點好處:

用戶不用等到其他進程處理完畢.因為只要有空閑子進程在就可以處理新的請求

如果一個worker子進程崩潰了,不會影響其他worker進程處理請求.

但是worker子進程的個數限制于apache配置文件中如下幾個條目的限制

MinSpareServers 最少空閑worker進程.

MaxSpareServers最多空閑worker進程,超過這個數,就會有一些空閑worker進程被kill

MaxRequestWorkers同一時刻可以處理的請求數,即并發量

MaxConnectionsPerChild每一個worker子進程一生中可以處理的請求,超過這個數之后就會被master進程kill

同時, 一般master進程使用root用戶啟動,這樣方便master進程監聽80端口,以及管理進程.而余下的worker子進程則是以apache配置文件中User指令指定的用戶啟動.這樣子是為了減少worker子進程的權限.保證安全.

root@ff1221aa94a9:~# ps -aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4448   676 ?        Ss   09:33   0:00 /bin/sh -c supervisord -n
root         5  0.0  0.8  60556 17172 ?        S    09:33   0:02 /usr/bin/python /usr/bin/supervisord -n
root        31  0.0  0.1  61384  3160 ?        Ss   09:33   0:00 /usr/sbin/sshd
root        32  0.0  0.8 200164 16384 ?        Ss   09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      33  0.0  0.4 200300  8392 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      34  0.0  0.3 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      35  0.0  0.3 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      36  0.0  0.3 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start
daemon      37  0.0  0.3 200300  7512 ?        S    09:33   0:00 /usr/local/apache/bin/httpd -k start

執行ps可以看出只有一個master進程以root用戶方式啟動

prefork的缺點很明顯,一個worker進程處理一個請求,并發不會高.而且進程占用的資源太多.做的事情卻只是處理一個請求.worker針對prefork的問題進行了改進.

仍然有一個master父進程啟動若干個子進程

每個子進程啟動若干個線程

每個線程處理每個請求

這樣子,worker模型的并發性高于prefork模型.并且由于線程的開銷小于進程,所以worker模型占用的資源反而小于prefork.

但是worker相對于prefork存在一個問題:非線程安全.最典型的一個問題在于:如果你的apache使用了worker模型工作.但是php卻使用非線程安全的版本,那么這兩者就不能工作了.所以縱然worker有萬般好,但是碰到使用非線程安全的歷史代碼,還是只能乖乖使用prefork模型.

worker模型使用多線程響應請求,這樣子存在一個問題,即一個線程崩潰就會影響整個進程.所以worker使用的是多進程+多線程的混合模型.即可以提高并發性,也可以避免一個線程崩潰導致整個整個web站點崩潰.

同prefork一樣,worker中子進程跟線程數量也收到apache配置文件的控制.有如下參數

MinSpareThreads最少空閑線程

ThreadsPerChild每個子進程可以創建的線程數量

MaxClients同時可以處理的請求數

.....

其web服務調優大抵就是根據服務器配置調節這些參數.具體參數細節可以參考Apache文檔

event模型是在apache2.2之后當做試驗特性引入的,在apache2.4之后才正式支持.event模型是為了解決長連接(keep-alive)問題而生的.使用worker模型,一個線程對應一個請求,當一個請求為長連接的時候,線程就會保持當長連接狀態,等待客戶端的下一個請求.這樣子當前線程就不能處理其他客戶端請求了.

event模型跟worker模型很像,也是多個進程+多個線程的混合模式,但是event模型下每個進程會有一個多帶帶的線程來管理這些keep-alive類型的線程.當新的請求過來的時候,管理線程會把請求交給其他的空閑線程處理.這樣子就避免了每個線程都被keep-alive阻塞.

但是event模型并不是所有情況都通用,在https協議下會退化成worker模型.具體原因可以看官方文檔.

講到Apache,不得不提起現在Nginx.相比于Apache.Nginx于2004年正式發布.而Apache在1995就已經出現了.當時的web環境還只是簡單的展示靜態頁面,而且并發量遠沒有現在這么高.所以當時Apache的prefork模型也可以很好的承擔web服務需求.加之其穩定性好,沒有什么理由不用它.

當時后來互聯網漸漸變大,網站的并發量變大,Apache就出現了一個C10K的問題.即一個物理服務器達到并發量1W的時候apache就會承受不了.后來2004年Nginx很好的解決了C10K問題.Nginx為何能優于apache解決C10K問題,我們還是得從其處理請求模型說起.

Nginx有三個著名的特性:

事件驅動編程

異步

非IO阻塞

正是這三種編程方式促使Nginx可以有如此高的并發量.下面來分析下Nginx到底是如何工作的.

同樣,Nginx的進程也分為master進程跟worker子進程.(其實還有兩個cache有關的進程, 這里略過).在啟動nginx之后,master進程就會隨即創建一定數量的worker子進程,并且之后worker子進程數量保持不變.并且這些worker子進程都是單線程的.當一個請求到來時,worker進程中某一個空閑進程就會去處理這個請求.乍一看到這里nginx的工作模式跟apache沒有什么區別.關鍵就在于nginx如何處理用戶請求.

worker子進程開始處理請求.這個請求可能是訪問某個網站的靜態頁面.而html頁面都是保存在硬盤上的.站在操作系統角度來看,nginx是沒有辦法直接讀取硬盤上的文件,必須由nginx告訴操作系統需要讀取哪個文件,然后又操作系統去讀取這個文件,讀取完畢操作系統再交給nginx.也就是說,在操作系統讀取文件的時候,nginx是空閑的.如果是apache,那這個時候apache的worker進程/線程就阻塞在這里等待操作系統把文件讀取好再交個自己,這種就稱之為IO阻塞.

但是nginx不一樣, nginx的worker進程在這個時候就會注冊一個事件,相當于告訴操作系統:你文件讀好了跟我說一下,我先去處理其他事情.然后這個worker就可以去處理新的用戶請求了.這里nginx的worker進程并沒有由于操作系統讀取文件而阻塞等待,這種即稱之為非IO阻塞

當操作系統讀取好文件之后,就會通知ngixn:我文件幫你讀取好了,你過來拿走."操作系統讀取好文件"這個事件被觸發了,于是Nginx就跑回去把文件拿走,然后返回響應.這種由于某個事件出現觸發Nginx執行操作的方式就稱為事件驅動編程.

我們回顧上面過程,一個用戶請求讀取文件,nginx把讀取文件這個事情通知操作系統之后就去處理下一個用戶請求,直到操作系統讀取好文件之后再返回響應.這種一個請求還沒有處理完畢就去處理下一個請求的編程方式即異步編程

正是由于nginx這種工作模型,使得nginx在保持一定量的worker進程下,也可以得到相當大的并發量.這點正是nginx優于apache的地方.同樣,nginx的這種請求處理模型在處理長連接的時候也可以使用.

那么是不是說Nginx一定就優于Apache.Apache就藥丸了呢.也不是.一定要記住,一個后來者的出現, 沒有在它的前輩所擅長的領域打敗它,那么后來者是不可能完全取代前者.很有可能的情況是兩者并存.nginx本身并不能處理php,python等腳本語言,只能把這些動態請求通過CGI轉發給其他程序處理.所以現在通常的架構是前臺Ngixn負責處理靜態文件諸如js,css,image文件.而碰到請求php等動態內容.就在后端多個apache服務器中選擇一個比較空閑的服務器,把這請求轉發給這個服務器處理.等apache處理好之后把返回交給nginx.nginx再返回給用戶.這是目前典型的一種設計方案.上面的流程中nginx負責兩個功能:反向代理,負載均衡.這也是nginx所擅長的兩個功能.而apache豐富的模塊可以很好的滿足一個站點的各種需求.并且經過了20+年的考驗,Apache的穩定性也是可以保證的.