摘要：對于的連接數，并沒有隨著節點的增多，而降低。比如，，這個，在用分布式算法求其節點時，應該以來計算，而不是以來計算。永久數據被踢現象網上有人反饋為數據丟失，明明設為永久有效，卻莫名其妙的丟失了。

Memcached是一個開源、免費、高性能的分布式對象緩存系統，通過減少對數據庫的讀取以提高Web應用的性能；Memcached基于一個存儲鍵/值對的hashmap。其守護進程（daemon ）是用 C 寫的，但是客戶端可以用任何語言來編寫，并通過memcached協議與守護進程通信。當某個服務器停止運行或崩潰了，所有存放在該服務器上的鍵/值對都將丟失。

Memcached的服務器端沒有提供分布式功能，各個Memcached應用不會互相通信以共享信息。想要實現分布式通過，可以多搭建幾個Memcached應用，通過算法實現此效果；

Memcached里有兩個重要概念：

slab：為了防止內存碎片化，Memcached服務器端會預先將數據空間劃分為一系列slab；舉個例子，現在有一個100立方米的房間，為了合理規劃這個房間放置東西，會在這個房間里放置 30 個 1 立方米的盒子、20 個 1.25 立方米的盒子、15 個 1.5 立方米的盒子...這些盒子就是slab；

LRU：最近最少使用算法；當同一個slat的格子滿了，這時需要新加一個值時，不會考慮將這個新數據放到比當前slat更大的空閑slat，而是使用LRU移除舊數據，放入這個新數據；

Memcached能夠在大多數 Linux 和 類 BSD 系統上運行；官方沒有給出Windows上安裝Memcached的支持；

對于Debian / Ubuntu系統：

apt-get install memcached

對于Redhat / Fedora / CentOs系統：

yum install memcached

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

啟動一個Memcached應用，常見的啟動方式是這樣的：
開啟一個memcached應用作守護進程，TCP連接，端口號是 11211；-u參數是運行Memcached應用的用戶（這個參數也只有 root用戶才能使用）；

memcached -u root -p 11211 -d -vvv 

其他常見的參數也有

-m ：分配給Memcached應用使用的內存大小，默認是 64M；

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

-c ：設置最大運行的并發連接數，默認是 1024；

-f ：設置slat大小增長因子；默認是 1.25；比如說 10號slab大小是752，那么11號slab大小就是 752 * 1.25；

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

telnet [host] [port]

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

set
存儲數據。如果set的key已經存在，該命令可以更新該key所對應的原來的數據，也就是實現更新的作用。詳細命令指南可參考菜鳥教程 - Memcached set 命令；

add
只有在set的key不存在的情況下，才會存儲數據；詳細命令指南可參考菜鳥教程 - Memcached add 命令；

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

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

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

cas
命令用于執行一個"檢查并設置"的操作。它僅在當前客戶端最后一次取值后，該key 對應的值沒有被其他客戶端修改的情況下，才能夠將值寫入。檢查是通過cas_token參數進行的， 這個參數是Memcach指定給已經存在的元素的一個唯一的 64 位值。詳細命令指南可參考菜鳥教程 - Memcached cas 命令；

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

gets
獲取帶有CAS令牌的數據值；詳細命令指南可參考菜鳥教程 - Memcached gets 命令；

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

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

stats
查看memcached所有的統計信息；詳細命令指南可參考菜鳥教程 - Memcached stats 命令；

stats items
顯示各個slab中item的數目和存儲時長等其它信息；詳細命令指南可參考菜鳥教程 - Memcached stats items 命令；

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

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

flush_all
清除所有緩存數據；詳細命令指南可參考菜鳥教程 - Memcached flush_all 命令；

根據服務器節點數的余數來進行分散，就是通過hash函數求得的Key的整數哈希值再除以服務器節點數并取余數來選擇服務器。這種算法取余計算簡單，分散效果好，但是缺點是如果某一臺機器宕機，那么應該落在該機器的請求就無法得到正確的處理，這時需要將當掉的服務器從算法從去除，此時候會有 (N-1) / N 的服務器的緩存數據需要重新進行計算；如果新增一臺機器，會有N / (N+1)的服務器的緩存數據需要進行重新計算。對于系統而言，這通常是不可接受的顛簸（因為這意味著大量緩存的失效或者數據需要轉移）。

【本段內容摘自大臉貓的博客】

表現為一個封閉的圓環，圓環上的點分別代表0 ~ 2^32。各個memcached節點根據hash算法，分別占據圓環上的一個點，當某key進行存儲操作，會針對key進行hash操作，hash后也是圓環上的一個點，那么這個key將被存儲在順時針方向的第一個節點上。

如上圖：分配不均的節點，此時key將會被存儲到節點C上。

此時，我們新增節點D，如下圖。受影響的部分只有節點A~節點D中間的部分，這邊分數據不會再映射到節點B上，而是映射到新增節點D上。減掉一個節點同理，只影響順時針后面一個節點。

優點：動態的增刪節點，服務器down機，影響的只是順時針的下一個節點
缺點：當服務器進行hash后值較為接近會導致在圓環上分布不均勻，進而導致key的分布、服務器的壓力不均勻。若中間某一權重較大的serverdown機，命中率下降明顯；

在一致性哈希算法的基礎上引入虛擬節點

引入虛擬節點的思想，解決一致性hash算法分布不均導致負載不均的問題。一個真實節點對應若干個虛擬節點，當key被映射到虛擬節點上時，則被認為映射到虛擬節點所對應的真實節點上。

優點：引入虛擬節點的思想，每個物理節點對應圓環上若干個虛擬節點（比如200~300個），當keyhash到虛擬節點，就會存儲到實際的物理節點上，有效的實現了負載均衡；

【本段內容摘自魚我所欲也的“memcached學習 - 分布式算法”文章】

緩存雪崩一般是由某個緩存節點失效，導致其他節點的緩存命中率下降，緩存中缺失的數據去數據庫查詢，短時間內，造成數據庫服務器崩潰；

重啟DB，短期又被壓垮，但緩存數據也多一些；DB反復多次啟動多次，緩存重建完畢，DB才穩定運行；或者，是由于緩存周期性的失效，比如每 6 小時失效一次，那么每 6 小時，將有一個請求“峰值”，嚴重者甚至會令DB崩潰；

該問題由 facebook 的工作人員提出的, facebook 在 2010 年左右，memcached節點就已經達3000 個.緩存數千 G 內容。

他們發現了一個問題，memcached 連接頻率，效率下降了，于是加 memcached 節點，添加了后，發現因為連接頻率導致的問題，仍然存在，并沒有好轉，稱之為“無底洞現象”。

以用戶為例: user-133-age， user-133-name，user-133-height .....N 個 key，當服務器增多，133 號用戶的信息，也被散落在更多的節點，所以，同樣是訪問個人主頁，得到相同的個人信息， 節點越多，要連接的節點也越多。

對于 memcached 的連接數，并沒有隨著節點的增多，而降低。 于是問題出現。

把某一組key，按其共同前綴，來分布。比如 user-133-age， user-133-name，user-133-height 這 3 個 key，在用分布式算法求其節點時，應該以 ‘user-133’來計算，而不是以 user-133-age/name/height 來計算。

這樣，3 個關于個人信息的 key，都落在同 1 個節點上，訪問個人主頁時，只需要連接 1 個節點。

網上有人反饋為"memcached 數據丟失"，明明設為永久有效，卻莫名其妙的丟失了。

分析原因：

如果 slab 里的很多 chunk，已經過期，但過期后沒有被 get 過， 系統不知他們已經過期。

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

當然，如果那些非永久數據被 get，也會被標識為 expire，從而不會再踢掉永久數據；

解決方案：永久數據和非永久數據分開放；