基本問題

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,value>對的哈希表。通過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。如果系統的負載并不重，那么不需要啟用多線程工作模式。如果您在運行一個擁有大規模硬件的、龐大的網站，將體驗到看到多線程的好處。更多信息請參見：

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

簡單地總結一下：命令解析（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、什么是一致性哈希的客戶端？

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

客戶端可以通過"前綴"來給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";//需要緩存內容的key

清除命名空間：$memcache->increment("foo_namespace_key");//key增加1，利用memcached的LRU最少使用的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。方法：可以寫一些腳本來緩存通用的頁面；也可以寫一個命令行工

具來填充緩存。你可以在高峰時刻在緩存里填充一些內容。

參考網頁:

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

轉載于:https://www.cnblogs.com/sandea/p/5517873.html

總結

以上是生活随笔為你收集整理的memcached的最佳实践方案（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。