面臨的問題

對(duì)于高并發(fā)高訪問的Web應(yīng)用程序來(lái)說(shuō)，數(shù)據(jù)庫(kù)存取瓶頸一直是個(gè)令人頭疼的問題。特別當(dāng)你的程序架構(gòu)還是建立在單數(shù)據(jù)庫(kù)模式，而一個(gè)數(shù)據(jù)池連接數(shù)峰值已經(jīng)達(dá)到500的時(shí)候，那你的程序運(yùn)行離崩潰的邊緣也不遠(yuǎn)了。很多小網(wǎng)站的開發(fā)人員一開始都將注意力放在了產(chǎn)品需求設(shè)計(jì)上，缺忽視了程序整體性能，可擴(kuò)展性等方面的考慮，結(jié)果眼看著訪問量一天天網(wǎng)上爬，可突然發(fā)現(xiàn)有一天網(wǎng)站因?yàn)樵L問量過大而崩潰了，到時(shí)候哭都來(lái)不及。所以我們一定要未雨綢繆，在數(shù)據(jù)庫(kù)還沒罷工前，想方設(shè)法給它減負(fù)，這也是這篇文章的主要議題。

大家都知道，當(dāng)有一個(gè)request過來(lái)后，web服務(wù)器交給app服務(wù)器，app處理并從db中存取相關(guān)數(shù)據(jù)，但db存取的花費(fèi)是相當(dāng)高昂的。特別是每次都取相同的數(shù)據(jù)，等于是讓數(shù)據(jù)庫(kù)每次都在做高耗費(fèi)的無(wú)用功，數(shù)據(jù)庫(kù)如果會(huì)說(shuō)話，肯定會(huì)發(fā)牢騷，你都問了這么多遍了，難道還記不住嗎？是啊，如果app拿到第一次數(shù)據(jù)并存到內(nèi)存里，下次讀取時(shí)直接從內(nèi)存里讀取，而不用麻煩數(shù)據(jù)庫(kù)，這樣不就給數(shù)據(jù)庫(kù)減負(fù)了？而且從內(nèi)存取數(shù)據(jù)必然要比從數(shù)據(jù)庫(kù)媒介取快很多倍，反而提升了應(yīng)用程序的性能。

因此，我們可以在web/app層與db層之間加一層cache層，主要目的：1. 減少數(shù)據(jù)庫(kù)讀取負(fù)擔(dān)；2. 提高數(shù)據(jù)讀取速度。而且，cache存取的媒介是內(nèi)存，而一臺(tái)服務(wù)器的內(nèi)存容量一般都是有限制的，不像硬盤容量可以做到TB級(jí)別。所以，可以考慮采用分布式的cache層，這樣更易于破除內(nèi)存容量的限制，同時(shí)又增加了靈活性。

Memcached 介紹

Memcached是開源的分布式cache系統(tǒng)，現(xiàn)在很多的大型web應(yīng)用程序包括facebook，youtube，wikipedia，yahoo等等都在使用memcached來(lái)支持他們每天數(shù)億級(jí)的頁(yè)面訪問。通過把cache層與他們的web架構(gòu)集成，他們的應(yīng)用程序在提高了性能的同時(shí)，還大大降低了數(shù)據(jù)庫(kù)的負(fù)載。
具體的memcached資料大家可以直接從它的官方網(wǎng)站[1]上得到。這里我就簡(jiǎn)單給大家介紹一下memcached的工作原理：

Memcached處理的原子是每一個(gè)（key，value）對(duì)（以下簡(jiǎn)稱kv對(duì)），key會(huì)通過一個(gè)hash算法轉(zhuǎn)化成hash-key，便于查找、對(duì)比以及做到盡可能的散列。同時(shí)，memcached用的是一個(gè)二級(jí)散列，通過一張大hash表來(lái)維護(hù)。

Memcached有兩個(gè)核心組件組成：服務(wù)端（ms）和客戶端（mc），在一個(gè)memcached的查詢中，mc先通過計(jì)算key的hash值來(lái)確定kv對(duì)所處在的ms位置。當(dāng)ms確定后，客戶端就會(huì)發(fā)送一個(gè)查詢請(qǐng)求給對(duì)應(yīng)的ms，讓它來(lái)查找確切的數(shù)據(jù)。因?yàn)檫@之間沒有交互以及多播協(xié)議，所以memcached交互帶給網(wǎng)絡(luò)的影響是最小化的。

舉例說(shuō)明：考慮以下這個(gè)場(chǎng)景，有三個(gè)mc分別是X，Y，Z，還有三個(gè)ms分別是A，B，C：

設(shè)置kv對(duì)
X想設(shè)置key=”foo”,value=”seattle”
X拿到ms列表，并對(duì)key做hash轉(zhuǎn)化，根據(jù)hash值確定kv對(duì)所存的ms位置
B被選中了
X連接上B，B收到請(qǐng)求，把（key=”foo”,value=”seattle”）存了起來(lái)

獲取kv對(duì)
Z想得到key=”foo”的value
Z用相同的hash算法算出hash值，并確定key=”foo”的值存在B上
Z連接上B，并從B那邊得到value=”seattle”
其他任何從X，Y，Z的想得到key=”foo”的值的請(qǐng)求都會(huì)發(fā)向B

Memcached服務(wù)器(ms)

內(nèi)存分配

默認(rèn)情況下，ms是用一個(gè)內(nèi)置的叫“塊分配器”的組件來(lái)分配內(nèi)存的。舍棄c++標(biāo)準(zhǔn)的malloc/free的內(nèi)存分配，而采用塊分配器的主要目的是為了避免內(nèi)存碎片，否則操作系統(tǒng)要花費(fèi)更多時(shí)間來(lái)查找這些邏輯上連續(xù)的內(nèi)存塊（實(shí)際上是斷開的）。用了塊分配器，ms會(huì)輪流的對(duì)內(nèi)存進(jìn)行大塊的分配，并不斷重用。當(dāng)然由于塊的大小各不相同，當(dāng)數(shù)據(jù)大小和塊大小不太相符的情況下，還是有可能導(dǎo)致內(nèi)存的浪費(fèi)。

同時(shí)，ms對(duì)key和data都有相應(yīng)的限制，key的長(zhǎng)度不能超過250字節(jié)，data也不能超過塊大小的限制 --- 1MB。
因?yàn)閙c所使用的hash算法，并不會(huì)考慮到每個(gè)ms的內(nèi)存大小。理論上mc會(huì)分配概率上等量的kv對(duì)給每個(gè)ms，這樣如果每個(gè)ms的內(nèi)存都不太一樣，那可能會(huì)導(dǎo)致內(nèi)存使用率的降低。所以一種替代的解決方案是，根據(jù)每個(gè)ms的內(nèi)存大小，找出他們的最大公約數(shù)，然后在每個(gè)ms上開n個(gè)容量=最大公約數(shù)的instance，這樣就等于擁有了多個(gè)容量大小一樣的子ms，從而提供整體的內(nèi)存使用率。

緩存策略

當(dāng)ms的hash表滿了之后，新的插入數(shù)據(jù)會(huì)替代老的數(shù)據(jù)，更新的策略是LRU（最近最少使用），以及每個(gè)kv對(duì)的有效時(shí)限。Kv對(duì)存儲(chǔ)有效時(shí)限是在mc端由app設(shè)置并作為參數(shù)傳給ms的。

同時(shí)ms采用是偷懶替代法，ms不會(huì)開額外的進(jìn)程來(lái)實(shí)時(shí)監(jiān)測(cè)過時(shí)的kv對(duì)并刪除，而是當(dāng)且僅當(dāng)，新來(lái)一個(gè)插入的數(shù)據(jù)，而此時(shí)又沒有多余的空間放了，才會(huì)進(jìn)行清除動(dòng)作。

緩存數(shù)據(jù)庫(kù)查詢
現(xiàn)在memcached最流行的一種使用方式是緩存數(shù)據(jù)庫(kù)查詢，下面舉一個(gè)簡(jiǎn)單例子說(shuō)明：

App需要得到userid=xxx的用戶信息，對(duì)應(yīng)的查詢語(yǔ)句類似：

“SELECT * FROM users WHERE userid = xxx”

App先去問cache，有沒有“user:userid”（key定義可預(yù)先定義約束好）的數(shù)據(jù)，如果有，返回?cái)?shù)據(jù)；如果沒有，App會(huì)從數(shù)據(jù)庫(kù)中讀取數(shù)據(jù)，并調(diào)用cache的add函數(shù)，把數(shù)據(jù)加入cache中。

當(dāng)取的數(shù)據(jù)需要更新，app會(huì)調(diào)用cache的update函數(shù)，來(lái)保持?jǐn)?shù)據(jù)庫(kù)與cache的數(shù)據(jù)同步。

從上面的例子我們也可以發(fā)現(xiàn)，一旦數(shù)據(jù)庫(kù)的數(shù)據(jù)發(fā)現(xiàn)變化，我們一定要及時(shí)更新cache中的數(shù)據(jù)，來(lái)保證app讀到的是同步的正確數(shù)據(jù)。當(dāng)然我們可以通過定時(shí)器方式記錄下cache中數(shù)據(jù)的失效時(shí)間，時(shí)間一過就會(huì)激發(fā)事件對(duì)cache進(jìn)行更新，但這之間總會(huì)有時(shí)間上的延遲，導(dǎo)致app可能從cache讀到臟數(shù)據(jù)，這也被稱為狗洞問題。（以后我會(huì)專門描述研究這個(gè)問題）

數(shù)據(jù)冗余與故障預(yù)防

從設(shè)計(jì)角度上，memcached是沒有數(shù)據(jù)冗余環(huán)節(jié)的，它本身就是一個(gè)大規(guī)模的高性能cache層，加入數(shù)據(jù)冗余所能帶來(lái)的只有設(shè)計(jì)的復(fù)雜性和提高系統(tǒng)的開支。

當(dāng)一個(gè)ms上丟失了數(shù)據(jù)之后，app還是可以從數(shù)據(jù)庫(kù)中取得數(shù)據(jù)。不過更謹(jǐn)慎的做法是在某些ms不能正常工作時(shí)，提供額外的ms來(lái)支持cache，這樣就不會(huì)因?yàn)閍pp從cache中取不到數(shù)據(jù)而一下子給數(shù)據(jù)庫(kù)帶來(lái)過大的負(fù)載。

同時(shí)為了減少某臺(tái)ms故障所帶來(lái)的影響，可以使用“熱備份”方案，就是用一臺(tái)新的ms來(lái)取代有問題的ms，當(dāng)然新的ms還是要用原來(lái)ms的IP地址，大不了數(shù)據(jù)重新裝載一遍。

另外一種方式，就是提高你ms的節(jié)點(diǎn)數(shù)，然后mc會(huì)實(shí)時(shí)偵查每個(gè)節(jié)點(diǎn)的狀態(tài)，如果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)長(zhǎng)時(shí)間沒有響應(yīng)，就會(huì)從mc的可用server列表里刪除，并對(duì)server節(jié)點(diǎn)進(jìn)行重新hash定位。當(dāng)然這樣也會(huì)造成的問題是，原本key存儲(chǔ)在B上，變成存儲(chǔ)在C上了。所以此方案本身也有其弱點(diǎn)，最好能和“熱備份”方案結(jié)合使用，就可以使故障造成的影響最小化。

Memcached客戶端（mc）

Memcached客戶端有各種語(yǔ)言的版本供大家使用，包括java，c，php，.net等等，具體可參見memcached api page[2]。
大家可以根據(jù)自己項(xiàng)目的需要，選擇合適的客戶端來(lái)集成。

緩存式的Web應(yīng)用程序架構(gòu)
有了緩存的支持，我們可以在傳統(tǒng)的app層和db層之間加入cache層，每個(gè)app服務(wù)器都可以綁定一個(gè)mc，每次數(shù)據(jù)的讀取都可以從ms中取得，如果沒有，再?gòu)膁b層讀取。而當(dāng)數(shù)據(jù)要進(jìn)行更新時(shí)，除了要發(fā)送update的sql給db層，同時(shí)也要將更新的數(shù)據(jù)發(fā)給mc，讓mc去更新ms中的數(shù)據(jù)。

假設(shè)今后我們的數(shù)據(jù)庫(kù)可以和ms進(jìn)行通訊了，那可以將更新的任務(wù)統(tǒng)一交給db層，每次數(shù)據(jù)庫(kù)更新數(shù)據(jù)的同時(shí)會(huì)自動(dòng)去更新ms中的數(shù)據(jù)，這樣就可以進(jìn)一步減少app層的邏輯復(fù)雜度。如下圖：

不過每次我們?nèi)绻麤]有從cache讀到數(shù)據(jù)，都不得不麻煩數(shù)據(jù)庫(kù)。為了最小化數(shù)據(jù)庫(kù)的負(fù)載壓力，我們可以部署數(shù)據(jù)庫(kù)復(fù)寫，用slave數(shù)據(jù)庫(kù)來(lái)完成讀取操作，而master數(shù)據(jù)庫(kù)永遠(yuǎn)只負(fù)責(zé)三件事：1.更新數(shù)據(jù)；2.同步slave數(shù)據(jù)庫(kù)；3.更新cache。如下圖：

以上這些緩存式web架構(gòu)在實(shí)際應(yīng)用中被證明是能有效并能極大地降低數(shù)據(jù)庫(kù)的負(fù)載同時(shí)又能提高web的運(yùn)行性能。當(dāng)然這些架構(gòu)還可以根據(jù)具體的應(yīng)用環(huán)境進(jìn)行變種，以達(dá)到不同硬件條件下性能的最優(yōu)化。

未來(lái)的憧憬
Memcached的出現(xiàn)可以說(shuō)是革命性的，第一次讓我們意識(shí)到可以用內(nèi)存作為存儲(chǔ)媒介來(lái)大規(guī)模的緩存數(shù)據(jù)以提高程序的性能。不過它畢竟還是比較新的東西，還需要很多有待優(yōu)化和改進(jìn)的地方，例如：
如何利用memcached實(shí)現(xiàn)cache數(shù)據(jù)庫(kù)，讓數(shù)據(jù)庫(kù)跑在內(nèi)存上。這方面，tangent software 開發(fā)的memcached_engine[3]已經(jīng)做了不少工作，不過現(xiàn)在的版本還只是處于實(shí)驗(yàn)室階段。
如何能方便有效的進(jìn)行批量key清理。因?yàn)楝F(xiàn)在key是散列在不同的server上的，所以對(duì)某類key進(jìn)行大批量清理是很麻煩的。因?yàn)閙emcached本身是一個(gè)大hash表，是不具備key的檢索功能的。所以memcached是壓根不知道某一類的key到底存了多少個(gè)，都存在哪些server上。而這類功能在實(shí)際應(yīng)用中卻是經(jīng)常用到。

交流
作者也是剛接觸memcached方面的內(nèi)容，所以嚴(yán)格來(lái)說(shuō)還只是個(gè)新手，班門弄斧地說(shuō)了一大通，如果有不對(duì)的地方，還請(qǐng)各位大俠多多指正。當(dāng)然，如果有什么和memcached方面有關(guān)的問題或建議，也歡迎和我聯(lián)系。
聯(lián)系Email: rongwei.yang@dianping.com

參考
[1]. Memcached website: http://danga.com/memcached/
[2]. Memcached API Page: http://danga.com/memcached/apis.bml
[3]. memcached_engine: http://tangent.org/506/memcache_engine.html