从奥运订票系统说起——谈FastCGI 与IT 架构
2008年，對(duì)于首都人民來(lái)說(shuō)，沒(méi)有什么比奧運(yùn)會(huì)更大的事情了。如何買(mǎi)到一張稱(chēng)心如意的比賽門(mén)票，也成了很多人的一個(gè)夢(mèng)想。然而，在奧運(yùn)官網(wǎng)搶票購(gòu)買(mǎi)的時(shí)候，這個(gè)夢(mèng)想?yún)s輕易地被網(wǎng)上購(gòu)票系統(tǒng)的當(dāng)機(jī)擊成碎片，很多充滿(mǎn)熱情的老百姓們也因此郁悶無(wú)比。由于搜狐承擔(dān)了奧運(yùn)的官網(wǎng)，我又在那里工作過(guò)相當(dāng)長(zhǎng)一段時(shí)間，很多兄弟搶票失敗，于是便認(rèn)定是搜狐開(kāi)發(fā)的系統(tǒng)太爛，而找我抱怨。其實(shí)當(dāng)時(shí)我也很是郁悶：首先這個(gè)系統(tǒng)并非搜狐開(kāi)發(fā)；其次我也不在搜狐了。雖然如此，和我同行的一些朋友，又開(kāi)始問(wèn)我如何解決類(lèi)似問(wèn)題。我也反反復(fù)復(fù)講了很多次，為了讓廣大讀者能夠深入了解背后的原因和機(jī)制，寫(xiě)出來(lái)，大家一起討論可能效果會(huì)更好。當(dāng)然，這并不是我說(shuō)的架構(gòu)就一定能解決問(wèn)題，僅僅是拋磚引玉而已。
??? 在說(shuō)架構(gòu)之前，我先說(shuō)一個(gè)老的技術(shù)，FastCGI。因?yàn)檫@個(gè)技術(shù)在后面的結(jié)構(gòu)闡述中將起到非常重要的用處，原以為應(yīng)該會(huì)有不少人會(huì)知道，但后來(lái)發(fā)現(xiàn)好像并非如此。
???關(guān)于FastCGI的歷史我就不再贅述，好像自1993年便有了。目前最熱門(mén)的視頻網(wǎng)站YouTube體系結(jié)構(gòu)中，就有fast-cgi的模塊。它支持很多httpd服務(wù)器，在官方網(wǎng)站上列了很多，如apache，aXesW3 ，MicrosoftIIS，Zeus，近幾年才出的lighttpd沒(méi)寫(xiě)，其實(shí)這個(gè)新的httpd也支持，但我個(gè)人覺(jué)得，支持最好的，可能還是Apache。
??? 先講講FastCGI的原理，它和現(xiàn)在常用的運(yùn)行請(qǐng)求不同，維基百科上有一個(gè)術(shù)語(yǔ)形容它，這里借用一下：
◆? 短生存期應(yīng)用程序
◆? 長(zhǎng)生存期應(yīng)用程序
??? CGI技術(shù)的機(jī)制是：每次當(dāng)客戶(hù)請(qǐng)求一個(gè)CGI的時(shí)候，Web服務(wù)器就請(qǐng)求操作系統(tǒng)生成一個(gè)新的CGI進(jìn)程；當(dāng)CGI滿(mǎn)足要求后，服務(wù)器就殺死這個(gè)進(jìn)程。并且服務(wù)器對(duì)客戶(hù)端的每個(gè)請(qǐng)求都要重復(fù)這樣的過(guò)程。
??? 而FastCGI技術(shù)的機(jī)制為：FastCGI程序一旦產(chǎn)生后，它可以持續(xù)工作，一直保持滿(mǎn)足客戶(hù)的請(qǐng)求直到自己被明確終止。如果你希望通過(guò)協(xié)同處理來(lái)提高程序的性能，你可以請(qǐng)求Web服務(wù)器運(yùn)行多個(gè)FastCGI 應(yīng)用程序。
??? 由此CGI就是所謂的短生存期應(yīng)用程序，FastCGI就是所謂的長(zhǎng)生存期應(yīng)用程序。
??? 由于FastCGI程序并不需要不斷產(chǎn)生新進(jìn)程，可以大大降低服務(wù)器的壓力。并且產(chǎn)生較高的應(yīng)用效率。如今，流行的Java語(yǔ)言Servlet技術(shù)，在設(shè)計(jì)上就是參考FastCGI技術(shù)。
FastCGI 配置運(yùn)行一般來(lái)說(shuō)分三種，這三種都需要Apache的mod_fastcgi 進(jìn)行處理。
1、Standalone FastCGI Server， 應(yīng)該是獨(dú)立的服務(wù)器。首先是需要把fastcgi作為單獨(dú)的守護(hù)進(jìn)程：
?
$ script/myapp_fastcgi.pl -l /tmp/myapp.socket -n 5
?
以下是這個(gè)fastcgi的守護(hù)進(jìn)程的參數(shù)：
-d -daemon #作為守護(hù)進(jìn)程
-p -pidfile #管理進(jìn)程的PID寫(xiě)入到到文件的名稱(chēng)
-l -listen #SOCKET的路徑，機(jī)器名:端口, 或者端口
-n -nproc #起始接受請(qǐng)求的進(jìn)程數(shù)
然后把下面的代碼加入Apache的HTTPD.CONF：
?
FastCgiExternalServer /tmp/myapp -socket /tmp/myapp.socket
Alias /myapp/ /tmp/myapp/
# Or，? 可以使用root的身份運(yùn)行?????
Alias / /tmp/myapp/
# Optionally，（使用rewrite模塊）?????
RewriteRule ^/myapp$ myapp/ [R]
然后重啟Apache就OK了
?
2、Static mode：靜態(tài)模式， 一般是用于單一確定的模式，就是在Apache 的httpd.conf 中間加上：
?
FastCgiServer /usr/local/apache/count/count.fcg -processes 1
?
Alias /c /usr/local/apache/count/count.fcg
?
此處建議再使用REWRITE的方式 重寫(xiě)整個(gè)的URL匹配， 使之看起來(lái)像一個(gè)靜態(tài)頁(yè)面。
?
RewriteRule read-(.+)-(.+)-(.+).html$ /c?id=$1&sid=$2&port=$3 [L]?
?
3、Dynamic mode：動(dòng)態(tài)模式，可以使用各種各樣的fastcgi，加入到httpd.conf中間去，比如：
AddHandler fastcgi-script .fcgi
還有一個(gè)關(guān)鍵的設(shè)置：
?
<Directory /path/to/MyApp>
?????? Options +ExecCGI
</Directory>
?
?這個(gè)配置建議放在cgi-bin? 這種類(lèi)似的目錄里面。
?? 請(qǐng)注意第二種，服務(wù)器起幾個(gè)進(jìn)程，是由-processes 1 這個(gè)參數(shù)來(lái)控制的，所以起多少你可以自己來(lái)定，我們?cè)谙旅娴囊粋€(gè)關(guān)鍵模塊中將使用這個(gè)模式。
?? 下面放一段FastCGI程序的C代碼，來(lái)說(shuō)明一下：
?
#include <fcgi_stdio.h>
#include <string.h>
?
void main(void){
int count = 0;
while(FCGI_Accept() >= 0) {
printf("Content-type:text/html ");
printf(" ");
printf("<HTML> "
"<HEAD>?
"<TITLE>FastCGI</TITLE> "
"<META http-equiv="Content-Type" "
"content="text/html;?? charset=utf-8"> <body> "?"Hello world!<br> ");
printf("Request number %d.",count++);
printf("</body></html> ”);
}
exit(0);
}
?
這是一個(gè)很簡(jiǎn)單的例子，就是簡(jiǎn)單的計(jì)數(shù)， 大家可以注意這一句：while(FCGI_Accept() >= 0)
???這就是它和普通的短周期程序最大的不同，一般CGI都是運(yùn)行完就退出了，這個(gè)FastCGI，在處理完一個(gè)請(qǐng)求完畢后，會(huì)回到初始狀態(tài)等待下一次請(qǐng)求；如果這個(gè)程序被設(shè)置成為只能啟動(dòng)一個(gè)，那么無(wú)論是否訪(fǎng)問(wèn)這個(gè)頁(yè)面，都是在前一個(gè)的基礎(chǔ)上加一，而不會(huì)又產(chǎn)生新的進(jìn)程；從而后來(lái)者是從零開(kāi)始。當(dāng)然，很多人也都注意到，此處就是一個(gè)死循環(huán)在不斷處理；如果程序比較復(fù)雜，存在內(nèi)存泄露的問(wèn)題，此處產(chǎn)生的問(wèn)題也要比普通CGI要嚴(yán)重得多，所以使用它對(duì)于程序員的要求也更高。
??? 上述方案應(yīng)該是所有的Web應(yīng)用解決方案中，執(zhí)行效率和速度最高的。官方數(shù)據(jù)是說(shuō)比一般的高15倍左右，在我的機(jī)器上測(cè)試，基本上每秒能夠處理大概2400次請(qǐng)求。
???再回到我們說(shuō)的正題：奧運(yùn)訂票系統(tǒng)的癱瘓，關(guān)于訪(fǎng)問(wèn)量，當(dāng)時(shí)的說(shuō)法是800萬(wàn)/小時(shí)，那么平均到每秒就是超過(guò)2200次。這對(duì)于訂票系統(tǒng)來(lái)說(shuō)，確實(shí)是一個(gè)非常大的考驗(yàn)。畢竟這種狀況下，數(shù)據(jù)庫(kù)是肯定承擔(dān)不住這個(gè)量級(jí)的訪(fǎng)問(wèn)了。如何進(jìn)行架構(gòu)設(shè)計(jì)，是我們都需要面對(duì)的問(wèn)題。
??? 如果設(shè)計(jì)要應(yīng)對(duì)這種高負(fù)載、高訪(fǎng)問(wèn)量的結(jié)構(gòu)，首先考慮這個(gè)系統(tǒng)的需求。其實(shí)具體過(guò)程比較簡(jiǎn)單：
1.用戶(hù)認(rèn)證
2.查看所有可以訂票的項(xiàng)目和票的數(shù)量
3.選擇項(xiàng)目，放入購(gòu)物車(chē)
4.確認(rèn)并提交訂單
5.訂單成功扣款
過(guò)程雖然簡(jiǎn)單，但其實(shí)里面的東西也不少。
???由于用戶(hù)的數(shù)據(jù)量很大，注冊(cè)用戶(hù)數(shù)百萬(wàn)以上；而且這種系統(tǒng)，登錄用戶(hù)在操作時(shí)應(yīng)該不存在普通應(yīng)用的2/8原則。在搶票的當(dāng)天，絕大部分注冊(cè)用戶(hù)都會(huì)登錄，而且時(shí)間會(huì)非常集中，所以并發(fā)會(huì)非常大。你如果預(yù)算充足，放一萬(wàn)臺(tái)服務(wù)器來(lái)做這個(gè)事情，做一個(gè)分布算法，然后每臺(tái)服務(wù)不超過(guò)十萬(wàn)個(gè)用戶(hù)，這樣你就能充分保證你的用戶(hù)感受和體驗(yàn)。可我想實(shí)際上沒(méi)有哪個(gè)公司和系統(tǒng)會(huì)這么做，即使是財(cái)大氣粗的奧組委。
???這個(gè)時(shí)候，很多人可能會(huì)想：上面提到的FastCGI這種高效率的程序就是針對(duì)類(lèi)似狀況的解決方案，其實(shí)這是很常見(jiàn)的錯(cuò)誤。我想這個(gè)訂票之所以會(huì)癱瘓，就是由于部分設(shè)計(jì)過(guò)于高效，而部分不可能那么高效的緣故。比如登錄這個(gè)模塊的效率估計(jì)就非常高，因?yàn)榈卿浿皇窃跀?shù)據(jù)庫(kù)對(duì)比一下用戶(hù)名和密碼，而且數(shù)據(jù)更新也不頻繁，完全可以用分布式數(shù)據(jù)庫(kù)來(lái)解決。但用戶(hù)登錄后，所有的壓力會(huì)全部壓在后面的功能上，從而造成系統(tǒng)的癱瘓。這個(gè)時(shí)候，由于人太多，你無(wú)論怎么高效，在執(zhí)行到后面復(fù)雜的購(gòu)買(mǎi)功能時(shí)，都會(huì)出現(xiàn)瓶頸。而如果真的放一萬(wàn)臺(tái)服務(wù)，你的數(shù)據(jù)如何分布同步，然后真的做到先來(lái)先得，會(huì)很難，如果設(shè)計(jì)的不好，和抽簽也就沒(méi)什么兩樣了。
??? 所以這個(gè)系統(tǒng)設(shè)計(jì)的策略應(yīng)該是：如何做到在保證用戶(hù)感受的情況下，合理控制進(jìn)入系統(tǒng)的人數(shù)，這樣你后面的設(shè)計(jì)和開(kāi)發(fā)的壓力會(huì)小的多，而且成本的控制非常清楚。
??? 那么剩下的做法就很清晰了：系統(tǒng)的重點(diǎn)是用戶(hù)登錄，而不是一般理解的后面購(gòu)票提交的系統(tǒng)功能。如何控制進(jìn)入的人數(shù)，我覺(jué)得不妨參考銀行的叫號(hào)方式來(lái)設(shè)計(jì)：系統(tǒng)先給用戶(hù)發(fā)號(hào)，然后當(dāng)了解到有資源空出來(lái)時(shí)，再讓用戶(hù)登錄。
?
這個(gè)結(jié)構(gòu)的重點(diǎn)就在呼號(hào)中心和序列號(hào)的分配上面。
1.?序列號(hào)分配中心，技術(shù)重點(diǎn)在于高效和唯一性。也就是說(shuō)當(dāng)用戶(hù)訪(fǎng)問(wèn)數(shù)達(dá)到海量之后，你需要非常迅速地分配唯一的序列號(hào)給登錄的用戶(hù)。這種狀況下，其他很多技術(shù)無(wú)法承擔(dān)這種需求。開(kāi)始提到的FastCGI，就是這個(gè)模式下的唯一選擇。我們?cè)陂_(kāi)始安裝的時(shí)候，就可以使用這種只起單個(gè)進(jìn)程的模式，所以分配用戶(hù)的序列號(hào)只會(huì)是唯一的。由于FastCGI的高效率，從而保證登錄的用戶(hù)可以迅速分配到一個(gè)號(hào)，然后離開(kāi)。當(dāng)然如果你還不放心的話(huà)，還可以在前面再加一個(gè)負(fù)載均衡的設(shè)備，完成對(duì)幾個(gè)不同服務(wù)器負(fù)載分配，然后每個(gè)機(jī)器加不同的步長(zhǎng)，并且起始數(shù)字不一樣。比如：如果你有2臺(tái)機(jī)器做發(fā)號(hào)工作，第一臺(tái)起始數(shù)字為1，第二臺(tái)為2，步長(zhǎng)為二，就是每次累加2，這樣用戶(hù)在不同的機(jī)器上也會(huì)得到唯一的號(hào)，而效率就能提高兩倍。
???至于記錄用戶(hù)序列號(hào)的方式，可以用cookie記錄在客戶(hù)端，然后進(jìn)行加密。用戶(hù)記錄后，進(jìn)入呼號(hào)中心，比對(duì)手里的號(hào)和前面排隊(duì)的人數(shù)，然后提示用戶(hù)前面排隊(duì)人數(shù)。比方說(shuō)，你上來(lái)就是排號(hào)在3千萬(wàn)以后了，前面有2千多萬(wàn)人，我想如果這個(gè)人頭腦正常的話(huà)，就不會(huì)說(shuō)這個(gè)系統(tǒng)太爛，只能說(shuō)自己起晚了，然后感嘆中國(guó)人實(shí)在是太多，就不會(huì)再上去反復(fù)不停地登錄。
2.?呼號(hào)中心，這里大概是最麻煩，也是最關(guān)鍵的地方。由于訂票系統(tǒng)是B/S結(jié)構(gòu)，服務(wù)器端有動(dòng)作的時(shí)候，如何通知客戶(hù)端是一個(gè)要點(diǎn)。也就是說(shuō)，當(dāng)有人訂票完畢，從系統(tǒng)中退出，此時(shí)，中控中心知道后，會(huì)通知呼號(hào)中心呼叫下一個(gè)。呼號(hào)中心如何找到應(yīng)呼叫的號(hào)碼，有兩種解決方法，具體實(shí)現(xiàn)都不妨通過(guò)AJAX的局部刷新達(dá)成。
第一種，和叫號(hào)系統(tǒng)的號(hào)進(jìn)行比對(duì)，如果發(fā)現(xiàn)匹配成功，就通知客戶(hù)端進(jìn)入系統(tǒng)。
第二種，判斷這個(gè)用戶(hù)前面的排隊(duì)數(shù)量，如果發(fā)現(xiàn)為零，就觸發(fā)進(jìn)入這個(gè)系統(tǒng)的動(dòng)作。
???還要注意一點(diǎn)，就是刷新時(shí)間長(zhǎng)短和叫號(hào)的失效問(wèn)題。時(shí)間太短，服務(wù)器壓力會(huì)很大；時(shí)間太長(zhǎng)又會(huì)容易造成這個(gè)用戶(hù)感覺(jué)沒(méi)有變化，從而感受很差。所以這個(gè)時(shí)間的設(shè)置，個(gè)人覺(jué)得在5-15秒之間調(diào)整會(huì)比較合適。然后壓力需要分?jǐn)?#xff0c;也就是叫號(hào)服務(wù)器需要設(shè)置多個(gè)。這樣的話(huà)，用戶(hù)刷新會(huì)命中不同的服務(wù)器，此時(shí)需要對(duì)數(shù)據(jù)的同步進(jìn)行特殊處理，其架構(gòu)如下：
??? 這個(gè)消息接受模塊可以有兩種模式取信息：短連接，每隔一段時(shí)間來(lái)傳遞信息；長(zhǎng)連接，就是在消息接受和中控服務(wù)器中建立一個(gè)長(zhǎng)效的消息通知機(jī)制。由于對(duì)于信息及時(shí)性的要求比較高，所以采用長(zhǎng)連接比較合適。
???消息接受模塊和中控服務(wù)器之間需要進(jìn)行序列號(hào)的交換。由于你不知道捏著這個(gè)號(hào)的用戶(hù)命中哪臺(tái)服務(wù)器，所以失效機(jī)制需要在幾個(gè)服務(wù)器上同時(shí)進(jìn)行。也就是說(shuō)，當(dāng)一個(gè)用戶(hù)退出，中控服務(wù)器知道后，開(kāi)始確認(rèn)最后一個(gè)登錄號(hào)，然后發(fā)給所有前端，前端要能保證通知到用戶(hù)，然后向用戶(hù)發(fā)出通知，說(shuō)明如果在給定次數(shù)內(nèi)用戶(hù)還不進(jìn)行登錄或者認(rèn)證，就提示后端此號(hào)失效，系統(tǒng)再分配下一個(gè)號(hào)給前端進(jìn)行通知，
??? 如果要設(shè)計(jì)得更加精巧，還可以建立前端服務(wù)器之間的消息通知機(jī)制。就是當(dāng)一臺(tái)服務(wù)器發(fā)現(xiàn)這個(gè)號(hào)在自己上面，就通知幾個(gè)前端，不再對(duì)這個(gè)號(hào)進(jìn)行判斷，盡量節(jié)約資源。
3.?中控服務(wù)器。我在開(kāi)發(fā)社區(qū)和直播間的時(shí)候，都用到了這種方式，此處也用到了。不過(guò)在這個(gè)系統(tǒng)中，中控服務(wù)器不必使用單獨(dú)的物理服務(wù)器，這里可以只是一個(gè)模塊，它的主要用途是通知這些叫號(hào)服務(wù)器。由于數(shù)據(jù)很簡(jiǎn)單，所以中控的分發(fā)比較容易，不用設(shè)計(jì)特別復(fù)雜的協(xié)議。
4.?認(rèn)證中心：唯一需要改動(dòng)的，就是判斷用戶(hù)的序列號(hào)是否可用并且是真正的號(hào)碼。
5.?購(gòu)票中心：此處有很多種分布的方法，有很多可以借鑒的結(jié)構(gòu)，這里就不贅述了。在這個(gè)架構(gòu)中，購(gòu)票唯一需要確認(rèn)的就是可以同時(shí)承擔(dān)多少人同時(shí)在線(xiàn)購(gòu)買(mǎi)
?
??? 前三個(gè)部分是這個(gè)架構(gòu)的核心部分，由于進(jìn)入的人數(shù)可以控制，后面的系統(tǒng)就還可以使用老的訂票系統(tǒng)，只用確認(rèn)同時(shí)放進(jìn)來(lái)多少人就可以，也就是窗口沒(méi)變，只是大家不再一擁而上，都是文明人，請(qǐng)排隊(duì)拿號(hào)。當(dāng)然后面的架構(gòu)還可以重新進(jìn)行優(yōu)化和設(shè)計(jì)，從而盡可能提高放進(jìn)來(lái)人的數(shù)量，在進(jìn)行設(shè)計(jì)購(gòu)票功能時(shí)還可以借鑒這方面的模式。比如：籃球是愛(ài)好觀眾比較多的運(yùn)動(dòng)，大家都想到現(xiàn)場(chǎng)看看科比同學(xué)的扣籃，進(jìn)來(lái)人后，可能大家都會(huì)一擁而上先搶這個(gè)，從而造成局部的數(shù)據(jù)癱瘓，影響整個(gè)系統(tǒng)。此時(shí)也可以在里面暗含這個(gè)模塊。買(mǎi)票的人少，拿號(hào)看不出來(lái)，拿了就能進(jìn)去；一旦人數(shù)到了極限，對(duì)不起，也請(qǐng)排隊(duì)。
??? 限制人員進(jìn)入后，未進(jìn)入的人和購(gòu)買(mǎi)的人不在同一個(gè)系統(tǒng)中，從而不會(huì)妨礙進(jìn)入的人，買(mǎi)的人也會(huì)很快解決，他們可以迅速完成訂單。提交后，系統(tǒng)發(fā)現(xiàn)這個(gè)人無(wú)法再訂其他球票的時(shí)候，就可以認(rèn)為再放一個(gè)人進(jìn)來(lái)，或者干脆做絕一點(diǎn)，馬上將其踢出去，以節(jié)約資源。
???而且，由于你可以控制進(jìn)入的用戶(hù)數(shù)量，從而系統(tǒng)其他部分的設(shè)計(jì)簡(jiǎn)單多了。多大的錢(qián)辦多少事，如果領(lǐng)導(dǎo)想快一點(diǎn)了事，預(yù)算充足，那么放入的人就多；如果心里面沒(méi)底，那么可以先放很少人進(jìn)來(lái)，或者說(shuō)大概估計(jì)一下，只放多少號(hào)，如就賣(mài)10萬(wàn)張票，那么只放50萬(wàn)個(gè)號(hào)，放完了就沒(méi)有了。用戶(hù)來(lái)晚了，連號(hào)都沒(méi)有，也只能慨嘆自己不夠及時(shí)，這樣比系統(tǒng)癱瘓要好得多。
??? 對(duì)于這個(gè)架構(gòu)，其設(shè)計(jì)重點(diǎn)就是把系統(tǒng)整體的資源處于可控的狀態(tài)。很多類(lèi)似系統(tǒng)，如：報(bào)名，考試，短時(shí)間搶購(gòu)等等實(shí)際應(yīng)用系統(tǒng)，都可以采用類(lèi)似的方式解決。好的架構(gòu)，并不是說(shuō)能解決所有的問(wèn)題，而是很清楚自己能做什么，不能做什么。
PHP的FastCGI
?PHP的FastCGI使你的所有php應(yīng)用軟件通過(guò)mod_fastci運(yùn)行，而不是mod_phpsusexec。FastCGI應(yīng)用速度很快 是因?yàn)樗麄兂志梅€(wěn)定。不必對(duì)每一個(gè)請(qǐng)求都啟動(dòng)和初始化。這使得應(yīng)用程序的開(kāi)發(fā)成為可能，否則在CGI范例是不切實(shí)際的（例如一個(gè)大型的腳本，或者一個(gè)需要 連接單個(gè)或多個(gè)數(shù)據(jù)庫(kù)的應(yīng)用）。
??? 1. FastCGI 像是一個(gè)常駐 (long-live) 型的 CGI，它可以一直執(zhí)行著，只要激活后，不會(huì)每次都要花費(fèi)時(shí)間去 fork 一次 (這是 CGI 最為人詬病的 fork-and-execute 模式)。
????2. FastCGI 可在任何平臺(tái)上使用，Netscape Enterprise 及 IIS 都有 FastCGI 的模塊可供使用，阿帕契 (Apache，以及利用 Apache 衍生出做的服務(wù)器) 上也有 mod_fastcgi 可用。
??? 3. FastCGI 支持 C/C++、Java、PHP、Python、Ruby、Perl，Tcl 等程序語(yǔ)言。
??? 4. FastCGI 的應(yīng)用程序亦兼容于 CGI。即 FastCGI 的應(yīng)用程序也可以當(dāng)成 CGI 來(lái)執(zhí)行。
??? 5. 現(xiàn)有的 CGI 程序要改寫(xiě)成 FastCGI 非常簡(jiǎn)單，最少可能只需要多加入三行程序代碼。
??? 6. FastCGI 的偵錯(cuò)方式與 CGI 大同小異，只要帶入程序所需的環(huán)境變量及參數(shù)，即可在命令列模式執(zhí)行或偵錯(cuò)。
??? 7. FastCGI 應(yīng)用程序的寫(xiě)作方式與 CGI 類(lèi)似，除了幾項(xiàng)原則要特別注意外，FastCGI 的寫(xiě)作方式跟 CGI 幾乎一樣，與學(xué)習(xí) Web Server API 比較起來(lái)， FastCGI 簡(jiǎn)單多了。
??? 8. FastCGI 支授分布式運(yùn)算 (distributed computing)，即 FastCGI 程序可以在網(wǎng)站服務(wù)器以外的主機(jī)上執(zhí)行并且接受來(lái)自其它網(wǎng)站服務(wù)器來(lái)的請(qǐng)求。
??? 好處
??? 1. PHP腳本運(yùn)行速度更快(3到30倍)。PHP解釋程序被載入內(nèi)存而不用每次需要時(shí)從存儲(chǔ)器讀取，極大的提升了依靠腳本運(yùn)行的站點(diǎn)的性能。
??? 2. 需要使用更少的系統(tǒng)資源。由于服務(wù)器不用每次需要時(shí)都載入PHP解釋程序，你可以將站點(diǎn)的傳輸速度提升很高而不必增加cpu負(fù)擔(dān)。因?yàn)閐ll文件不再每次都載入了，那么數(shù)據(jù)庫(kù)的持久連接也將可以起到它設(shè)計(jì)初的效果。
??? 3. 不需要對(duì)現(xiàn)有的代碼作任何改變。
??? 潛在問(wèn)題
??? 1. 對(duì)所有的子目錄（/home/USERNAME/public_html/php.ini）你只有一個(gè)可用的php.ini文件。這是優(yōu)化網(wǎng)站代碼所必需的。如果你需要多個(gè)php.ini文件以適應(yīng)不同的腳本需要，你可以在任何子目錄禁用PHP的快速CGI，而其余的地方則繼續(xù)有效。
??? 2. 你對(duì)PHP環(huán)境做的任何升級(jí)（如php.ini文件的改變）都有幾分鐘的延遲。這是因?yàn)闉榱烁斓乃俣?你的php.ini文件已經(jīng)被載入內(nèi)存，而不是每次需要時(shí)再?gòu)拇鎯?chǔ)器重新讀取。
總結(jié)
以上是生活随笔為你收集整理的从奥运订票系统说起——谈FastCGI 与IT 架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 手机最便宜多少钱啊？
- 下一篇： “一朝同物化”下一句是什么