一、越來越多的并發(fā)連接數(shù)

現(xiàn)在的Web系統(tǒng)面對的并發(fā)連接數(shù)在近幾年呈現(xiàn)指數(shù)增長，高并發(fā)成為了一種常態(tài)，給Web系統(tǒng)帶來不小的挑戰(zhàn)。以最簡單粗暴的方式解決，就是增加Web系統(tǒng)的機(jī)器和升級硬件配置。雖然現(xiàn)在的硬件越來越便宜，但是一味地通過增加機(jī)器來解決并發(fā)量的增長，成本是非常高昂的。結(jié)合技術(shù)優(yōu)化方案，才是更有效的解決方法。

并發(fā)連接數(shù)為什么呈指數(shù)增長？實(shí)際上，從這幾年的用戶基數(shù)上看，這個(gè)數(shù)量并沒有出現(xiàn)指數(shù)增長，因此它并非主要原因。主要原因，還是web變得更復(fù)雜，交互更豐富所導(dǎo)致的。

1. 頁面元素增多，交互復(fù)雜

Web頁面元素越來越多，更為豐富。更多的資源元素，意味著更多的下載請求。Web系統(tǒng)的交互越來越復(fù)雜，交互場景和次數(shù)也大幅增加。以“www.qq.com”的首頁為例子，刷新一次，大概會有244個(gè)請求。并且，在頁面打開完成之后，還會有一些定時(shí)的查詢或者上報(bào)請求持續(xù)運(yùn)作。

目前的Http請求，為了減少反復(fù)的創(chuàng)建和銷毀連接行為，通常都建立長連接（Connection keep-alive）。一經(jīng)建立，這個(gè)連接會被保持住一段時(shí)間，被后續(xù)請求復(fù)用。然而，它也帶來了另一個(gè)新的問題，連接的保持是會占用Web系統(tǒng)服務(wù)端資源的，如果不充分使用這個(gè)連接，會導(dǎo)致資源浪費(fèi)。長連接被創(chuàng)建后，首批資源傳輸完畢，之后幾乎沒有數(shù)據(jù)交互，一直到超時(shí)時(shí)間，才會自動(dòng)釋放長連接占據(jù)的系統(tǒng)資源。

除此之外，還有一些Web需求本身就需要長期保持連接的，例如Web socket。

2. 主流的本瀏覽器的連接數(shù)在增加

面對越來越豐富的Web資源，主流瀏覽器并發(fā)連接數(shù)也在增加，同一個(gè)域下，早期的瀏覽器一般只有1-2個(gè)下載連接，而目前的主流瀏覽器通常在2-6個(gè)。增加瀏覽器并發(fā)連接數(shù)目，在需要下載資源比較多的場景下，可以加快頁面的加載速度。更多的連接對瀏覽器加載頁面元素是有好處的，在某些連接遭遇“網(wǎng)絡(luò)阻塞”的情況下，其他正常的下載連接可以繼續(xù)工作。

這樣自然無形增加了Web系統(tǒng)后端的壓力，更多的下載連接意味著占據(jù)了更多的Web服務(wù)器的資源。而在用戶訪問高峰期，自熱而然就形成了“高并發(fā)”場景。這些連接和請求，占據(jù)了服務(wù)器的大量CPU和內(nèi)存等資源。尤其在資源數(shù)目超過100+的網(wǎng)站頁面中，使用更多的下載連接，非常有必要。

二、Web前端優(yōu)化，降低服務(wù)端壓力

在緩解“高并發(fā)”的壓力，需要前端和后端的共同配合優(yōu)化，才能達(dá)到最大效果。在用戶第一線的Web前端，可以起到減少或者減輕Http請求的效果。

1. 減少Web請求

常用的實(shí)現(xiàn)方法是通過Http協(xié)議頭中的expire或max-age來控制，將靜態(tài)內(nèi)容放入瀏覽器的本地緩存，在之后的一段時(shí)間里，不再請求Web服務(wù)器，直接使用本地資源。還有HTML5中的本地存儲技術(shù)（LocalStorage），也被作為一個(gè)強(qiáng)大的數(shù)據(jù)本地緩存。

這種方案緩存后，根本不發(fā)送請求到Web服務(wù)器，大幅降低服務(wù)器壓力，也帶來了良好的用戶體驗(yàn)。但是，這種方案，對首次訪問的用戶無效，同時(shí)，也影響部分Web資源的實(shí)時(shí)性。

2. 減輕Web請求

瀏覽器的本地緩存是存在過期時(shí)間的，一旦過期，就必須重新向服務(wù)器請求。這個(gè)時(shí)候，會有兩種情形：

（1）服務(wù)器的資源內(nèi)容沒有更新，瀏覽器請求Web資源，服務(wù)器回復(fù)“可以繼續(xù)使用本地緩存”。（發(fā)生通信，但是Web服務(wù)器只需要做簡單“回復(fù)”）

（2）服務(wù)器的文件或者內(nèi)容已經(jīng)更新，瀏覽器請求Web資源，Web服務(wù)器通過網(wǎng)絡(luò)傳輸新的資源內(nèi)容。（發(fā)生通信，Web服務(wù)器需要完成復(fù)雜的傳輸工作）

這里的協(xié)商方式是通過Http協(xié)議的Last-Modified或Etag來控制，這個(gè)時(shí)候請求服務(wù)器，如果是內(nèi)容沒有發(fā)生變更的情況，服務(wù)器會返回304 Not Modified。這樣的話，就不需要每次請求Web服務(wù)器都做復(fù)雜的傳輸完整數(shù)據(jù)文件的工作，只要簡單的http應(yīng)答就可以達(dá)到相同的效果。

雖然上述請求，起到“減輕”Web服務(wù)器的壓力，但是連接仍然被建立，請求也發(fā)生了。

3. 合并頁面請求

如果是比較老一些的Web開發(fā)者，應(yīng)該會更有印象，在ajax盛行之前。頁面大部分都是直接輸出的，并沒有這么多的ajax請求，Web后端將頁面內(nèi)容完全拼湊好了，再返回給前端。那個(gè)時(shí)候，頁面靜態(tài)化，是一個(gè)挺廣泛的優(yōu)化方式。后來，被交互更友好的ajax漸漸替代了，一個(gè)頁面的請求也變得越來越多。

由于移動(dòng)端的網(wǎng)絡(luò)（2G/3G）比起PC寬帶差很多，并且部分手機(jī)配置比較低，面對一個(gè)超過100個(gè)請求的網(wǎng)頁，加載的速度會緩慢很多。于是，優(yōu)化的方向又重新回到合并頁面元素，減少請求數(shù)量：

（1）合并HTML展示內(nèi)容。將CSS和JS直接嵌入到HTML頁面內(nèi)，不通過連接的方式引入。

（2）Ajax動(dòng)態(tài)內(nèi)容合并請求。對于動(dòng)態(tài)內(nèi)容，將10次Ajax請求合并為1次的批量信息查詢。

（3）小圖片合并，通過CSS的偏移量技術(shù)Sprites，將很多小圖片合并為一張。這個(gè)優(yōu)化方式，在PC端的Web優(yōu)化中，也非常常見。

合并請求，減少了傳輸數(shù)據(jù)的次數(shù)，也就是相當(dāng)于將它們從一個(gè)一個(gè)地請求，變?yōu)橐淮蔚?#8220;批量”請求。上述優(yōu)化方法，到達(dá)“減輕”Web服務(wù)器壓力的目的，減少了需要建立的連接。

三、 節(jié)約Web服務(wù)端的內(nèi)存

前端的優(yōu)化完成，我們就需要著眼于Web服務(wù)端本身。內(nèi)存是Web服務(wù)器非常重要的資源，更多的內(nèi)存通常意味著可以同時(shí)放入更多的工作任務(wù)。就Web服務(wù)占用內(nèi)存而言，可以粗略劃分：

（1）用來維持連接的基本內(nèi)存，進(jìn)程初始化時(shí)，會載入一些基礎(chǔ)模塊到內(nèi)存。

（2）被傳輸?shù)臄?shù)據(jù)內(nèi)容載入到各個(gè)緩沖區(qū)，占據(jù)的內(nèi)存。

（3）程序執(zhí)行過程中，申請和使用的內(nèi)存。

如果維持一個(gè)連接，能夠盡可能少占用內(nèi)存，那么我們就可以維持更多的并發(fā)連接，從而讓W(xué)eb服務(wù)器支持更多的并發(fā)連接數(shù)。

Apache（httpd）是一個(gè)成熟并且古老的Web服務(wù)，而Apache的發(fā)展和演變，一直在追求做到這一點(diǎn)，它試圖不斷減少服務(wù)占據(jù)的內(nèi)存，以支持更大的并發(fā)量。以Apache的工作模式的演變?yōu)橐暯牵覀円黄饋砜纯矗鼈兪侨绾蝺?yōu)化內(nèi)存的問題的。

1. prefork MPM，多進(jìn)程工作模式

prefork是Apache最成熟和穩(wěn)定的工作模式，即使是現(xiàn)在，仍然被廣泛使用。主進(jìn)程生成后，它先完成基礎(chǔ)的初始化工作，然后，通過fork預(yù)先產(chǎn)生一批的子進(jìn)程（子進(jìn)程會復(fù)制父進(jìn)程的內(nèi)存空間，不需要再做基礎(chǔ)的初始化工作）。然后等待服務(wù)，之所以預(yù)先生成，是為了減少頻繁創(chuàng)建和銷毀進(jìn)程的開銷。多進(jìn)程的好處，是進(jìn)程之間的內(nèi)存數(shù)據(jù)不會相互干擾，同時(shí)，某個(gè)進(jìn)程異常終止也不會影響其他進(jìn)程。但是，就內(nèi)存而言，每個(gè)httpd子進(jìn)程占用了很多的內(nèi)存，因?yàn)樽舆M(jìn)程的內(nèi)存數(shù)據(jù)是復(fù)制父進(jìn)程的。我們可以粗略認(rèn)為，這里存在大量的“重復(fù)數(shù)據(jù)”被放在內(nèi)存中。最終，導(dǎo)致我們能夠生成的子進(jìn)程最大數(shù)量是很有限。在面對高并發(fā)時(shí)，因?yàn)橛胁簧貹eep-alive的長連接，將這些子進(jìn)程“霸占”住，很可能導(dǎo)致可用子進(jìn)程耗盡。因此，prefork并不太適合高并發(fā)場景。

• 優(yōu)點(diǎn)：成熟穩(wěn)定，兼容所有新老模塊。同時(shí)，不需要擔(dān)心線程安全的問題。（例如，我們常用的mod_php，將PHP編譯為Apache的子模塊，就不需要支持線程安全）
• 缺點(diǎn)：一個(gè)服務(wù)進(jìn)程占用很多內(nèi)存。

2. worker MPM，多進(jìn)程和多線程的混合模式

worker模式比起prefork，是使用了多進(jìn)程和多線程的混合模式。它也預(yù)先fork了幾個(gè)子進(jìn)程（數(shù)量很少），然后每個(gè)子進(jìn)程創(chuàng)建一些線程（其中包括一個(gè)監(jiān)聽線程）。每個(gè)請求過來，會被分配到1個(gè)線程來服務(wù)。線程比起進(jìn)程會更輕量，因?yàn)榫€程通常會共享父進(jìn)程的內(nèi)存空間，因此，內(nèi)存的占用會減少一些。在高并發(fā)的場景下，因?yàn)楸绕餻refork更省內(nèi)存，因此會有更多的可用線程。

但是，它并沒有解決Keep-alive的長連接“霸占”線程的問題，只是對象變成了比較輕量的線程。

有些人會覺得奇怪，那么這里為什么不完全使用多線程呢，還要引入多進(jìn)程？因?yàn)檫€需要考慮穩(wěn)定性，如果一個(gè)線程掛了，會導(dǎo)致同一個(gè)進(jìn)程下其他正常的子線程都掛了。如果全部采用多線程，某個(gè)線程掛掉，就導(dǎo)致整個(gè)Apache服務(wù)“全軍覆沒”。而目前的工作模式，受影響的只是Apache的一部分服務(wù)，而不是整個(gè)服務(wù)。

線程共享父進(jìn)程的內(nèi)存空間，減少了內(nèi)存的占用，卻又引起了新的問題。就是“線程安全”，多個(gè)線程修改共享資源導(dǎo)致的“競爭行為”，又強(qiáng)迫我們所使用的模塊必須支持“線程安全”。因此，它有一定程度上增加Web服務(wù)的不穩(wěn)定性。例如，mod_php所使用的PHP拓展，也同樣需要支持“線程安全”，否則，不能在該模式下使用。

• 優(yōu)點(diǎn)：占據(jù)更少的內(nèi)存，高并發(fā)下表現(xiàn)更優(yōu)秀。
• 缺點(diǎn)：必須考慮線程安全的問題，同時(shí)鎖的引入又增加了CPU的開銷。

3. event MPM，多進(jìn)程和多線程的混合模式，引入Epoll

這個(gè)是Apache中比較新的模式，在現(xiàn)在的版本（Apache 2.4.10）已經(jīng)是穩(wěn)定可用的模式。它和worker模式很像，最大的區(qū)別在于，它解決了keep-alive場景下，長期被占用的線程的資源浪費(fèi)問題。event MPM中，會有一個(gè)專門的線程來管理這些keep-alive類型的線程，當(dāng)有真實(shí)請求過來的時(shí)候，將請求傳遞給服務(wù)線程，執(zhí)行完畢后，又允許它釋放。它減少了“占據(jù)”連接而又不使用的資源浪費(fèi)，增強(qiáng)了高并發(fā)場景下的請求處理能力。因?yàn)闇p少了“閑等”的線程，線程的數(shù)量減少，同等場景下，內(nèi)存占用會下降一些。

event MPM在遇到某些不兼容的模塊時(shí)，會失效，將會回退到worker模式，一個(gè)工作線程處理一個(gè)請求。新版Apache官方自帶的模塊，全部是支持event MPM的。注意一點(diǎn)，event MPM需要Linux系統(tǒng)（Linux 2.6+）對EPoll的支持，才能啟用。Apache的三種模式中在真實(shí)應(yīng)用場景中，event MPM是最節(jié)約內(nèi)存的。

4. 使用比較輕量的Nginx作為Web服務(wù)器

雖然Apache的不斷優(yōu)化，減少了內(nèi)存占用，從而增加了處理高并發(fā)的能力。但是，正如前面所說，Apache是一個(gè)古老而成熟的Web服務(wù)，同時(shí)，集成很多穩(wěn)定的模塊，是一個(gè)比較重的Web服務(wù)。Nginx是個(gè)比較輕量的Web服務(wù)，占據(jù)的內(nèi)存天然就少于Apache。而且，Nginx通過一個(gè)進(jìn)程來服務(wù)于N個(gè)連接。所使用的方式，并不是Apache的增加進(jìn)程/線程來支持更多的連接。對于Nginx來說，它少創(chuàng)建了大量的進(jìn)程/線程，減少了很多內(nèi)存的開銷。

靜態(tài)文件的QPS性能壓測結(jié)果，Nginx性能大概3倍于Apache對靜態(tài)文件的處理。PHP等動(dòng)態(tài)文件的QPS，Nginx的做法通常是通過FastCGI的方式和PHP-FPM通信的方式完成，PHP作為一個(gè)與之無關(guān)的外部服務(wù)存在。而Apache通常將PHP編譯為自己的字模塊（新版的Apache也支持FastCGI）。PHP動(dòng)態(tài)文件，Nginx的表現(xiàn)略遜于Apache。

5. sendfile節(jié)約內(nèi)存

Apache、Nginx等不少Web服務(wù)，都帶有sendfile支持的。sendfile可以減少數(shù)據(jù)到“用戶態(tài)內(nèi)存空間”（用戶緩沖區(qū)）的拷貝，進(jìn)而減少內(nèi)存的占用。當(dāng)然，很多同學(xué)第一個(gè)反應(yīng)當(dāng)然是問Why？為了盡可能清楚講述這個(gè)原理，我們就先回Linux內(nèi)核態(tài)和用戶態(tài)的存儲空間的交互。

一般情況下，用戶態(tài)（也就是我們的程序所在的內(nèi)存空間）是不會直接讀寫或者操作各種設(shè)備（磁盤、網(wǎng)絡(luò)、終端等），中間通常用內(nèi)核作為“中間人”，來完成對設(shè)備的操作或者讀寫。

以最簡單的磁盤讀寫例子，從磁盤中讀取A文件，寫入到B文件。A文件數(shù)據(jù)是從磁盤開始，然后載入到“內(nèi)核緩沖區(qū)”，然后再拷貝到“用戶緩沖區(qū)”，我們才可以對數(shù)據(jù)進(jìn)行處理。寫入的時(shí)候，也同理，從“用戶態(tài)緩沖區(qū)”載入到“內(nèi)核緩沖區(qū)”，最后寫入到磁盤B文件。

這樣寫文件很累吧，于是有人覺得這里可以跳過“用戶緩沖區(qū)”的拷貝。其實(shí)，這就是MMP（Memory-Mapping，內(nèi)存映射）的實(shí)現(xiàn)，建立一個(gè)磁盤空間和內(nèi)存的直接映射，數(shù)據(jù)不再復(fù)制到“用戶態(tài)緩沖區(qū)”，而是返回一個(gè)指向內(nèi)存空間的指針。于是，我們之前的讀寫文件例子，就會變成，A文件數(shù)據(jù)從磁盤載入到“內(nèi)核緩沖區(qū)”，然后從“內(nèi)核緩沖區(qū)”復(fù)制到B文件的“內(nèi)核緩沖區(qū)”，B文件再從”內(nèi)核緩沖區(qū)“寫回到磁盤中。這個(gè)過程，減少了一次內(nèi)存拷貝，同時(shí)也少內(nèi)存占用。

好了，回到sendfile的話題上來，簡單的說，sendfile的做法和MMP類似，就是減少數(shù)據(jù)從”內(nèi)核態(tài)緩沖區(qū)“到”用戶態(tài)緩沖區(qū)“的內(nèi)存拷貝。

默認(rèn)的磁盤文件讀取，到傳輸給socket，流程（不使用sendfile）是：

使用sendfile之后：

這種方式，不僅節(jié)省了內(nèi)存，而且還有CPU的開銷。

四、節(jié)約Web服務(wù)器的CPU

對Web服務(wù)器而言，CPU是另一個(gè)非常核心的系統(tǒng)資源。雖然一般情況下，我們認(rèn)為業(yè)務(wù)程序的執(zhí)行消耗了我們主要CPU。但是，就Web服務(wù)程序而言，多線程/多進(jìn)程的上下文切換，也是比較消耗CPU資源的。一個(gè)進(jìn)程/線程通常不能長期占有CPU，當(dāng)發(fā)生阻塞或者時(shí)間片用完，就無法繼續(xù)占用CPU，這個(gè)時(shí)候，就會發(fā)生上下文切換，CPU時(shí)間片從老進(jìn)程/線程切換到新的。除此之外，在并發(fā)連接數(shù)目很高的場景下，對這些用戶建立的連接（socket文件描述符）狀態(tài)的輪詢和檢測，也是比較消耗CPU的。

而Apache和Nginx的發(fā)展和演變，也在努力減少CPU開銷。

1. Select/Poll（Apache早期版本的I/O多路復(fù)用）

通常，Web服務(wù)都要維護(hù)很多個(gè)和用戶通信的socket文件描述符，I/O多路復(fù)用，其實(shí)就是為了方便對這些文件描述符的管理和檢測。Apache早期版本，是使用select的模式，簡單的說，就是將這些我們關(guān)注的socket文件描述符交給內(nèi)核，讓內(nèi)核告訴我們，那些描述符可操作。Poll與select原理基本相同，因此放在一起，它們之間的區(qū)別，就不贅敘了哈。

select/poll返回的是一個(gè)我們之前提交的文件描述符集合（內(nèi)核將其中可讀、可寫或者異常狀態(tài)的socket文件描述符的標(biāo)識位修改了），我們需要通過輪詢檢查才能獲得我們可以操作的文件描述符。在這個(gè)過程中，不斷重復(fù)執(zhí)行。在實(shí)際應(yīng)用場景中，大部分被我們監(jiān)控的socket文件描述符，都是”空閑的“，也就是說，不能操作。我們對整個(gè)集合輪詢，就是為了找了少部分我們可以操作的socket文件描述符。于是，當(dāng)我們監(jiān)控的socket文件描述符越多（用戶并發(fā)連接數(shù)越來越多），這個(gè)輪詢工作，也就越來越沉重，進(jìn)而導(dǎo)致增大了CPU的開銷。

如果我們監(jiān)控的socket文件描述符，幾乎都是”活躍的“，反而使用這種模式更合適一點(diǎn)。

2. Epoll（新版的Apache的event MPM，Nginx等支持）

Epoll是Linux2.6開始正式支持的I/O多路復(fù)用，我們可以理解為它是對select/poll的改進(jìn)。首先，我們同樣將我們關(guān)注的socket文件描述符集合告訴給內(nèi)核，同時(shí)，給它們注冊”回調(diào)函數(shù)“，如果某個(gè)socket文件準(zhǔn)備好了，就通過回調(diào)函數(shù)通知我們。于是，我們就不需要專門去輪詢整個(gè)全量的socket文件描述符集合，直接可以得到已經(jīng)可操作的socket文件描述符。那么，那些大部分”空閑“的描述符，我們就不遍歷了。即使我們監(jiān)控的socket文件描述越來越多，我們輪詢的也只是”活躍可操作“的socket文件描述符。

其實(shí)，有一種極端點(diǎn)的場景，就是我們?nèi)课募枋龇麕缀醵际?#8221;活躍“的，這樣反而導(dǎo)致了大量回調(diào)函數(shù)的執(zhí)行，又增加了CPU的開銷。但是，就Web服務(wù)的真實(shí)場景，絕大部分時(shí)候，都是連接集合中都存在很多”空閑“連接。

3. 線程/進(jìn)程的創(chuàng)建銷毀和上下文切換

通常，Apache某一個(gè)時(shí)間內(nèi)，是一個(gè)進(jìn)程/線程服務(wù)于一個(gè)連接。于是，Apache就有很多的進(jìn)程/線程，服務(wù)于很多的連接。Web服務(wù)在高峰期，會建立很多的進(jìn)程/線程，也就帶來很多的上下文切換開銷。而Nginx，它通常只有1個(gè)master主進(jìn)程和幾個(gè)worker子進(jìn)程，然后，1個(gè)worker進(jìn)程服務(wù)很多個(gè)連接，進(jìn)而節(jié)省了CPU的上下文切換開銷。

兩種模式雖然不同，但實(shí)際上不能直接出分好壞，綜合來說，各有各自的優(yōu)勢，就不妄議了哈。

4. 多線程下的鎖對CPU的開銷

Apache中的worker和event模式，都有采用多線程。多線程因?yàn)楣蚕砀高M(jìn)程的內(nèi)存空間，在訪問共享數(shù)據(jù)的時(shí)候，就會產(chǎn)生競爭，也就是線程安全問題。因此通常會引入鎖（Linux下比較常用的線程相關(guān)的鎖有互斥量metux，讀寫鎖rwlock等），成功獲取鎖的線程可以繼續(xù)執(zhí)行，獲取失敗的通常選擇阻塞等待。引入鎖的機(jī)制，程序的復(fù)雜度往往增加不少，同時(shí)還有線程“死鎖”或者“餓死”的風(fēng)險(xiǎn)（多進(jìn)程在訪問進(jìn)程間共享資源的時(shí)候，也有同樣的問題）。

死鎖現(xiàn)象（兩個(gè)線程彼此鎖住對方想要獲取的資源，相互阻塞等待，永遠(yuǎn)無法達(dá)不到滿足條件）：

餓死現(xiàn)象（某個(gè)線程，一直獲取不到它想要鎖資源，永遠(yuǎn)無法執(zhí)行下一步）：

為了避免這些鎖導(dǎo)致的問題，就不得不加大程序的復(fù)雜度，解決方案一般有：

（1）對資源的加鎖，根據(jù)約定好的順序，大家都先對共享資源X加鎖，加鎖成功之后才能加鎖共享資源Y。

（2）如果線程占有資源X，卻加鎖資源Y失敗，則放棄加鎖，同時(shí)也釋放掉之前占有的資源X。

在使用PHP的時(shí)候，在Apache的worker和event模式下，也必須兼容線程安全。通常，新版本的PHP官方庫是沒有線程安全方面的問題，需要關(guān)注的是第三方擴(kuò)展。PHP實(shí)現(xiàn)線程安全，不是通過鎖的方式實(shí)現(xiàn)的。而是為每個(gè)線程獨(dú)立申請一份全局變量的副本，相當(dāng)于線程的私人內(nèi)存空間，但是這樣做相對消耗多一些內(nèi)存。不過，這樣的好處，是不需要引入復(fù)雜的鎖機(jī)制實(shí)現(xiàn)，也避免了鎖機(jī)制對CPU的開銷。

這里順便提到一下，經(jīng)常和Nginx搭配工作的PHP-FPM（FastCGI）使用的是多進(jìn)程，因此不會有線程安全的問題。

五、 小結(jié)

可能有些同學(xué)看完之后，會得出結(jié)論，Nginx+PHP-FPM的工作方式，似乎是最節(jié)省系統(tǒng)資源的Web系統(tǒng)工作方式。某種程度上說，的確是可以這么說的，但是Web系統(tǒng)的搭建，需要從實(shí)際業(yè)務(wù)應(yīng)用的角度出發(fā)，具體問題需要具體分析，尋求最合適的技術(shù)方案。

Web服務(wù)的不斷演變和發(fā)展，努力地追求用盡可能少的系統(tǒng)資源，來支撐更多的用戶請求，這是一條波瀾壯闊的前進(jìn)之路。這些技術(shù)方案，匯聚了很多值得學(xué)習(xí)和借鑒的解決問題的思路。