memcache 存儲單個KEY，數據量過大的時候性能慢！以及簡單的memcache不適合用到的場景

今天有人問到我：memcache存儲大數據量，10K，100K，1M的時候，效果怎麼樣？？
我回答：很差，效果很是慢。
對方問：爲何啊？？
我回答不上來。。。因而就找了點資料。

memcached使用須要注意的知識：

一、memcached的基本設置
1）啓動Memcache的服務器端
# /usr/local/bin/memcached -d -m 10 -u root -l 192.168.0.200 -p 12000 -c 256 -P /tmp/memcached.pid

-d選項是啓動一個守護進程，
-m是分配給Memcache使用的內存數量，單位是MB，我這裏是10MB，
-u是運行Memcache的用戶，我這裏是root，
-l是監聽的服務器IP地址，若是有多個地址的話，我這裏指定了服務器的IP地址192.168.0.200，
-p是設置Memcache監聽的端口，我這裏設置了12000，最好是1024以上的端口，
-c選項是最大運行的併發鏈接數，默認是1024，我這裏設置了256，按照你服務器的負載量來設定，
-P是設置保存Memcache的pid文件，我這裏是保存在 /tmp/memcached.pid，

 

二、適用memcached的業務場景？

1）若是網站包含了訪問量很大的動態網頁，於是數據庫的負載將會很高。因爲大部分數據庫請求都是讀操做，那麼memcached能夠顯著地減少數據庫負載。

2）若是數據庫服務器的負載比較低但CPU使用率很高，這時能夠緩存計算好的結果（ computed objects ）和渲染後的網頁模板（enderred templates）。

3）利用memcached能夠緩存session數據、臨時數據以減小對他們的數據庫寫操做。

4）緩存一些很小可是被頻繁訪問的文件。

5）緩存Web 'services'（非IBM宣揚的Web Services，譯者注）或RSS feeds的結果.。

三、不適用memcached的業務場景？

1）緩存對象的大小大於1MB

Memcached自己就不是爲了處理龐大的多媒體（large media）和巨大的二進制塊（streaming huge blobs）而設計的。

2）key的長度大於250字符

3）虛擬主機不讓運行memcached服務

     若是應用自己託管在低端的虛擬私有服務器上，像vmware, xen這類虛擬化技術並不適合運行memcached。Memcached須要接管和控制大塊的內存，若是memcached管理      的內存被OS或 hypervisor交換出去，memcached的性能將大打折扣。

4）應用運行在不安全的環境中

Memcached爲提供任何安全策略，僅僅經過telnet就能夠訪問到memcached。若是應用運行在共享的系統上，須要着重考慮安全問題。

5）業務自己須要的是持久化數據或者說須要的應該是database

四、 不能可以遍歷memcached中全部的item

     這個操做的速度相對緩慢且阻塞其餘的操做（這裏的緩慢時相比memcached其餘的命令）。memcached全部非調試（non-debug）命令，例如add, set, get, fulsh等不管

memcached中存儲了多少數據，它們的執行都只消耗常量時間。任何遍歷全部item的命令執行所消耗的時間，將隨着memcached中數據量的增長而增長。當其餘命令由於等待（遍歷全部item的命令執行完畢）而不能獲得執行，於是阻塞將發生。

五、  memcached能接受的key的最大長度是250個字符

memcached能接受的key的最大長度是250個字符。須要注意的是，250是memcached服務器端內部的限制。若是使用的 Memcached客戶端支持"key的前綴"或相似特性，那麼key（前綴+原始key）的最大長度是能夠超過250個字符的。推薦使用較短的key， 這樣能夠節省內存和帶寬。

六、  單個item的大小被限制在1M byte以內

由於內存分配器的算法就是這樣的。

詳細的回答：

1）Memcached的內存存儲引擎，使用slabs來管理內存。內存被分紅大小不等的slabs chunks（先分紅大小相等的slabs，而後每一個slab被分紅大小相等chunks，不一樣slab的chunk大小是不相等的）。chunk的大小 依次從一個最小數開始，按某個因子增加，直到達到最大的可能值。若是最小值爲400B，最大值是1MB，因子是1.20，各個slab的chunk的大小 依次是：

slab1 - 400B；slab2 - 480B；slab3 - 576B ...slab中chunk越大，它和前面的slab之間的間隙就越大。所以，最大值越大，內存利用率越低。Memcached必須爲每一個slab預先分 配內存，所以若是設置了較小的因子和較大的最大值，會須要爲Memcached提供更多的內存。

2）不要嘗試向memcached中存取很大的數據，例如把巨大的網頁放到mencached中。由於將大數據load和unpack到內存中須要 花費很長的時間，從而致使系統的性能反而很差。若是確實須要存儲大於1MB的數據，能夠修改slabs.c：POWER_BLOCK的值，而後從新編譯 memcached；或者使用低效的malloc/free。另外，可使用數據庫、MogileFS等方案代替Memcached系統。

七、  memcached的內存分配器是如何工做的？爲何不適用malloc/free！？爲什麼要使用slabs？

實際上，這是一個編譯時選項。默認會使用內部的slab分配器，並且確實應該使用內建的slab分配器。最先的時候，memcached只使用 malloc/free來管理內存。然而，這種方式不能與OS的內存管理之前很好地工做。反覆地malloc/free形成了內存碎片，OS最終花費大量 的時間去查找連續的內存塊來知足malloc的請求，而不是運行memcached進程。slab分配器就是爲了解決這個問題而生的。內存被分配並劃分紅 chunks，一直被重複使用。由於內存被劃分紅大小不等的slabs，若是item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。

八、memcached對item的過時時間有什麼限制？

item對象的過時時間最長能夠達到30天。memcached把傳入的過時時間（時間段）解釋成時間點後，一旦到了這個時間點，memcached就把item置爲失效狀態，這是一個簡單但obscure的機制。

九、什麼是二進制協議，是否須要關注？

二進制協議嘗試爲端提供一個更有效的、可靠的協議，減小客戶端/服務器端因處理協議而產生的CPU時間。根據Facebook的測試，解析ASCII協議是memcached中消耗CPU時間最多的環節。

十、 memcached的內存分配器是如何工做的？爲何不適用malloc/free！？爲什麼要使用slabs？

實際上，這是一個編譯時選項。默認會使用內部的slab分配器，並且確實應該使用內建的slab分配器。最先的時候，memcached只使用 malloc/free來管理內存。然而，這種方式不能與OS的內存管理之前很好地工做。反覆地malloc/free形成了內存碎片，OS最終花費大量 的時間去查找連續的內存塊來知足malloc的請求，而不是運行memcached進程。slab分配器就是爲了解決這個問題而生的。內存被分配並劃分紅 chunks，一直被重複使用。由於內存被劃分紅大小不等的slabs，若是item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。

十一、memcached是原子的嗎？

全部的被髮送到memcached的單個命令是徹底原子的。若是您針對同一份數據同時發送了一個set命令和一個get命令，它們不會影響對方。它 們將被串行化、前後執行。即便在多線程模式，全部的命令都是原子的。然是，命令序列不是原子的。若是首先經過get命令獲取了一個item，修改了它，然 後再把它set回memcached，系統不保證這個item沒有被其餘進程（process，未必是操做系統中的進程）操做過。memcached 1.2.5以及更高版本，提供了gets和cas命令，它們能夠解決上面的問題。若是使用gets命令查詢某個key的item，memcached會返 回該item當前值的惟一標識。若是客戶端程序覆寫了這個item並想把它寫回到memcached中，能夠經過cas命令把那個惟一標識一塊兒發送給 memcached。若是該item存放在memcached中的惟一標識與您提供的一致，寫操做將會成功。若是另外一個進程在這期間也修改了這個 item，那麼該item存放在memcached中的惟一標識將會改變，寫操做就會