http://hzp.iteye.com/blog/1872664
Memcached處理的原子是每一個（key，value）對（以下簡稱kv對），key會通過一個hash算法轉化成hash-key，便于查找、對比以及做到盡可能的散列。同時，memcached用的是一個二級散列，通過一張大hash表來維護。
Memcached有兩個核心組件組成：服務端（ms）和客戶端（mc），在一個memcached的查詢中，mc先通過計算key的hash值來 確定kv對所處在的ms位置。當ms確定后，客戶端就會發送一個查詢請求給對應的ms，讓它來查找確切的數據。因為這之間沒有交互以及多播協議，所以 memcached交互帶給網絡的影響是最小化的。
舉例說明：考慮以下這個場景，有三個mc分別是X，Y，Z，還有三個ms分別是A，B，C：
設置kv對
X想設置key=”foo”,value=”seattle”
X拿到ms列表，并對key做hash轉化，根據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”的值的請求都會發向B
?
?
Memcached服務器(ms)
內存分配
默認情況下，ms是用一個內置的叫“塊分配器”的組件來分配內存的。舍棄c++標準的malloc/free的內存分配，而采用塊分配器的主要目的 是為了避免內存碎片，否則操作系統要花費更多時間來查找這些邏輯上連續的內存塊（實際上是斷開的）。用了塊分配器，ms會輪流的對內存進行大塊的分配，并 不斷重用。當然由于塊的大小各不相同，當數據大小和塊大小不太相符的情況下，還是有可能導致內存的浪費。
同時，ms對key和data都有相應的限制，key的長度不能超過250字節，data也不能超過塊大小的限制 --- 1MB。
因為 mc所使用的hash算法，并不會考慮到每個ms的內存大小。理論上mc會分配概率上等量的kv對給每個ms，這樣如果每個ms的內存都不太一樣，那可能 會導致內存使用率的降低。所以一種替代的解決方案是，根據每個ms的內存大小，找出他們的最大公約數，然后在每個ms上開n個容量=最大公約數的 instance，這樣就等于擁有了多個容量大小一樣的子ms，從而提供整體的內存使用率。
緩存策略
當ms的hash表滿了之后，新的插入數據會替代老的數據，更新的策略是LRU（最近最少使用），以及每個kv對的有效時限。Kv對存儲有效時限是在mc端由app設置并作為參數傳給ms的。
同時ms采用是偷懶替代法，ms不會開額外的進程來實時監測過時的kv對并刪除，而是當且僅當，新來一個插入的數據，而此時又沒有多余的空間放了，才會進行清除動作。
?
Memcached客戶端（mc）
Memcached客戶端有各種語言的版本供大家使用，包括java，c，php，.net等等。
大家可以根據自己項目的需要，選擇合適的客戶端來集成。
?
緩存式的Web應用程序架構
有了緩存的支持，我們可以在傳統的app層和db層之間加入cache層， 每個app服務器都可以綁定一個mc，每次數據的讀取都可以從ms中取得，如果沒有，再從db層讀取。而當數據要進行更新時，除了要發送update的 sql給db層，同時也要將更新的數據發給mc，讓mc去更新ms中的數據。
假設今后我們的數據庫可以和ms進行通訊了，那可以將更新的任務統一交給db層，每次數據庫更新數據的同時會自動去更新ms中的數據，這樣就可以進一步減少app層的邏輯復雜度。如下圖：
不過每次我們如果沒有從cache讀到數據，都不得不麻煩數據庫。為了最小化數據庫的負載壓力，我們可以部署數據庫復寫，用slave數據庫來完成讀取操作，而master數據庫永遠只負責三件事：1.更新數據；2.同步slave數據庫；3.更新cache。如下圖：
以上這些緩存式web架構在實際應用中被證明是能有效并能極大地降低數據庫的負載同時又能提高web的運行性能。當然這些架構還可以根據具體的應用環境進行變種，以達到不同硬件條件下性能的最優化。
?
參考
[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
)
)
