七、數(shù)據(jù)庫

幾乎所有操作最后都要落到數(shù)據(jù)庫身上，它又最難擴展（存儲也挺難）。對于mysql，什么樣的表用myisam，什么樣的表用innodb，在開發(fā)之前要確定。復(fù)制策略、分片策略，也要確定。表引擎方面，一般，更新不多、不需要事務(wù)的表可以用myisam，需要行鎖定、事務(wù)支持的，用innodb。myisam的鎖表不一定是性能低下的根源，innodb也不一定全是行鎖，具體細(xì)節(jié)要多看相關(guān)的文檔，熟悉了引擎特性才能用的更好。現(xiàn)代WEB應(yīng)用越來越復(fù)雜了，我們設(shè)計表結(jié)構(gòu)時常常設(shè)計很多冗余，雖然不符合傳統(tǒng)范式，但為了速度考慮還是值得的，要求高的情況下甚至要杜絕聯(lián)合查詢。編程時得多注意數(shù)據(jù)一致性。

復(fù)制策略方面，多主多從結(jié)構(gòu)也最好一開始就設(shè)計好，代碼直接按照多主多從來編寫，用一些小技巧來避免復(fù)制延時問題，并且還要解決多數(shù)據(jù)庫數(shù)據(jù)是否一致，可以自己寫或者找現(xiàn)成的運維工具。

分片策略。總會有那么幾個表數(shù)據(jù)量超大，這時分片必不可免。分片有很多策略，從簡單的分區(qū)到根據(jù)熱度自動調(diào)整，依照具體業(yè)務(wù)選擇一個適合自己的。避免自增ID作為主鍵，不利于分片。

用存儲過程是比較難擴展的，這種情形多發(fā)生于傳統(tǒng)C/S，特別是OA系統(tǒng)轉(zhuǎn)換過來的開發(fā)人員。低成本網(wǎng)站不是一兩臺小型機跑一個數(shù)據(jù)庫處理所有業(yè)務(wù)的模式，是機海作戰(zhàn)。方便水平擴展比那點預(yù)分析時間和網(wǎng)絡(luò)傳輸流量要重要的多的多。

NoSQL。這只是一個概念。實際應(yīng)用中，網(wǎng)站有著越來越多的密集寫操作、上億的簡單關(guān)系數(shù)據(jù)讀取、熱備等，這都不是傳統(tǒng)關(guān)系數(shù)據(jù)庫所擅長的，于是就產(chǎn)生了很多非關(guān)系型數(shù)據(jù)庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次的寫操作，內(nèi)存型的甚至5萬以上。例如MongoDB，幾句配置就可以組建一個復(fù)制+自動分片+failover的環(huán)境，文檔化的存儲也簡化了傳統(tǒng)設(shè)計庫結(jié)構(gòu)再開發(fā)的模式。很多業(yè)務(wù)是可以用這類數(shù)據(jù)庫來替代mysql的。

八、緩存。

數(shù)據(jù)庫很脆弱，一定要有緩存在前面擋著，其實我們優(yōu)化速度，幾乎就是優(yōu)化緩存，能用緩存的地方，就不要再跑到后端數(shù)據(jù)庫那折騰。緩存有持久化緩存、內(nèi)存緩存，生成靜態(tài)頁面是最容易理解的持久化緩存了，還有很多比如varnish的分塊緩存、前面提到的memcachedb等，內(nèi)存緩存，memcached首當(dāng)其沖。緩存更新可用被動更新和主動更新。被動更新的好處是設(shè)計簡單，緩存空了就自動去數(shù)據(jù)庫取數(shù)據(jù)再把緩存填上，但容易引發(fā)雪崩效應(yīng)，一旦緩存大面積失效，數(shù)據(jù)庫的壓力直線上升很可能掛掉。主動緩存可避免這點但是可能引發(fā)程序取不到數(shù)據(jù)的問題。這兩者之間如何配合，程序設(shè)計要多動腦筋。

九、隊列。

用戶一個操作很可能引發(fā)一系列資源和功能的調(diào)動，這些調(diào)動如果同時發(fā)生，壓力無法控制，用戶體驗也不好，可以把這樣一些操作放入隊列，由另幾個模塊去異步執(zhí)行，例如發(fā)送郵件，發(fā)送手機短信。開源隊列服務(wù)器很多，性能要求不高用數(shù)據(jù)庫當(dāng)做隊列也可以，只要保證程序讀寫隊列的接口不變，底層隊列服務(wù)可隨時更換就可以，類似Zend Framework里的Zend_Queue類，java.util.Queue接口等。

十、文件存儲。

除了結(jié)構(gòu)化數(shù)據(jù)，我們經(jīng)常要存放其他的數(shù)據(jù)，像圖片之類的。這類數(shù)據(jù)數(shù)量繁多、訪問量大。典型的就是圖片，從用戶頭像到用戶上傳的照片，還要生成不同的縮略圖尺寸。存儲的分布幾乎跟數(shù)據(jù)庫擴展一樣艱難。不使用專業(yè)存儲的情況下，基本都是靠自己的NAS。這就涉及到結(jié)構(gòu)。拿圖片存儲舉例，圖片是非常容易產(chǎn)生熱點的，有些圖片上傳后就不再有人看，有些可能每天被訪問數(shù)十萬次，而且大量小文件的異步備份也很耗費時間。

為了將來圖片走cdn做準(zhǔn)備，一開始最好就將圖片的域名分開，且不用主域名。很多網(wǎng)站都將cookie設(shè)置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，并且占多余流量，還可能因為瀏覽器并發(fā)線程限制造成訪問緩慢。

如果用普通的文件系統(tǒng)存儲圖片，有一個簡單的方法。計算文件的hash值，比如md5，以結(jié)果第一位作為第一級目錄，這樣第一級有16個目錄。從0到F，可以把這個字母作為域名，0.yourimg.com到f.yourimg.com（客戶端dns壓力會增大），還可以擴展到最多16個NAS集群上。第二級可用年月例如，201011，第三級用日，第四級可選，根據(jù)上傳量，比如am/pm，甚至小時。最終的目錄結(jié)構(gòu)可能會是 e/201008/25/am/e43ae391c839d82801920cf.jpg。rsync備份時可以用腳本只同步某年某日某時的文件，避免計算大量文件帶來的開銷。當(dāng)然最好是能用專門的分布式文件系統(tǒng)或更專業(yè)點的存儲解決方案。

下面，我們要談?wù)劥a了。