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，

2）若是要結束Memcache進程，執行：

# kill `cat /tmp/memcached.pid`

哈希算法將任意長度的二進制值映射爲固定長度的較小二進制值，這個小的二進制值稱爲哈希值。哈希值是一段數據惟一且極其緊湊的數值表示形式。若是散列一段明文並且哪怕只更改該

段落的一個字母，隨後的哈希都將產生不一樣的值。要找到散列爲同一個值的兩個不一樣的輸入，在計算上是不可能的。

二、一致性Hash算法的目的有兩點：一是節點變更後其餘節點受影響儘量小；二是節點變更後數據從新分配儘量均衡 。

三、爲何要運行 memcached ？

若是網站的高流量很大而且大多數的訪問會形成數據庫高負荷的情況下，使用 memcached 可以減輕數據庫的壓力。

四、適用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是怎麼工做的？

Memcached的高性能源於兩階段哈希（two-stage hash）結構。Memcached就像一個巨大的、存儲了不少<key,value>對的哈希表。經過key，能夠存儲或查詢任意的數據。 客戶端

能夠把數據存儲在多臺memcached上。當查詢數據時，客戶端首先參考節點列表計算出key的哈希值（階段一哈希），進而選中一個節點；客戶端將請求發送給選中的節點，而後

memcached節點經過一個內部的哈希算法（階段二哈希），查找真正的數據（item）並返回給客戶端。從實現的角度看，memcached是一個非阻塞的、基於事件的服務器程序。

八、memcached最大的優點是什麼？

Memcached最大的好處就是它帶來了極佳的水平可擴展性，特別是在一個巨大的系統中。因爲客戶端本身作了一次哈希，那麼咱們很容易增長大量memcached到集羣中。memcached

之間沒有相互通訊，所以不會增長 memcached的負載；沒有多播協議，不會網絡通訊量爆炸（implode）。

九、memcached和MySQL的query cache相比，有什麼優缺點？

缺點：

1）相比MySQL的query cache，把memcached引入應用中須要很多的工做量。MySQL的query cache，能夠自動地緩存SQL查詢的結果，被緩存的SQL查詢能夠被反覆、快速的執行。

優勢：

1）當修改表時，MySQL的query cache會馬上被刷新（flush）。當寫操做很頻繁時，MySQL的query cache會常常讓全部緩存數據都失效。

2）在多核CPU上，MySQL的query cache會遇到擴展問題（scalability issues）。在多核CPU上，query cache會增長一個全局鎖（global lock）, 因爲須要刷新更多的緩存數據，速度

會變得更慢。

3）在MySQL的query cache中，是不能存儲任意的數據的（只能是SQL查詢結果）。利用memcached，咱們能夠搭建出各類高效的緩存。好比，能夠執行多個獨立的查詢，構建出一個

用戶對象（user object），而後將用戶對象緩存到memcached中。而query cache是SQL語句級別的，不可能作到這一點。在小的網站中，query cache會有所幫助，但隨着網站規模的

增長，query cache的弊將大於利。

4）query cache可以利用的內存容量受到MySQL服務器空閒內存空間的限制。給數據庫服務器增長更多的內存來緩存數據，當然是很好的。可是，有了memcached，只要您有空閒的內

存，均可以用來增長memcached集羣的規模，而後您就能夠緩存更多的數據。

十、memcached和服務器的local cache（好比PHP的APC、mmap文件等）相比，有什麼優缺點？

1）首先，local cache面臨着嚴重的內存限制，可以利用的內存容量受到（單臺）服務器空閒內存空間的限制。

2）local cache有一點比memcached和query cache都要好，那就是它不但能夠存儲任意的數據，並且沒有網絡存取的延遲。所以，local cache的數據查詢更快。考慮把highly

common的數據放在local cache中吧。若是每一個頁面都須要加載一些數量較少的數據，能夠考慮把它們放在local cached。

3）local cache缺乏集體失效（group invalidation）的特性。在memcached集羣中，刪除或更新一個key會讓全部的觀察者覺察到。可是在local cache中, 咱們只能通知全部的服務器

刷新cache（很慢，不具擴展性）或者僅僅依賴緩存超時失效機制。

十一、memcached的cache機制是怎樣的？

Memcached主要的cache機制是LRU（最近最少用）算法+超時失效。當您存數據到memcached中，能夠指定該數據在緩存中能夠呆多久Which is forever, or some time in the

future。若是memcached的內存不夠用了，過時的slabs會優先被替換，接着就輪到最老的未被使用的slabs。

十二、memcached如何實現冗餘機制？

不實現！Memcached應該是應用的緩存層，從設計自己來京就不帶有任何冗餘機制。若是一個memcached節點失去了全部數據，應該能夠從數據源（好比數據庫）再次獲取到數據。應

用系統應該能夠容忍節點的失效。若是擔憂節點失效會大大加劇數據庫的負擔，那麼能夠採起一些辦法。好比您能夠增長更多的節點（來減小丟失一個節點的影響），熱備節點（在其餘節

點down了的時候接管IP）等等。

1三、memcached如何處理容錯的？

在節點失效的狀況下，集羣沒有必要作任何容錯處理。若是發生了節點失效，應對的措施徹底取決於用戶。

節點失效時，下面列出幾種方案供您選擇：

1）忽略它！ 在失效節點被恢復或替換以前，還有不少其餘節點能夠應對節點失效帶來的影響。

2）把失效的節點從節點列表中移除。作這個操做千萬要當心！在默認狀況下（餘數式哈希算法），客戶端添加或移除節點，會致使全部的緩存數據不可用！由於哈希參照的節點列表變化

了，大部分key會由於哈希值的改變而被映射到（與原來）不一樣的節點上。

3）啓動熱備節點，接管失效節點所佔用的IP。這樣能夠防止哈希紊亂（hashing chaos）。

4）若是但願添加和移除節點，而不影響原先的哈希結果，可使用一致性哈希算法（consistent hashing）。

5）兩次哈希（reshing）。當客戶端存取數據時，若是發現一個節點down了，就再作一次哈希（哈希算法與前一次不一樣），從新選擇另外一個節點（須要注意的時，客戶端並無把down

的節點從節點列表中移除，下次仍是有可能先哈希到它）。若是某個節點時好時壞，兩次哈希的方法就有風險了，好的節點和壞的節點上均可能存在髒數據（stale data）。

1四、如何將memcached中item批量導入導出？

不該該這樣作！Memcached是一個非阻塞的服務器。任何可能致使memcached暫停或瞬時拒絕服務的操做都應該值得深思熟慮。向memcached中批量導入數據每每不是您真正想要

的！想象看，若是緩存數據在導出導入之間發生了變化，您就須要處理髒數據了；若是緩存數據在導出導入之間過時了，您又怎麼處理這些數據呢？

所以，批量導出導入數據並不像想象中的那麼有用。不過在一個場景卻是頗有用。若是您有大量的從不變化 的數據，而且但願緩存很快熱（warm）起來，批量導入緩存數據是頗有幫助

的。

1五、可是我確實須要把memcached中的item批量導出導入，怎麼辦？？

若是須要批量導出和導入，最可能的緣由通常是從新生成緩存數據須要消耗很長的時間或者數據庫壞了讓您飽受痛苦。

若是一個memcached節點down了讓您很痛苦，那麼必須對數據庫作一些優化工做。好比處理"驚羣"問題（ memcached節點都失效了，反覆的查詢讓數據庫不堪重負）或者存在優化不

好的查詢等。Memcached 並非逃避優化查詢的藉口和方案。

這裏給出一些提示：

使用MogileFS（或者CouchDB等相似的軟件）在存儲item，把item計算出來並dump到磁盤上。MogileFS能夠很方便地覆寫item，並提供快速地訪問。甚至能夠把MogileFS中的item

緩存在memcached中，這樣能夠加快讀取速度。 MogileFS+Memcached的組合能夠加快緩存不命中時的響應速度，提升網站的可用性。

從新使用MySQL。MySQL的 InnoDB主鍵查詢速度很是快。若是大部分緩存數據均可以放到VARCHAR字段中，那麼主鍵查詢的性能將更好。從memcached中按key查詢幾乎等價於

MySQL的主鍵查詢：將key 哈希到64-bit的整數，而後將數據存儲到MySQL中。您能夠把原始（不作哈希）的key存儲都普通的字段中，而後創建二級索引來加快查詢...key被動地失效，

批量刪除失效的key，等等。

1六、memcached是如何作身份驗證的？

沒有身份認證機制！memcached是運行在應用下層的軟件（身份驗證應該是應用上層的職責）。memcached的客戶端和服務器端之因此是輕量級的，部分緣由就是徹底沒有實現身份驗

證機制。這樣，memcached能夠很快地建立新鏈接，服務器端也無需任何配置。若是您但願限制訪問，您可使用防火牆，或者讓memcached監聽unix domain socket。

1七、memcached的多線程是什麼？如何使用它們？

線程就是定律（threads rule）！在Steven Grimm和Facebook的努力下，memcached 1.2及更高版本擁有了多線程模式。多線程模式容許memcached可以充分利用多個CPU，並在

CPU之間共享全部的緩存數據。memcached使用一種簡單的鎖機制來保證數據更新操做的互斥。相比在同一個物理機器上運行多個memcached實例，這種方式可以更有效地處理multi

gets。若是系統的負載並不重，那麼不須要啓用多線程工做模式。若是您在運行一個擁有大規模硬件的、龐大的網站，將體驗到看到多線程的好處。更多信息請參見：

http://code.sixapart.com/svn/memcached/trunk/server/doc/threads.txt 。

簡單地總結一下：命令解析（memcached在這裏花了大部分時間）能夠運行在多線程模式下。memcached內部對數據的操做是基於不少全局鎖的（所以這部分工做不是多線程的）。未

來對多線程模式的改進，將移除大量的全局鎖，提升memcached在負載極高的場景下的性能。

1八、memcached能接受的key的最大長度是多少？

memcached能接受的key的最大長度是250個字符。須要注意的是，250是memcached服務器端內部的限制。若是使用的Memcached客戶端支持"key的前綴"或相似特性，那麼key

（前綴+原始key）的最大長度是能夠超過250個字符的。推薦使用較短的key，這樣能夠節省內存和帶寬。

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

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

obscure的機制。

20、memcached最大能存儲多大的單個item？

memcached最大能存儲1MB的單個item。若是須要被緩存的數據大於1MB，能夠考慮在客戶端壓縮或拆分到多個key中。

2一、爲何單個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系統。

2二、能夠在不一樣的memcached節點上使用大小不等的緩存空間嗎？若是這麼作以後，memcached可以更有效地使用內存嗎？

Memcache客戶端僅根據哈希算法來決定將某個key存儲在哪一個節點上，而不考慮節點的內存大小。所以，能夠在不一樣的節點上使用大小不等的內存做爲緩存空間。可是通常能夠這樣作

：擁有較多內存的節點上能夠運行多個memcached實例，每一個實例使用的內存跟其餘節點上的實例相同。

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

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

環節。

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

實際上，這是一個編譯時選項。默認會使用內部的slab分配器，並且確實應該使用內建的slab分配器。最先的時候，memcached只使用malloc/free來管理內存。然而，這種方式不能與

OS的內存管理之前很好地工做。反覆地malloc/free形成了內存碎片，OS最終花費大量的時間去查找連續的內存塊來知足malloc的請求，而不是運行memcached進程。slab分配器就是

爲了解決這個問題而生的。內存被分配並劃分紅chunks，一直被重複使用。由於內存被劃分紅大小不等的slabs，若是item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。

2五、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中的惟一標識將會改變，寫操做就會

失敗。

性能和客戶端庫方面的問題

2六、memcached沒有個人database快，爲何？

在一對一比較中，memcached可能沒有SQL查詢快。可是，這不是memcached的設計目標。Memcached的目標是可伸縮性。當鏈接和請求增長的時候，memcached的性能將比

大多數數據庫查詢好。能夠先在高負載的環境（併發的鏈接和請求）中測試您的代碼，而後再決定memcached是否適合您。

2七、使用不一樣的客戶端庫，能夠訪問到memcached中相同的數據嗎？

從技術上說，是能夠的。可是可能會遇到下面三個問題：

1）不一樣的庫採用不一樣的方式序列化數據。舉個例子，perl的Cache::Memcached使用Storable來序列化結構複雜的數據（好比hash references, objects, 等）。其餘語言的客戶端庫很

可能不能讀取這種格式的數據。若是您要存儲複雜的數據而且想被多種客戶端庫讀取，那麼您應該以簡單的string格式來存儲，而且這種格式能夠被JSON、XML等外部庫解析。

2）從某個客戶端來的數據被壓縮了，從另外一個客戶端來的卻沒被壓縮。

3）各個客戶端庫可能使用不一樣的哈希算法（階段一哈希）。在鏈接到多個memcached服務器端的狀況下，客戶端庫根據自身實現的哈希算法把key映射到某臺memcached上。正是由於

不一樣的客戶端庫使用不一樣的哈希算法，因此被Perl客戶端庫映射到memcached A的key，可能又會被Python客戶端庫映射到memcached B，等等。Perl客戶端庫還容許爲每臺

memcached指定不一樣的權重（weight），這也是致使這個問題的一個因素。

2八、什麼是一致性哈希的客戶端？

這裏有一篇文章很好地解釋了它的用處：http://www.last.fm/user/RJ/journal/2007/04/10/392555 。

客戶端能夠經過"前綴"來給key設置一個域（命名空間）。例如，在一個共享主機的環境中，能夠將客戶姓名做爲"前綴"，爲key建立一個特定的域。在存儲數據的時候，"前綴"能夠用在

key上，可是不該該參與哈希計算。目前，memcached本身尚未實現針對複雜結構數據的序列化方法，JSON則是一種被普遍使用的對象序列化格式。

哈希 / 鍵分佈

2九、何時失效的數據項會從緩存中刪除？

memcached 使用懶失效，當客戶端請求數據項時， memcached 在返回數據前會檢查失效時間來肯定數據項是否已經失效。一樣地，當添加一個新的數據項時，若是緩存已經滿了， memcached 就會先替換失效的數據項，而後纔是緩存中最少使用的數據項。

命名空間

30、memcached 不支持命名空間。如下提供幾種模仿命名空間的方式：

1）用鍵的前綴模仿命名空間：在真實的鍵以前加入有意義的前綴。

2）用命名空間刪除數據項：儘管 memcached 不支持使用任何類型的通配符或命名空間來完成刪除操做，可是能夠採用一些技巧來替代：

在 PHP 中使用一個叫 foo 的命名空間：$ns_key = $memcache->get("foo_namespace_key");

// if not set, initialize it

if($ns_key=false) $memcache->set("foo_namespace_key", rand(1, 10000));

$my_key = "foo_".$ns_key."_12345";//須要緩存內容的key

清除命名空間：$memcache->increment("foo_namespace_key");//key增長1，利用memcached的LRU最少使用的key將給替換

應用設計

3一、在設計應用時，能夠經過Memcached緩存那些內容？

1）緩存簡單的查詢結果：查詢緩存存儲了給定查詢語句對應的整個結果集，最合適緩存那些常常被用到，但不會改變的 SQL 語句對查詢到的結果集，好比載入特定的過濾內容。

$key = md5('SELECT * FROM rest_of_sql_statement_goes_here');

if ($memcache->get($key)) {

      ` return $memcache->get($key);`

}else {

    ` // Run the query and transform the result data into your final dataset form`

    ` $result = $query_results_mangled_into_most_likely_an_array`

     ` $memcache->set($key, $result, TRUE, 86400); // Store the result of the query for a day`

    ` return $result;`

}

記住，若是查詢語句對應的結果集改變，該結果集不會展示出來。這種方法不老是有用，但它確實讓工做變得比較快。

2）緩存簡單的基於行的查詢結果：基於行的緩存會檢查緩存數據key的列表，那些在緩存中的行能夠直接被取出，不在緩存中的行將會從數據庫中取出並以惟一的鍵爲標識緩存起來，最

後加入到最終的數據集中返回。隨着時間的推移，大多數數據都會被緩存，這也意味着相比與數據庫，查詢語句會更多地從 memcached 中獲得數據行。若是數據是至關靜態的，咱們可

以設置一個較長的緩存時間。

基於行的緩存模式對下面這種搜索狀況特別有用：數據集自己很大或是數據集是從多張表中獲得，而數據集取決於查詢的輸入參數可是查詢的結果集之間的有重複部分。

好比，若是你有用戶 A ， B ， C ， D ， E 的數據集。你去點擊一張顯示用戶 A ， B ， E 信息的頁面。首先， memcached 獲得 3 個不一樣的鍵，每一個對應一個用戶去緩存中查找，所有未

命中。而後就到數據庫中用 SQL 查詢獲得 3 個用戶的數據行，並緩存他們。

如今，你又去點擊另外一張顯示顯示 C ， D ， E 信息的頁面。當你去查找 memcached 時， C ， D 的數據並無被命中，但咱們命中了 E 的數據。而後從數據庫獲得 C ， D 的行數據，緩

存在 memcached 中。至此之後，不管這些用戶信息怎樣地排列組合，任何關於 A ， B ， C ， D ， E 信息的頁面均可以從 memcached 獲得數據了。

3）緩存的不僅是 SQL 數據，能夠緩存最終完成的部分顯示頁面，以節省CPU計算時間

例如正在製做一張顯示用戶信息的頁面，你可能獲得一段關於用戶的信息（姓名，生日，家庭住址，簡介），而後你可能會將 XML 格式的簡介信息轉化爲 HTML 格式或作其餘的一些工

做。相比單獨存儲這些屬性，你可能更願意存儲通過渲染的數據塊。那時你就能夠簡單地取出被預處理後的 HTML 直接填充在頁面中，這樣節省了寶貴的 CPU 時間。

3二、使用分層的緩存

memcached 能夠高速處理大量的緩存數據，可是仍是要根據系統的狀況考慮維護多層的緩存結構。例如除了memcached緩存以外，還能夠經過本地緩存（如ehcache、oscache等）建

立起多級緩存。例如，能夠採用本地緩存緩存一些基本數據，例如少許但訪問頻繁的數據（如產品分類，鏈接信息，服務器狀態變量，應用配置變量等），緩存這些數據並讓他們儘量的

接近處理器是有意義的 , 這樣能夠幫助減小生成頁面的時間，而且在 memcached 失效的狀況下能夠增長可靠性。

3三、當數據更新時須要更新緩存

用戶編輯了本身的信息，當保存信息到數據庫時，須要更新緩存中的數據或是簡單地刪除老的數據。若是立刻更新數據，要防止從數據庫讀取那些剛剛更新過的數據。當用戶習慣性地從新

載入本身的用戶信息來確認是否修改爲功時，數據將從緩存中直接取出，這時他們得到了最新的數據。

3四、模擬帶鎖的添加命令

若是你實在須要鎖，你能夠經過「添加」命令模仿鎖的功能。儘管在未命中的狀況下它不是那麼有用，但若是你用它緩存日常的數據（應用服務器池的元數據）那仍是有用的。

好比，你要更新鍵 A 。

1. 添加一個 "lock:A" 的鍵，這個鍵有一個持續幾秒的過時時間（足夠長以使你能完成計算和更新，也不要很長，由於若是鎖進程掛了，這個鍵不會當即釋放）

2. 若是添加操做成功了，你就擁有了鎖：從緩存獲取鍵 A 的數據；利用客戶端程序更改數據；更新緩存鍵 A 的數據；刪除鍵 "lock:A" 。若是你不須要當即再次更新，就讓它存活直到失效。

3. 若是添加操做失敗，說明有人獲取了鎖。這時讓應用作些合適的事，好比返回老數據，等待後重試，或是其餘的。

以上這些操做相似 MySQL 將 GET_LOCK 的 timeout 值設置成 0 。沒有辦法在 memcached 中經過互斥鎖模擬 GET_LOCK() 的 timeout 操做。

3五、預熱你的緩存

若是你有一個很高訪問率的站點，而且你正想加入故障恢復功能或是其餘全新的功能，你最終可能會碰到空緩存的問題。一開始緩存是空的，而後一大羣人點擊你的站點，在填充緩存的過

程中，你的數據庫可能會承受不住壓力。爲了解決這一問題，你能夠試試任何可行的方法來 " 溫暖 " 你的Memcached。方法：能夠寫一些腳原本緩存通用的頁面；也能夠寫一個命令行工

具來填充緩存。你能夠在高峯時刻在緩存裏填充一些內容。

參考網頁:

http://shwangking-126-com.iteye.com/blog/284937