在介紹mod_python模式之前先像大家說一下它的定義，mod_python模式標(biāo)志了物件之間隱藏的規(guī)律關(guān)系，而這些物件并不必然是圖像、圖案，也可以是數(shù)字、抽象的關(guān)系、甚至思維的方式。

在這部分開始之前我也想聊聊之前我們一直在講，而且將來還一直會(huì)講下去的一個(gè)話題――狀態(tài)。 之前我們一直在討論，把用戶的狀態(tài)保存在一個(gè)集中的地方，尤其是大規(guī)模集群部署的情況下。

同樣，對(duì)于python來說亦是如此，可以說這條金科玉律不只是針對(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來說基本上有兩種部署策略， 第一種是利用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上了，不過還好mod_python模式也是非常的穩(wěn)定的方案了。

第二種就是webserver＋fastcgi，這里的webserver就可以隨意選擇了，大多數(shù)的webserver對(duì)提供了對(duì)fastcgi的支持，比如我們耳熟能詳?shù)膌ighttpd和nginx，而且據(jù)稱在很多情況下。FastCGI能夠提供比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ì)非?？焖?，比如使用mod_python模式需要50毫秒，c++處理這個(gè)請(qǐng)求有可能只需要20毫秒（這個(gè)例子未必準(zhǔn)確，只是為了說明fastcgi的特性）。雖然在開發(fā)上c++比較麻煩一點(diǎn)，不過在性能上，c++肯定是no1了，從這個(gè)例子上我們可以看到，使用fastcgi速度取決于處理一次請(qǐng)求的速度（廢話，哪個(gè)不是這樣）。 #t#

我們來看一下使用fastcgi的一般模式：1、WEB服務(wù)器收到客戶端的頁(yè)面請(qǐng)求 2、WEB服務(wù)器將這個(gè)頁(yè)面請(qǐng)求委派給一個(gè)FastCGI 外部進(jìn)程（WEB服務(wù)器于FastCGI之間是通過socket來連接通訊的） 3、FastCGI外部進(jìn)程得到WEB服務(wù)器委派過來的頁(yè)面請(qǐng)求信息后進(jìn)行處理，并且將處理結(jié)果（動(dòng)態(tài)頁(yè)面內(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è)趖omcat中開啟處理請(qǐng)求的thread一樣，只不過tomcat中的request handler thread在配置起來顯然更加方便，因?yàn)槲覀冎灰P(guān)注線程池中最大的可以容納的線程數(shù)，最大空閑線程數(shù)等就行了。