最近一直在學(xué)習(xí)大型網(wǎng)站的架構(gòu)和性能優(yōu)化，瘋狂地從網(wǎng)上尋找各種可能的架構(gòu)資料，終于在InfoQ上找到2009 QCon舉辦的QCon全球企業(yè)開發(fā)大會(huì)北京站演講資料。

挑了我最喜歡的幾個(gè)大型網(wǎng)站(豆瓣、淘寶、優(yōu)酷)，先看了豆瓣的主講人洪強(qiáng)寧分享的《豆瓣網(wǎng)技術(shù)架構(gòu)變遷》。看完后有幾個(gè)感覺：

 ※ 羅馬不是一天建成的

豆瓣在5年內(nèi)經(jīng)歷了6次架構(gòu)的調(diào)整，和淘寶有得一拼啊。任何優(yōu)秀的架構(gòu)都是在不斷的問題和瓶頸中發(fā)展起來的

 ※ 總是考慮使用Memcached

應(yīng)該在系統(tǒng)架構(gòu)的第一時(shí)間就考慮使用Memcached，按照洪大師的說法。豆瓣現(xiàn)在的內(nèi)存緩存有38G。Memcached的好處地球人都知道了

 ※提防Memcached的并發(fā)訪問

Memcached雖然是劑猛藥，但也有可 能成為毒藥。特別是在高并發(fā)的情況下同時(shí)獲取一批緩存數(shù)據(jù)的時(shí)候(不知道新版本的Memcached解決這個(gè)問題沒有，當(dāng)時(shí)我第一次看到這個(gè)功能時(shí)那是激 動(dòng)得內(nèi)牛滿面啊~~~)。要知道Memcached畢竟只是個(gè)緩存工具，不是內(nèi)存數(shù)據(jù)庫。不要指望他提供什么鎖、并發(fā)控制的機(jī)制(不過它倒是提供了一個(gè)原 子操作increment，用于遞增數(shù)據(jù)，對(duì)于刷新頁面訪問量之類的比較有用)

 ※ 根據(jù)數(shù)據(jù)訪問特性合理規(guī)劃表類型

使用MySQL的數(shù)據(jù)庫，可以方便地使用不 同的存儲(chǔ)引擎對(duì)應(yīng)不同操作類型的表(貌似對(duì)于其它數(shù)據(jù)庫，還沒有這種功能。也可能是我孤陋寡聞了)。對(duì)于讀寫不平衡但并發(fā)低的情況，采用MyISAM可以 獲得較高的效率。網(wǎng)上google了一把，ISAM的意思是Indexed Sequential Access Method (有索引的順序訪問方法)，它的優(yōu)勢是速度快，支持全文搜索；但對(duì)事務(wù)支持差(PS：個(gè)人意見這個(gè)用來做數(shù)據(jù)分析或者數(shù)據(jù)挖掘最好了 ^_^)。如果是用于高并發(fā)的讀寫訪問，那么只能采用InnoDB類型的表了。

 ※ 動(dòng)靜分離

使用lighttpd具有比Apache更好的靜態(tài)文件處理功能(PS：個(gè)人見到從豆瓣的第一個(gè)版本開始到目前為止的版本，只有兩點(diǎn)是不變的：1.使用lighttpd對(duì)精通文件進(jìn)行分離，直接從FS讀取。動(dòng)態(tài)的走SCGI接口。2.使用Memcached)。

 ※ 對(duì)緩存、數(shù)據(jù)庫進(jìn)行負(fù)載均衡，例如MySQL Proxy

使用類似于Load Balance來平衡Memcached的負(fù)載。不同于Round-robin方式，采用的是hash分配。自己實(shí)現(xiàn)Hash算法(PS：這個(gè)倒是和網(wǎng)上 的多數(shù)觀點(diǎn)一樣，但緩存的東西多了，命中率總是會(huì)下降，要么擴(kuò)大內(nèi)存要么改算法，避免多次的重新分配)

 ※ 不要忽視小文件的讀寫

在豆瓣的某個(gè)發(fā)展階段，就出現(xiàn)了因?yàn)榇罅康男D片讀寫而造成大量的磁盤IO和碎片的問題。原來豆瓣一開始也是把所有圖片都放在一個(gè)目錄下啊()，后來出現(xiàn)問題后才改成1000個(gè)圖片一個(gè)目錄。要不按照洪大師的說法：一個(gè)ls就可以讓服務(wù)器掛掉。

 ※  屏蔽表名和物理表的關(guān)系

通過中間映射實(shí)現(xiàn)底層物理數(shù)據(jù)表的無縫遷移。(PS：這個(gè)只要是做過Java的都知道了，IoC，代理其實(shí)也就是這個(gè)作用)，具體的做法就是只傳一個(gè)邏輯表名進(jìn)去，后臺(tái)函數(shù)映射后解析成一個(gè)真正的物理表所在的位置，方便日后的數(shù)據(jù)遷移，只要維護(hù)這個(gè)映射表就好了

 ※ 數(shù)據(jù)復(fù)制(主從模式)是必經(jīng)階段

 當(dāng)主數(shù)據(jù)庫出現(xiàn)瓶頸時(shí)，要考慮采用數(shù)據(jù)庫 復(fù)制的方式(Master / Slave模式)，主庫負(fù)責(zé)事務(wù)性讀寫，從庫負(fù)責(zé)非事務(wù)性讀(不能有寫)。數(shù)據(jù)庫復(fù)制的形式在豆瓣的發(fā)展上發(fā)生了很多次變化，我看到的就有從單點(diǎn)的復(fù)制到 最終的跨機(jī)房復(fù)制。這一點(diǎn)可以從后面的PPT看到

 ※ 數(shù)據(jù)庫復(fù)制是存在時(shí)間延遲的

數(shù)據(jù)庫復(fù)制的延遲時(shí)間要考慮在內(nèi)，否則會(huì)出現(xiàn)當(dāng)主庫寫完后，未來得及復(fù)制到從庫就出現(xiàn)Application從從庫讀數(shù)據(jù)的情況，嚴(yán)重的話用戶每次更新數(shù)據(jù)后再刷新看到的永遠(yuǎn)都是舊的數(shù)據(jù)(緩存還沒有更新，同步的數(shù)據(jù)還在路上呢....)。

 ※ 人肉刷新緩存有時(shí)候是必要的

接上面的問題，洪大師的團(tuán)隊(duì)最終采用了“人肉刷新”---- 即在可預(yù)見的情況下，內(nèi)存中的數(shù)據(jù)更新后，主動(dòng)調(diào)用Memcached的flush()方法刷新一下緩存，先同步了緩存再說，后面的數(shù)據(jù)你就慢慢復(fù)制吧。這個(gè)只能靠程序員自己控制了....ORZ

 ※ 統(tǒng)一的Data mining入口

豆瓣的數(shù)據(jù)庫復(fù)制機(jī)制中有一個(gè)特別的“Data mining”模塊，由它負(fù)責(zé)把數(shù)據(jù)寫到主DB，再從主DB replicate到從DB，然后Data mining模塊從從DB read。這個(gè)有點(diǎn)搞不懂？這個(gè)“Data mining”到底是什么來頭？怎么所有數(shù)據(jù)都從這里寫，甚至連主DB的數(shù)據(jù)都是從這里寫進(jìn)去的？

 ※ 分離服務(wù)器

把服務(wù)器分成控制服務(wù)器、應(yīng)用服務(wù)器、代理服務(wù)器。分別對(duì)應(yīng)入口轉(zhuǎn)發(fā)，應(yīng)用請(qǐng)求，負(fù)載均衡。把數(shù)據(jù)挖掘、日志分析、爬蟲應(yīng)用之類占用帶寬，耗內(nèi)存的東西全都移到后端，放在月黑風(fēng)高，夜深人靜的時(shí)候去進(jìn)行吧。

 ※ 硬件的故障不可忽視

SCSI比SATA的穩(wěn)定性要高，花在內(nèi)存上的錢是值得的

 ※ 永遠(yuǎn)不要高估機(jī)房托管方、空間提供商的智商和責(zé)任心

比如洪大師說的：搬機(jī)器的時(shí)候不小心把你們服務(wù)器的電源線拔了之類的問題...

 ※ 如果你夠牛B，那么考慮實(shí)現(xiàn)自己的內(nèi)存數(shù)據(jù)庫和文件系統(tǒng)

例如DoubanFS、DoubanDB(貌似這是一個(gè)基于key-value的內(nèi)存數(shù)據(jù)庫，看來內(nèi)存數(shù)據(jù)庫在未來大有可為啊，該死的hibernate，該死的iBatis，該死的OR-Mapping)。

以上是豆瓣洪大師的觀點(diǎn)，加上最近看到的其它，也一并總結(jié)一下吧：

 ※ 盡可能在長事務(wù)的情況下使用異步通信，例如發(fā)送SMS、MMS到網(wǎng)關(guān)然后等待回應(yīng)

 ※ 對(duì)數(shù)據(jù)庫采用水平分區(qū)而非垂直分區(qū)以加強(qiáng)后期的擴(kuò)展性

 ※ 合理恰當(dāng)?shù)厥褂盟饕?br />
 ※ 在高層次的地方使用緩存，而不要在低層次的地方使用緩存

 ※ 建立科學(xué)合理的性能、壓力測試環(huán)境。性能瓶頸總是出現(xiàn)在你意想不到的地方