摘要：對(duì)于的連接數(shù)，并沒有隨著節(jié)點(diǎn)的增多，而降低。比如，，這個(gè)，在用分布式算法求其節(jié)點(diǎn)時(shí)，應(yīng)該以來計(jì)算，而不是以來計(jì)算。永久數(shù)據(jù)被踢現(xiàn)象網(wǎng)上有人反饋為數(shù)據(jù)丟失，明明設(shè)為永久有效，卻莫名其妙的丟失了。

Memcached是一個(gè)開源、免費(fèi)、高性能的分布式對(duì)象緩存系統(tǒng)，通過減少對(duì)數(shù)據(jù)庫的讀取以提高Web應(yīng)用的性能；Memcached基于一個(gè)存儲(chǔ)鍵/值對(duì)的hashmap。其守護(hù)進(jìn)程（daemon ）是用 C 寫的，但是客戶端可以用任何語言來編寫，并通過memcached協(xié)議與守護(hù)進(jìn)程通信。當(dāng)某個(gè)服務(wù)器停止運(yùn)行或崩潰了，所有存放在該服務(wù)器上的鍵/值對(duì)都將丟失。

Memcached的服務(wù)器端沒有提供分布式功能，各個(gè)Memcached應(yīng)用不會(huì)互相通信以共享信息。想要實(shí)現(xiàn)分布式通過，可以多搭建幾個(gè)Memcached應(yīng)用，通過算法實(shí)現(xiàn)此效果；

Memcached里有兩個(gè)重要概念：

slab：為了防止內(nèi)存碎片化，Memcached服務(wù)器端會(huì)預(yù)先將數(shù)據(jù)空間劃分為一系列slab；舉個(gè)例子，現(xiàn)在有一個(gè)100立方米的房間，為了合理規(guī)劃這個(gè)房間放置東西，會(huì)在這個(gè)房間里放置 30 個(gè) 1 立方米的盒子、20 個(gè) 1.25 立方米的盒子、15 個(gè) 1.5 立方米的盒子...這些盒子就是slab；

LRU：最近最少使用算法；當(dāng)同一個(gè)slat的格子滿了，這時(shí)需要新加一個(gè)值時(shí)，不會(huì)考慮將這個(gè)新數(shù)據(jù)放到比當(dāng)前slat更大的空閑slat，而是使用LRU移除舊數(shù)據(jù)，放入這個(gè)新數(shù)據(jù)；

Memcached能夠在大多數(shù) Linux 和 類 BSD 系統(tǒng)上運(yùn)行；官方?jīng)]有給出Windows上安裝Memcached的支持；

對(duì)于Debian / Ubuntu系統(tǒng)：

apt-get install memcached

對(duì)于Redhat / Fedora / CentOs系統(tǒng)：

yum install memcached

通過memcached -h查看幫助，同時(shí)也算是測(cè)試是否安裝成功；
如果遇到錯(cuò)誤，可參考官方上的FAQ；

啟動(dòng)一個(gè)Memcached應(yīng)用，常見的啟動(dòng)方式是這樣的：
開啟一個(gè)memcached應(yīng)用作守護(hù)進(jìn)程，TCP連接，端口號(hào)是 11211；-u參數(shù)是運(yùn)行Memcached應(yīng)用的用戶（這個(gè)參數(shù)也只有 root用戶才能使用）；

memcached -u root -p 11211 -d -vvv 

其他常見的參數(shù)也有

-m ：分配給Memcached應(yīng)用使用的內(nèi)存大小，默認(rèn)是 64M；

-l ：設(shè)置能訪問Memcached應(yīng)用的IP(默認(rèn)：所有都允許；無論內(nèi)外網(wǎng)或者本機(jī)更換IP，有安全隱患；若設(shè)置為127.0.0.1就只能本機(jī)訪問)；

-c ：設(shè)置最大運(yùn)行的并發(fā)連接數(shù)，默認(rèn)是 1024；

-f ：設(shè)置slat大小增長因子；默認(rèn)是 1.25；比如說 10號(hào)slab大小是752，那么11號(hào)slab大小就是 752 * 1.25；

Memcached客戶端與服務(wù)器端的通信比較簡單，使用的基于文本的協(xié)議，而不是二進(jìn)制協(xié)議；因此可以通過telnet進(jìn)行交互；

telnet [host] [port]

按下Ctrl + ]，并回車，即可回顯；

set
存儲(chǔ)數(shù)據(jù)。如果set的key已經(jīng)存在，該命令可以更新該key所對(duì)應(yīng)的原來的數(shù)據(jù)，也就是實(shí)現(xiàn)更新的作用。詳細(xì)命令指南可參考菜鳥教程 - Memcached set 命令；

add
只有在set的key不存在的情況下，才會(huì)存儲(chǔ)數(shù)據(jù)；詳細(xì)命令指南可參考菜鳥教程 - Memcached add 命令；

replace
只有在set的key存在的情況下，才會(huì)替換數(shù)據(jù)；詳細(xì)命令指南可參考菜鳥教程 - Memcached replace 命令；

append
向已存在的元素值后追加數(shù)據(jù)；詳細(xì)命令指南可參考菜鳥教程 - Memcached append 命令；

prepend
向已存在的元素值的頭部追加數(shù)據(jù)；詳細(xì)命令指南可參考菜鳥教程 - Memcached prepend 命令；

cas
命令用于執(zhí)行一個(gè)"檢查并設(shè)置"的操作。它僅在當(dāng)前客戶端最后一次取值后，該key 對(duì)應(yīng)的值沒有被其他客戶端修改的情況下，才能夠?qū)⒅祵懭?。檢查是通過cas_token參數(shù)進(jìn)行的， 這個(gè)參數(shù)是Memcach指定給已經(jīng)存在的元素的一個(gè)唯一的 64 位值。詳細(xì)命令指南可參考菜鳥教程 - Memcached cas 命令；

get
根據(jù)元素的鍵名獲取值；詳細(xì)命令指南可參考菜鳥教程 - Memcached get 命令；

gets
獲取帶有CAS令牌的數(shù)據(jù)值；詳細(xì)命令指南可參考菜鳥教程 - Memcached gets 命令；

delete
刪除已存在的元素；詳細(xì)命令指南可參考菜鳥教程 - Memcached delete 命令；

incr/decr
對(duì)于已存在的鍵值進(jìn)行自增或自減操作；詳細(xì)命令指南可參考菜鳥教程 - Memcached incr/decr 命令；

stats
查看memcached所有的統(tǒng)計(jì)信息；詳細(xì)命令指南可參考菜鳥教程 - Memcached stats 命令；

stats items
顯示各個(gè)slab中item的數(shù)目和存儲(chǔ)時(shí)長等其它信息；詳細(xì)命令指南可參考菜鳥教程 - Memcached stats items 命令；

stats slabs
顯示各個(gè)slab的信息，包括chunk的大小、數(shù)目、使用情況等。詳細(xì)命令指南可參考菜鳥教程 - Memcached stats slabs 命令；

stats sizes
用于顯示所有item的大小和個(gè)數(shù)。該信息返回兩列，第一列是 item 的大小，第二列是 item 的個(gè)數(shù)。詳細(xì)命令指南可參考菜鳥教程 - Memcached stats sizes 命令；

flush_all
清除所有緩存數(shù)據(jù)；詳細(xì)命令指南可參考菜鳥教程 - Memcached flush_all 命令；

根據(jù)服務(wù)器節(jié)點(diǎn)數(shù)的余數(shù)來進(jìn)行分散，就是通過hash函數(shù)求得的Key的整數(shù)哈希值再除以服務(wù)器節(jié)點(diǎn)數(shù)并取余數(shù)來選擇服務(wù)器。這種算法取余計(jì)算簡單，分散效果好，但是缺點(diǎn)是如果某一臺(tái)機(jī)器宕機(jī)，那么應(yīng)該落在該機(jī)器的請(qǐng)求就無法得到正確的處理，這時(shí)需要將當(dāng)?shù)舻姆?wù)器從算法從去除，此時(shí)候會(huì)有 (N-1) / N 的服務(wù)器的緩存數(shù)據(jù)需要重新進(jìn)行計(jì)算；如果新增一臺(tái)機(jī)器，會(huì)有N / (N+1)的服務(wù)器的緩存數(shù)據(jù)需要進(jìn)行重新計(jì)算。對(duì)于系統(tǒng)而言，這通常是不可接受的顛簸（因?yàn)檫@意味著大量緩存的失效或者數(shù)據(jù)需要轉(zhuǎn)移）。

【本段內(nèi)容摘自大臉貓的博客】

表現(xiàn)為一個(gè)封閉的圓環(huán)，圓環(huán)上的點(diǎn)分別代表0 ~ 2^32。各個(gè)memcached節(jié)點(diǎn)根據(jù)hash算法，分別占據(jù)圓環(huán)上的一個(gè)點(diǎn)，當(dāng)某key進(jìn)行存儲(chǔ)操作，會(huì)針對(duì)key進(jìn)行hash操作，hash后也是圓環(huán)上的一個(gè)點(diǎn)，那么這個(gè)key將被存儲(chǔ)在順時(shí)針方向的第一個(gè)節(jié)點(diǎn)上。

如上圖：分配不均的節(jié)點(diǎn)，此時(shí)key將會(huì)被存儲(chǔ)到節(jié)點(diǎn)C上。

此時(shí)，我們新增節(jié)點(diǎn)D，如下圖。受影響的部分只有節(jié)點(diǎn)A~節(jié)點(diǎn)D中間的部分，這邊分?jǐn)?shù)據(jù)不會(huì)再映射到節(jié)點(diǎn)B上，而是映射到新增節(jié)點(diǎn)D上。減掉一個(gè)節(jié)點(diǎn)同理，只影響順時(shí)針后面一個(gè)節(jié)點(diǎn)。

優(yōu)點(diǎn)：動(dòng)態(tài)的增刪節(jié)點(diǎn)，服務(wù)器down機(jī)，影響的只是順時(shí)針的下一個(gè)節(jié)點(diǎn)
缺點(diǎn)：當(dāng)服務(wù)器進(jìn)行hash后值較為接近會(huì)導(dǎo)致在圓環(huán)上分布不均勻，進(jìn)而導(dǎo)致key的分布、服務(wù)器的壓力不均勻。若中間某一權(quán)重較大的serverdown機(jī)，命中率下降明顯；

在一致性哈希算法的基礎(chǔ)上引入虛擬節(jié)點(diǎn)

引入虛擬節(jié)點(diǎn)的思想，解決一致性hash算法分布不均導(dǎo)致負(fù)載不均的問題。一個(gè)真實(shí)節(jié)點(diǎn)對(duì)應(yīng)若干個(gè)虛擬節(jié)點(diǎn)，當(dāng)key被映射到虛擬節(jié)點(diǎn)上時(shí)，則被認(rèn)為映射到虛擬節(jié)點(diǎn)所對(duì)應(yīng)的真實(shí)節(jié)點(diǎn)上。

優(yōu)點(diǎn)：引入虛擬節(jié)點(diǎn)的思想，每個(gè)物理節(jié)點(diǎn)對(duì)應(yīng)圓環(huán)上若干個(gè)虛擬節(jié)點(diǎn)（比如200~300個(gè)），當(dāng)keyhash到虛擬節(jié)點(diǎn)，就會(huì)存儲(chǔ)到實(shí)際的物理節(jié)點(diǎn)上，有效的實(shí)現(xiàn)了負(fù)載均衡；

【本段內(nèi)容摘自魚我所欲也的“memcached學(xué)習(xí) - 分布式算法”文章】

緩存雪崩一般是由某個(gè)緩存節(jié)點(diǎn)失效，導(dǎo)致其他節(jié)點(diǎn)的緩存命中率下降，緩存中缺失的數(shù)據(jù)去數(shù)據(jù)庫查詢，短時(shí)間內(nèi)，造成數(shù)據(jù)庫服務(wù)器崩潰；

重啟DB，短期又被壓垮，但緩存數(shù)據(jù)也多一些；DB反復(fù)多次啟動(dòng)多次，緩存重建完畢，DB才穩(wěn)定運(yùn)行；或者，是由于緩存周期性的失效，比如每 6 小時(shí)失效一次，那么每 6 小時(shí)，將有一個(gè)請(qǐng)求“峰值”，嚴(yán)重者甚至?xí)頓B崩潰；

該問題由 facebook 的工作人員提出的, facebook 在 2010 年左右，memcached節(jié)點(diǎn)就已經(jīng)達(dá)3000 個(gè).緩存數(shù)千 G 內(nèi)容。

他們發(fā)現(xiàn)了一個(gè)問題，memcached 連接頻率，效率下降了，于是加 memcached 節(jié)點(diǎn)，添加了后，發(fā)現(xiàn)因?yàn)檫B接頻率導(dǎo)致的問題，仍然存在，并沒有好轉(zhuǎn)，稱之為“無底洞現(xiàn)象”。

以用戶為例: user-133-age， user-133-name，user-133-height .....N 個(gè) key，當(dāng)服務(wù)器增多，133 號(hào)用戶的信息，也被散落在更多的節(jié)點(diǎn)，所以，同樣是訪問個(gè)人主頁，得到相同的個(gè)人信息， 節(jié)點(diǎn)越多，要連接的節(jié)點(diǎn)也越多。

對(duì)于 memcached 的連接數(shù)，并沒有隨著節(jié)點(diǎn)的增多，而降低。 于是問題出現(xiàn)。

把某一組key，按其共同前綴，來分布。比如 user-133-age， user-133-name，user-133-height 這 3 個(gè) key，在用分布式算法求其節(jié)點(diǎn)時(shí)，應(yīng)該以 ‘user-133’來計(jì)算，而不是以 user-133-age/name/height 來計(jì)算。

這樣，3 個(gè)關(guān)于個(gè)人信息的 key，都落在同 1 個(gè)節(jié)點(diǎn)上，訪問個(gè)人主頁時(shí)，只需要連接 1 個(gè)節(jié)點(diǎn)。

網(wǎng)上有人反饋為"memcached 數(shù)據(jù)丟失"，明明設(shè)為永久有效，卻莫名其妙的丟失了。

分析原因：

如果 slab 里的很多 chunk，已經(jīng)過期，但過期后沒有被 get 過， 系統(tǒng)不知他們已經(jīng)過期。

永久數(shù)據(jù)很久沒 get 了， 不活躍， 如果新增 item，則永久數(shù)據(jù)被踢了。

當(dāng)然，如果那些非永久數(shù)據(jù)被 get，也會(huì)被標(biāo)識(shí)為 expire，從而不會(huì)再踢掉永久數(shù)據(jù)；

解決方案：永久數(shù)據(jù)和非永久數(shù)據(jù)分開放；