今天有人問到我：memcache存儲大數據量，10K，100K，1M的時候，效果怎么樣？？
我回答：不好，效果非常慢。
對方問：為什么啊？？
我回答不上來。。。於是就找了點資料。
memcached使用需要注意的知識：
1、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，
2、適用memcached的業務場景？
1）如果網站包含了訪問量很大的動態網頁，因而數據庫的負載將會很高。由於大部分數據庫請求都是讀操作，那么memcached可以顯著地減小數據庫負載。
2）如果數據庫服務器的負載比較低但CPU使用率很高，這時可以緩存計算好的結果（ computed objects ）和渲染后的網頁模板（enderred templates）。
3）利用memcached可以緩存session數據、臨時數據以減少對他們的數據庫寫操作。
4）緩存一些很小但是被頻繁訪問的文件。
5）緩存Web 'services'（非IBM宣揚的Web Services，譯者注）或RSS feeds的結果.。
3、不適用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
4、 不能能夠遍歷memcached中所有的item
這個操作的速度相對緩慢且阻塞其他的操作（這里的緩慢時相比memcached其他的命令）。memcached所有非調試（non-debug）命令，例如add, set, get, fulsh等無論
memcached中存儲了多少數據，它們的執行都只消耗常量時間。任何遍歷所有item的命令執行所消耗的時間，將隨着memcached中數據量的增加而增加。當其他命令因為等待（遍歷所有item的命令執行完畢）而不能得到執行，因而阻塞將發生。
5、 memcached能接受的key的最大長度是250個字符
memcached能接受的key的最大長度是250個字符。需要注意的是，250是memcached服務器端內部的限制。如果使用的 Memcached客戶端支持"key的前綴"或類似特性，那么key（前綴+原始key）的最大長度是可以超過250個字符的。推薦使用較短的key， 這樣可以節省內存和帶寬。
6、 單個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系統。
7、 memcached的內存分配器是如何工作的？為什么不適用malloc/free！？為何要使用slabs？
實際上，這是一個編譯時選項。默認會使用內部的slab分配器，而且確實應該使用內建的slab分配器。最早的時候，memcached只使用 malloc/free來管理內存。然而，這種方式不能與OS的內存管理以前很好地工作。反復地malloc/free造成了內存碎片，OS最終花費大量 的時間去查找連續的內存塊來滿足malloc的請求，而不是運行memcached進程。slab分配器就是為了解決這個問題而生的。內存被分配並划分成 chunks，一直被重復使用。因為內存被划分成大小不等的slabs，如果item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。
8、memcached對item的過期時間有什么限制？
item對象的過期時間最長可以達到30天。memcached把傳入的過期時間（時間段）解釋成時間點后，一旦到了這個時間點，memcached就把item置為失效狀態，這是一個簡單但obscure的機制。
9、什么是二進制協議，是否需要關注？
二進制協議嘗試為端提供一個更有效的、可靠的協議，減少客戶端/服務器端因處理協議而產生的CPU時間。根據Facebook的測試，解析ASCII協議是memcached中消耗CPU時間最多的
環節。
10、 memcached的內存分配器是如何工作的？為什么不適用malloc/free！？為何要使用slabs？
實際上，這是一個編譯時選項。默認會使用內部的slab分配器，而且確實應該使用內建的slab分配器。最早的時候，memcached只使用 malloc/free來管理內存。然而，這種方式不能與OS的內存管理以前很好地工作。反復地malloc/free造成了內存碎片，OS最終花費大量 的時間去查找連續的內存塊來滿足malloc的請求，而不是運行memcached進程。slab分配器就是為了解決這個問題而生的。內存被分配並划分成 chunks，一直被重復使用。因為內存被划分成大小不等的slabs，如果item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。
11、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中的唯一標識將會改變，寫操作就會