memcache的最佳實踐

基本問題
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）如果要結束Memcache程式，執行：
# kill `cat /tmp/memcached.pid`
雜湊演算法將任意長度的二進位制值對映為固定長度的較小二進位制值，這個小的二進位制值稱為雜湊值。雜湊值是一段資料唯一且極其緊湊的數值表示形式。如果雜湊一段明文而且哪怕只更改該段落的一個字母，隨後的雜湊都將產生不同的值。要找到雜湊為同一個值的兩個不同的輸入，在計算上是不可能的。

2、一致性Hash演算法的目的有兩點：一是節點變動後其他節點受影響儘可能小；二是節點變動後資料重新分配儘可能均衡 。

3、為什麼要執行 memcached ？
如果網站的高流量很大並且大多數的訪問會造成資料庫高負荷的狀況下，使用 memcached 能夠減輕資料庫的壓力。

4、適用memcached的業務場景？
1）如果網站包含了訪問量很大的動態網頁，因而資料庫的負載將會很高。由於大部分資料庫請求都是讀操作，那麼memcached可以顯著地減小資料庫負載。
2）如果資料庫伺服器的負載比較低但CPU使用率很高，這時可以快取計算好的結果（ computed objects ）和渲染後的網頁模板（enderred templates）。
3）利用memcached可以快取session資料、臨時資料以減少對他們的資料庫寫操作。
4）快取一些很小但是被頻繁訪問的檔案。
5）快取Web 'services'（非IBM宣揚的Web Services，譯者注）或RSS feeds的結果.。

5、不適用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

6、能夠遍歷memcached中所有的item嗎？
不能，這個操作的速度相對緩慢且阻塞其他的操作（這裡的緩慢時相比memcached其他的命令）。memcached所有非除錯（non-debug）命令，例如add, set, get, fulsh等無論memcached中儲存了多少資料，它們的執行都只消耗常量時間。任何遍歷所有item的命令執行所消耗的時間，將隨著memcached中資料量的增加而增加。當其他命令因為等待（遍歷所有item的命令執行完畢）而不能得到執行，因而阻塞將發生。

叢集的相關問題
7、memcached是怎麼工作的？
Memcached的高效能源於兩階段雜湊（two-stage hash）結構。Memcached就像一個巨大的、儲存了很多對的雜湊表。透過key，可以儲存或查詢任意的資料。 客戶端可以把資料儲存在多臺memcached上。當查詢資料時，客戶端首先參考節點列表計算出key的雜湊值（階段一雜湊），進而選中一個節點；客戶端將請求傳送給選中的節點，然後memcached節點透過一個內部的雜湊演算法（階段二雜湊），查詢真正的資料（item）並返回給客戶端。從實現的角度看，memcached是一個非阻塞的、基於事件的伺服器程式。

8、memcached最大的優勢是什麼？
Memcached最大的好處就是它帶來了極佳的水平可擴充套件性，特別是在一個巨大的系統中。由於客戶端自己做了一次雜湊，那麼我們很容易增加大量memcached到叢集中。memcached之間沒有相互通訊，因此不會增加 memcached的負載；沒有多播協議，不會網路通訊量爆炸（implode）。

9、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叢集的規模，然後您就可以快取更多的資料。

10、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（很慢，不具擴充套件性）或者僅僅依賴快取超時失效機制。

11、memcached的cache機制是怎樣的？
Memcached主要的cache機制是LRU（最近最少用）演算法+超時失效。當您存資料到memcached中，可以指定該資料在快取中可以呆多久Which is forever, or some time in the future。如果memcached的記憶體不夠用了，過期的slabs會優先被替換，接著就輪到最老的未被使用的slabs。

12、memcached如何實現冗餘機制？
不實現！Memcached應該是應用的快取層，從設計本身來京就不帶有任何冗餘機制。如果一個memcached節點失去了所有資料，應該可以從資料來源（比如資料庫）再次獲取到資料。應用系統應該可以容忍節點的失效。如果擔心節點失效會大大加重資料庫的負擔，那麼可以採取一些辦法。比如您可以增加更多的節點（來減少丟失一個節點的影響），熱備節點（在其他節點down了的時候接管IP）等等。

13、memcached如何處理容錯的？
在節點失效的情況下，叢集沒有必要做任何容錯處理。如果發生了節點失效，應對的措施完全取決於使用者。
節點失效時，下面列出幾種方案供您選擇：
1）忽略它！ 在失效節點被恢復或替換之前，還有很多其他節點可以應對節點失效帶來的影響。
2）把失效的節點從節點列表中移除。做這個操作千萬要小心！在預設情況下（餘數式雜湊演算法），客戶端新增或移除節點，會導致所有的快取資料不可用！因為雜湊參照的節點列表變化了，大部分key會因為雜湊值的改變而被對映到（與原來）不同的節點上。
3）啟動熱備節點，接管失效節點所佔用的IP。這樣可以防止雜湊紊亂（hashing chaos）。
4）如果希望新增和移除節點，而不影響原先的雜湊結果，可以使用一致性雜湊演算法（consistent hashing）。
5）兩次雜湊（reshing）。當客戶端存取資料時，如果發現一個節點down了，就再做一次雜湊（雜湊演算法與前一次不同），重新選擇另一個節點（需要注意的時，客戶端並沒有把down 的節點從節點列表中移除，下次還是有可能先雜湊到它）。如果某個節點時好時壞，兩次雜湊的方法就有風險了，好的節點和壞的節點上都可能存在髒資料（stale data）。

14、如何將memcached中item批次匯入匯出？
不應該這樣做！Memcached是一個非阻塞的伺服器。任何可能導致memcached暫停或瞬時拒絕服務的操作都應該值得深思熟慮。向memcached中批次匯入資料往往不是您真正想要的！想象看，如果快取資料在匯出匯入之間發生了變化，您就需要處理髒資料了；如果快取資料在匯出匯入之間過期了，您又怎麼處理這些資料呢？因此，批次匯出匯入資料並不像想象中的那麼有用。不過在一個場景倒是很有用。如果您有大量的從不變化 的資料，並且希望快取很快熱（warm）起來，批次匯入快取資料是很有幫助的。

15、但是我確實需要把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，等等。

16、memcached是如何做身份驗證的？
沒有身份認證機制！memcached是執行在應用下層的軟體（身份驗證應該是應用上層的職責）。memcached的客戶端和伺服器端之所以是輕量級的，部分原因就是完全沒有實現身份驗證機制。這樣，memcached可以很快地建立新連線，伺服器端也無需任何配置。如果您希望限制訪問，您可以使用防火牆，或者讓memcached監聽unix domain socket。

17、memcached的多執行緒是什麼？如何使用它們？
執行緒就是定律（threads rule）！在Steven Grimm和Facebook的努力下，memcached 1.2及更高版本擁有了多執行緒模式。多執行緒模式允許memcached能夠充分利用多個CPU，並在CPU之間共享所有的快取資料。memcached使用一種簡單的鎖機制來保證資料更新操作的互斥。相比在同一個物理機器上執行多個memcached例項，這種方式能夠更有效地處理multi gets。如果系統的負載並不重，那麼不需要啟用多執行緒工作模式。如果您在執行一個擁有大規模硬體的、龐大的網站，將體驗到看到多執行緒的好處。更多資訊請參見：
。
簡單地總結一下：命令解析（memcached在這裡花了大部分時間）可以執行在多執行緒模式下。memcached內部對資料的操作是基於很多全域性鎖的（因此這部分工作不是多執行緒的）。未來對多執行緒模式的改進，將移除大量的全域性鎖，提高memcached在負載極高的場景下的效能。

18、memcached能接受的key的最大長度是多少？
memcached能接受的key的最大長度是250個字元。需要注意的是，250是memcached伺服器端內部的限制。如果使用的Memcached客戶端支援"key的字首"或類似特性，那麼key（字首+原始key）的最大長度是可以超過250個字元的。推薦使用較短的key，這樣可以節省記憶體和頻寬。

19、memcached對item的過期時間有什麼限制？
item物件的過期時間最長可以達到30天。memcached把傳入的過期時間（時間段）解釋成時間點後，一旦到了這個時間點，memcached就把item置為失效狀態，這是一個簡單但 obscure的機制。

20、memcached最大能儲存多大的單個item？
memcached最大能儲存1MB的單個item。如果需要被快取的資料大於1MB，可以考慮在客戶端壓縮或拆分到多個key中。

21、為什麼單個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系統。

22、可以在不同的memcached節點上使用大小不等的快取空間嗎？如果這麼做之後，memcached能夠更有效地使用記憶體嗎？
Memcache客戶端僅根據雜湊演算法來決定將某個key儲存在哪個節點上，而不考慮節點的記憶體大小。因此，可以在不同的節點上使用大小不等的記憶體作為快取空間。但是一般可以這樣做：擁有較多記憶體的節點上可以執行多個memcached例項，每個例項使用的記憶體跟其他節點上的例項相同。

23、什麼是二進位制協議，是否需要關注？
二進位制協議嘗試為端提供一個更有效的、可靠的協議，減少客戶端/伺服器端因處理協議而產生的CPU時間。根據Facebook的測試，解析ASCII協議是memcached中消耗CPU時間最多的環節。

24、memcached的記憶體分配器是如何工作的？為什麼不適用malloc/free！？為何要使用slabs？
實際上，這是一個編譯時選項。預設會使用內部的slab分配器，而且確實應該使用內建的slab分配器。最早的時候，memcached只使用malloc/free來管理記憶體。然而，這種方式不能與OS的記憶體管理以前很好地工作。反覆地malloc/free造成了記憶體碎片，OS最終花費大量的時間去查詢連續的記憶體塊來滿足malloc的請求，而不是執行memcached程式。slab分配器就是為了解決這個問題而生的。記憶體被分配並劃分成chunks，一直被重複使用。因為記憶體被劃分成大小不等的slabs，如果item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些記憶體。

25、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中的唯一標識將會改變，寫操作就會失敗。

效能和客戶端庫方面的問題
26、memcached沒有我的database快，為什麼？
在一對一比較中，memcached可能沒有SQL查詢快。但是，這不是memcached的設計目標。Memcached的目標是可伸縮性。當連線和請求增加的時候，memcached的效能將比大多數資料庫查詢好。可以先在高負載的環境（併發的連線和請求）中測試您的程式碼，然後再決定memcached是否適合您。

27、使用不同的客戶端庫，可以訪問到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），這也是導致這個問題的一個因素。

28、什麼是一致性雜湊的客戶端？
這裡有一篇文章很好地解釋了它的用處： 。
客戶端可以透過"字首"來給key設定一個域（名稱空間）。例如，在一個共享主機的環境中，可以將客戶姓名作為"字首"，為key建立一個特定的域。在儲存資料的時候，"字首"可以用在key上，但是不應該參與雜湊計算。目前，memcached自己還沒有實現針對複雜結構資料的序列化方法，JSON則是一種被廣泛使用的物件序列化格式。

雜湊 / 鍵分佈
29、什麼時候失效的資料項會從快取中刪除？
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";
清除名稱空間：$memcache->increment("foo_namespace_key");

應用設計
31、在設計應用時，可以透過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 時間。

32、使用分層的快取
memcached 可以高速處理大量的快取資料，但是還是要根據系統的情況考慮維護多層的快取結構。例如除了memcached快取之外，還可以透過本地快取（如ehcache、oscache等）建立起多級快取。例如，可以採用本地快取快取一些基本資料，例如少量但訪問頻繁的資料（如產品分類，連線資訊，伺服器狀態變數，應用配置變數等），快取這些資料並讓他們儘可能的接近處理器是有意義的 , 這樣可以幫助減少生成頁面的時間，並且在 memcached 失效的情況下可以增加可靠性。

33、當資料更新時需要更新快取
使用者編輯了自己的資訊，當儲存資訊到資料庫時，需要更新快取中的資料或是簡單地刪除老的資料。如果馬上更新資料，要防止從資料庫讀取那些剛剛更新過的資料。當使用者習慣性地重新載入自己的使用者資訊來確認是否修改成功時，資料將從快取中直接取出，這時他們獲得了最新的資料。

34、模擬帶鎖的新增命令
如果你實在需要鎖，你可以透過“新增”命令模仿鎖的功能。儘管在未命中的情況下它不是那麼有用，但如果你用它快取平常的資料（應用伺服器池的後設資料）那還是有用的。
比如，你要更新鍵 A 。
1. 新增一個 "lock:A" 的鍵，這個鍵有一個持續幾秒的過期時間（足夠長以使你能完成計算和更新，也不要很長，因為如果鎖程式掛了，這個鍵不會立即釋放）
2. 如果新增操作成功了，你就擁有了鎖：從快取獲取鍵 A 的資料；利用客戶端程式更改資料；更新快取鍵 A 的資料；刪除鍵 "lock:A" 。如果你不需要立即再次更新，就讓它存活直到失效。
3. 如果新增操作失敗，說明有人獲取了鎖。這時讓應用做些合適的事，比如返回老資料，等待後重試，或是其他的。
以上這些操作類似 MySQL 將 GET_LOCK 的 timeout 值設定成 0 。沒有辦法在 memcached 中透過互斥鎖模擬 GET_LOCK() 的 timeout 操作。

35、預熱你的快取
如果你有一個很高訪問率的站點，並且你正想加入故障恢復功能或是其他全新的功能，你最終可能會碰到空快取的問題。一開始快取是空的，然後一大群人點選你的站點，在填充快取的過程中，你的資料庫可能會承受不住壓力。為了解決這一問題，你可以試試任何可行的方法來 " 溫暖 " 你的Memcached。方法：可以寫一些指令碼來快取通用的頁面；也可以寫一個命令列工具來填充快取。你可以在高峰時刻在快取裡填充一些內容。