初次接觸Python部署問題解析
在這部分開始之前我也想聊聊之前我們一直在講，而且將來還一直會(huì)講下去的一個(gè)話題――狀態(tài)。 之前我們一直在討論，把用戶的狀態(tài)保存在一個(gè)集中的地方，尤其是大規(guī)模集群Python部署的情況下。
同樣，對(duì)于django來說亦是如此，可以說這條金科玉律不只是針對(duì)某種針對(duì)某個(gè)語言，某個(gè)框架，它應(yīng)該是更高層次的一種理念。那么我們可以把狀態(tài)放到什么地方呢，目前一些流行的選擇是DB(內(nèi)存表，或?qū)嶓w表),memcached，或者cookie。
但這幾種選擇并不是可以隨便互換的，比如業(yè)務(wù)數(shù)據(jù)較多的情況下，放在cookie中不是很合適，因?yàn)橛锌赡艹鯿ookie大小的限制，那么放在memcached中，很遺憾，memcached(使用slab的情況下)中也有它自己的限制。
如果狀態(tài)數(shù)據(jù)大小跨度較大，那么丟數(shù)據(jù)的情況有可能發(fā)生，ahuaxuan很久之前在測(cè)試環(huán)境下就碰到過這種情況，由于線上memcached開得較大，所以沒有出現(xiàn)這種情況，關(guān)于這種事件發(fā)生得內(nèi)部原因在ahuaxuan的另外一篇文章中已經(jīng)有了非常詳細(xì)的描述。
那么放在DB上呢，顯然，DB的壓力也是我們需要考慮的問題之一。當(dāng)然除了這些主流的選擇之外，我們其他選擇還有很多，比如memcachedb，或者timesten，或者其他等等。但是對(duì)于狀態(tài)這種東西，尤其狀態(tài)數(shù)據(jù)比較重要的情況下，我們一定要深入研究并理解狀態(tài)數(shù)據(jù)的存儲(chǔ)技術(shù)，否則可能會(huì)遇到我們異想不到的情況。
比如很久之前我想破頭也不會(huì)想到memcached是LRU是針對(duì)某個(gè)slab的(而且我還要插一句，LRU的時(shí)候其實(shí)并不是遍歷slab中的chunk鏈表，而且只遍歷最開始的50個(gè)數(shù)據(jù)而已，這樣做純粹是為了速度)。 目前對(duì)django來說基本上有兩種Python部署策略， 第一種是利用mod_python將django運(yùn)行在apache進(jìn)程中，還有一種是webserver+fastcgi，這兩種方式各有優(yōu)缺點(diǎn)。
在mod_python模式中，我們的webserver必須使用apache，apache在webserver這一領(lǐng)域已經(jīng)獨(dú)占鰲頭很多年了，市場(chǎng)占有率也是遠(yuǎn)遠(yuǎn)的超過其他的webserver，不過近幾年來，又崛起了幾個(gè)其他的webserver，其中比較出名的是ligttpd和nginx。
它們都以高性能和低內(nèi)存消耗對(duì)apache發(fā)出了挑戰(zhàn)，而mod_python是apache的插件，使用這種方式就把我們的webserver限定在apache上了，不過還好apache+mod_python也是非常的穩(wěn)定的方案了。
第二種就是webserver＋fastcgi，這里的webserver就可以隨意選擇了，大多數(shù)的webserver對(duì)提供了對(duì)fastcgi的支持，比如我們耳熟能詳?shù)膌ighttpd和nginx，而且據(jù)稱在很多情況下，F(xiàn)astCGI能夠提供比mod_python更為優(yōu)越的安全性和效能。
針對(duì)小型站點(diǎn)，相對(duì)于Apache來說FastCGI更為輕量級(jí)。據(jù)稱qq的個(gè)人空間就是c++加fastcgi實(shí)現(xiàn)的，哦，這樣做的優(yōu)勢(shì)在哪里呢，c++的處理速度將會(huì)非常的快，也就是說每個(gè)fastcgi處理一個(gè)請(qǐng)求將會(huì)非常快速。
比如使用python需要50毫秒，c++處理這個(gè)請(qǐng)求有可能只需要20毫秒（這個(gè)例子未必準(zhǔn)確，只是為了說明fastcgi的特性），雖然在開發(fā)上c++比較麻煩一點(diǎn)，不過在性能上，c++肯定是no1了，從這個(gè)例子上我們可以看到，使用fastcgi速度取決于處理一次請(qǐng)求的速度（廢話，哪個(gè)不是這樣）。
我們來看一下使用fastcgi的一般模式：
1、WEB服務(wù)器收到客戶端的頁面請(qǐng)求
2、WEB服務(wù)器將這個(gè)頁面請(qǐng)求委派給一個(gè)FastCGI 外部進(jìn)程（WEB服務(wù)器于FastCGI之間是通過socket來連接通訊的）
3、FastCGI外部進(jìn)程得到WEB服務(wù)器委派過來的頁面請(qǐng)求信息后進(jìn)行處理，并且將處理結(jié)果（動(dòng)態(tài)頁面內(nèi)容）返回給WEB服務(wù)器
4、Web服務(wù)器將FastCGI返回回來的結(jié)果再轉(zhuǎn)送給客戶端瀏覽器。
對(duì)我們來說第3步是我們最需要關(guān)注的，因?yàn)榈?步的速度嚴(yán)重影響著整個(gè)性能。由于fastcgi是基于進(jìn)程的，所以，我們要根據(jù)我們的應(yīng)用來開啟數(shù)量合適的fastcgi進(jìn)程。多開了是對(duì)資源的浪費(fèi)。
少開了就影響性能，這個(gè)類似我們?cè)?FONT>Python部署中開啟處理請(qǐng)求的thread一樣，只不過tomcat中的request handler thread在配置起來顯然更加方便，因?yàn)槲覀冎灰P(guān)注線程池中最大的可以容納的線程數(shù)，最大空閑線程數(shù)等就行了。
【編輯推薦】
