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

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

Memcached 介紹

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

Memcached處理的原子是每一個（key，value）對（以下簡稱kv對），key會通過一個hash算法轉化成hash-key，便于查找、對比以及做到盡可能的散列。同時，memcached用的是一個二級散列，通過一張大hash表來維護。

Memcached有兩個核心組件組成：服務端（ms）和客戶端（mc），在一個memcached的查詢中，mc先通過計算key的hash值來確定kv對所處在的ms位置。當ms確定后，客戶端就會發(fā)送一個查詢請求給對應的ms，讓它來查找確切的數(shù)據(jù)。因為這之間沒有交互以及多播協(xié)議，所以memcached交互帶給網絡的影響是最小化的。

舉例說明：考慮以下這個場景，有三個mc分別是X，Y，Z，還有三個ms分別是A，B，C：

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

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

Memcached服務器(ms)

內存分配

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

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

緩存策略

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

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

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

App需要得到userid=xxx的用戶信息，對應的查詢語句類似：

“SELECT * FROM users WHERE userid = xxx”

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

當取的數(shù)據(jù)需要更新，app會調用cache的update函數(shù)，來保持數(shù)據(jù)庫與cache的數(shù)據(jù)同步。

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

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

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

當一個ms上丟失了數(shù)據(jù)之后，app還是可以從數(shù)據(jù)庫中取得數(shù)據(jù)。不過更謹慎的做法是在某些ms不能正常工作時，提供額外的ms來支持cache，這樣就不會因為app從cache中取不到數(shù)據(jù)而一下子給數(shù)據(jù)庫帶來過大的負載。

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

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

Memcached客戶端（mc）

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

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

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

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

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

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

交流
作者也是剛接觸memcached方面的內容，所以嚴格來說還只是個新手，班門弄斧地說了一大通，如果有不對的地方，還請各位大俠多多指正。當然，如果有什么和memcached方面有關的問題或建議，也歡迎和我聯(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

memcached 工作原理