Memcached FAQ

時間 2019-11-14

原文原文鏈接

這篇FAQ包含了你們廣泛關心的問題。很是值得一看。php

原文：http://blog.csdn.net/jarfield/archive/2009/07/05/4322953.aspxhtml

最後更新時間 2009-04-10 更新人 dormando@rydia.net
這裏收集了常常被問到的關於memcached的問題java

通常的問題

通常的問題

什麼是memcached？
memcached是一個高性能的、分佈式的、內存對象緩存系統。memcached本質上是一個通用的緩存系統，可是它一般被用來減少數據庫的負載，以達到加速dynamic web應用的目的。mysql

Dange Interactive （開發memcached的組織機構，譯者注）開發memcached的目的是，加快LiveJournal.com 的速度。LiveJournal.com 這個網站擁有大量的web server和database server，天天訪問的用戶數高達1百萬，天天的動態網頁PV高達2千萬+。有了memcached，數據庫就跟沒事同樣，其負載被大大減少。Memcached加快了動態網頁的響應時間，提升了資源利用率，加快了memcached不命中時數據庫的訪問速度。

從哪得到memcached？
到這個下載頁面下載吧！

怎麼安裝memcached？
能夠參考安裝指南，也可使用操做系統的軟件包管理系統來自動下載安裝（apt, yum等）。
若是您的linux發行版沒有memcached，或者有了memcached但版本不夠新，您還能夠從源代碼安裝。從咱們的下載頁面得到源代碼的tar包，而後在shell中執行如下命令：
$ tar -zxvf memcached-1.x.x.tar.gz
$ ./configure --enable-threads (若是您想使用多線程工做方式)
$ make
$ make test
$ sudo make install
您可使用'./configure --help' 能夠查看全部的選項。

哪些平臺能夠運行memcached？
任何有空閒內存的地方均可以！Memcached能夠運行在linux、BSD、windows。它只須要不多的CPU時間，因此不管哪裏有空閒內存，哪裏就能夠運行它。

什麼狀況下適合使用memcached？
若是您的網站包含了訪問量很大的動態網頁，於是數據庫負載很高，並且大部分數據庫請求都是讀操做，那麼memcached能夠幫您顯著地減少數據庫負載。linux

Memcached一樣適用在其餘不少場合。至於到底適用哪些場合，您能夠通讀Memcached FAQ和相關的指南來得到一些靈感。若是您的數據庫負載比較低但CPU使用率很高，您能夠緩存計算好的結果（ computed objects ）和渲染後的模板（enderred templates）。經過memcached，您能夠緩存session數據、臨時數據以減小對他們的數據庫寫操做，緩存一些很小可是被頻繁訪問的文件，緩存Web 'services'（非IBM宣揚的Web Services，譯者注）或RSS feeds的結果...

即便您的資源（CPU、內存、數據庫等，譯者注）很充足，memcached至少也能夠幫您加快頁面的渲染速度。

什麼狀況下不適合適用memcached？
參見這裏。（下面也翻譯這個頁面）

Memcached的確很棒！但也不是每種場合都適用...web

對象的大小大於1MB
- Memcached自己就不是爲了處理龐大的多媒體（large media）和巨大的二進制塊（streaming huge blobs）。
- 考慮其餘的條件：http://www.danga.com/mogilefs

key的長度大於250字符
- 若是真的用了這麼長的key，那麼您什麼地方可能作錯了。
- 還有，能夠看看關於key長度的郵件列表。

您的虛擬主機不讓您運行memcached
- 若是您的應用託管在低端的虛擬私有服務器（virtual private server, a slice of a machine)上，像vmware, xen這類虛擬化技術並不適合運行memcached。Memcached確實須要接管和控制大塊的內存--若是memcached的內存被OS或 hypervisor交換出去，memcached的性能將大打折扣。

您的應用運行在不安全的環境中
- 記住，任何人僅僅經過telnet就能夠訪問到您的memcached。若是您的應用運行在共享的系統上，要盯緊哦！
您須要持久化數據，或者說您須要的應該是database
- 若是您僅僅期待memcached提供SQL接口，那麼您可能須要從新思考一下對cache和memcached的理解。若是想對這個問題有更多的瞭解，慶參考下面dormando寫的blog。
links
- 2008/08
  - Memcached versus more rdbms sharding at highscalability.com
  - Should you use memcached? Should you just shard mysql more? by dormando

怎麼訪問memcached？算法

通常來講，您的應用可使用memcached的客戶端庫來訪問一個或多個memcached。sql

這個客戶端頁面上列出了全部可用的API庫，包括Perl, C, C#, PHP, Python, Java, Ruby, PostgreSQL的存儲過程及觸發器。shell

您能夠根據memcached協議編寫本身的客戶端庫。數據庫

怎麼把memcached當成database使用？

若是您想把memcached用做數據存儲媒介而不是緩存，那麼您應該使用database。MySQL Cluster擁有一些與memcached相似的特性（儘管MySQL Cluster安裝並不容易），並且MySQL Cluster徹底能夠勝任一個可靠的分佈存儲媒介。

可以遍歷memcached中全部的item嗎？

不！Memcached不支持也不計劃支持這個操做。這個操做的速度相對緩慢且阻塞其餘的操做（這裏的緩慢時相比memcached其餘的命令）。如前面所說，memcached是一個緩存，不是數據庫。Tugela 和 memcachedb 是memcached派生出的系統，它們速度比較慢，可是行爲更有點像數據庫。

固然，memcached畢竟是軟件，因此從某種角度說，答案最終確定是YES。可是這個操做確實慢並且阻塞memcached。對於開發和測試服務器來講，這不是問題，可是對於99.9%的真正部署來講，答案是NO。

咱們前面提到的「阻塞memcached」到底是什麼意思呢？memcached全部非調試（non-debug）命令，例如add, set, get, fulsh這些命令，不管memcached中存儲了多少數據，它們的執行都只消耗常量時間。任何遍歷全部item的命令執行所消耗的時間，將隨着memcached中數據量的增長而增長。當其餘命令由於等待（遍歷全部item的命令執行完畢）而不能獲得執行，阻塞就發生了。

也許您能夠說，「刪除我全部的key」這個命令平均只花費半秒鐘，我有足夠的CPU空閒時間，我隔幾秒鐘才執行一次這個命令，那麼還有什麼問題嗎（還不能遍歷全部的item嗎）？（固然有問題）由於這半秒鐘，其餘的請求都至少延遲半秒鐘。It'll take as long as it takes the hardware to process through that queue in order to catch up. So all of your other requests end up taking too long.

因此咱們努力不作這樣的事情。若是您確實須要遍歷全部的item，考慮使用MySQL吧，使用主鍵訪問數據，您還可使用一個輔助索引加快搜索速度。

最後更新時間 2009-04-10 更新人 dormando@rydia.net
這裏收集了常常被問到的關於memcached的問題

集羣架構方面的問題

集羣架構方面的問題

memcached是怎麼工做的？

Memcached的神奇來自兩階段哈希（two-stage hash）。Memcached就像一個巨大的、存儲了不少<key,value>對的哈希表。經過key，能夠存儲或查詢任意的數據。

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

舉個列子，假設有3個客戶端1, 2, 3，3臺memcached A, B, C：
Client 1想把數據"barbaz"以key "foo"存儲。Client 1首先參考節點列表（A, B, C），計算key "foo"的哈希值，假設memcached B被選中。接着，Client 1直接connect到memcached B，經過key "foo"把數據"barbaz"存儲進去。Client 2使用與Client 1相同的客戶端庫（意味着階段一的哈希算法相同），也擁有一樣的memcached列表（A, B, C）。
因而，通過相同的哈希計算（階段一），Client 2計算出key "foo"在memcached B上，而後它直接請求memcached B，獲得數據"barbaz"。
各類客戶端在memcached中數據的存儲形式是不一樣的（perl Storable, php serialize, java hibernate, JSON等）。一些客戶端實現的哈希算法也不同。可是，memcached服務器端的行爲老是一致的。

最後，從實現的角度看，memcached是一個非阻塞的、基於事件的服務器程序。這種架構能夠很好地解決C10K problem ，並具備極佳的可擴展性。

能夠參考A Story of Caching ，這篇文章簡單解釋了客戶端與memcached是如何交互的。

memcached最大的優點是什麼？

請仔細閱讀上面的問題（即memcached是如何工做的）。Memcached最大的好處就是它帶來了極佳的水平可擴展性，特別是在一個巨大的系統中。因爲客戶端本身作了一次哈希，那麼咱們很容易增長大量memcached到集羣中。memcached之間沒有相互通訊，所以不會增長 memcached的負載；沒有多播協議，不會網絡通訊量爆炸（implode）。memcached的集羣很好用。內存不夠了？增長几臺 memcached吧；CPU不夠用了？再增長几臺吧；有多餘的內存？在增長几臺吧，不要浪費了。

基於memcached的基本原則，能夠至關輕鬆地構建出不一樣類型的緩存架構。除了這篇FAQ，在其餘地方很容易找到詳細資料的。

看看下面的幾個問題吧，它們在memcached、服務器的local cache和MySQL的query cache之間作了比較。這幾個問題會讓您有更全面的認識。

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

把memcached引入應用中，仍是須要很多工做量的。MySQL有個使用方便的query cache，能夠自動地緩存SQL查詢的結果，被緩存的SQL查詢能夠被反覆地快速執行。Memcached與之相比，怎麼樣呢？MySQL的query cache是集中式的，鏈接到該query cache的MySQL服務器都會受益。

當您修改表時，MySQL的query cache會馬上被刷新（flush）。存儲一個memcached item只須要不多的時間，可是當寫操做很頻繁時，MySQL的query cache會常常讓全部緩存數據都失效。

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

在MySQL的query cache中，咱們是不能存儲任意的數據的（只能是SQL查詢結果）。而利用memcached，咱們能夠搭建出各類高效的緩存。好比，能夠執行多個獨立的查詢，構建出一個用戶對象（user object），而後將用戶對象緩存到memcached中。而query cache是SQL語句級別的，不可能作到這一點。在小的網站中，query cache會有所幫助，但隨着網站規模的增長，query cache的弊將大於利。

query cache可以利用的內存容量受到MySQL服務器空閒內存空間的限制。給數據庫服務器增長更多的內存來緩存數據，當然是很好的。可是，有了memcached，只要您有空閒的內存，均可以用來增長memcached集羣的規模，而後您就能夠緩存更多的數據。

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

首先，local cache有許多與上面(query cache)相同的問題。local cache可以利用的內存容量受到（單臺）服務器空閒內存空間的限制。不過，local cache有一點比memcached和query cache都要好，那就是它不但能夠存儲任意的數據，並且沒有網絡存取的延遲。

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

local cache缺乏集體失效（group invalidation）的特性。在memcached集羣中，刪除或更新一個key會讓全部的觀察者覺察到。可是在local cache中, 咱們只能通知全部的服務器刷新cache（很慢，不具擴展性），或者僅僅依賴緩存超時失效機制。

local cache面臨着嚴重的內存限制，這一點上面已經提到。

memcached的cache機制是怎樣的？

Memcached主要的cache機制是LRU（最近最少用）算法+超時失效。當您存數據到memcached中，能夠指定該數據在緩存中能夠呆多久Which is forever, or some time in the future。若是memcached的內存不夠用了，過時的slabs會優先被替換，接着就輪到最老的未被使用的slabs。

memcached如何實現冗餘機制？
不實現！咱們對這個問題感到很驚訝。Memcached應該是應用的緩存層。它的設計自己就不帶有任何冗餘機制。若是一個memcached節點失去了全部數據，您應該能夠從數據源（好比數據庫）再次獲取到數據。您應該特別注意，您的應用應該能夠容忍節點的失效。不要寫一些糟糕的查詢代碼，寄但願於memcached來保證一切！若是您擔憂節點失效會大大加劇數據庫的負擔，那麼您能夠採起一些辦法。好比您能夠增長更多的節點（來減小丟失一個節點的影響），熱備節點（在其餘節點down了的時候接管IP），等等。

memcached如何處理容錯的？
不處理！:) 在memcached節點失效的狀況下，集羣沒有必要作任何容錯處理。若是發生了節點失效，應對的措施徹底取決於用戶。節點失效時，下面列出幾種方案供您選擇：

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

把失效的節點從節點列表中移除。作這個操做千萬要當心！在默認狀況下（餘數式哈希算法），客戶端添加或移除節點，會致使全部的緩存數據不可用！由於哈希參照的節點列表變化了，大部分key會由於哈希值的改變而被映射到（與原來）不一樣的節點上。

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

若是但願添加和移除節點，而不影響原先的哈希結果，可使用一致性哈希算法（consistent hashing）。您能夠百度一下一致性哈希算法。支持一致性哈希的客戶端已經很成熟，並且被普遍使用。去嘗試一下吧！

兩次哈希（reshing）。當客戶端存取數據時，若是發現一個節點down了，就再作一次哈希（哈希算法與前一次不一樣），從新選擇另外一個節點（須要注意的時，客戶端並無把down的節點從節點列表中移除，下次仍是有可能先哈希到它）。若是某個節點時好時壞，兩次哈希的方法就有風險了，好的節點和壞的節點上均可能存在髒數據（stale data）。

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

您不該該這樣作！Memcached是一個非阻塞的服務器。任何可能致使memcached暫停或瞬時拒絕服務的操做都應該值得深思熟慮。向memcached中批量導入數據每每不是您真正想要的！想象看，若是緩存數據在導出導入之間發生了變化，您就須要處理髒數據了；若是緩存數據在導出導入之間過時了，您又怎麼處理這些數據呢？

所以，批量導出導入數據並不像您想象中的那麼有用。不過在一個場景卻是頗有用。若是您有大量的從不變化的數據，而且但願緩存很快熱（warm）起來，批量導入緩存數據是頗有幫助的。雖然這個場景並不典型，但卻常常發生，所以咱們會考慮在未來實現批量導出導入的功能。

Steven Grimm，一如既往地,，在郵件列表中給出了另外一個很好的例子：http://lists.danga.com/pipermail/memcached/2007-July/004802.html 。

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

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

若是一個memcached節點down了讓您很痛苦，那麼您還會陷入其餘不少麻煩。您的系統太脆弱了。您須要作一些優化工做。好比處理"驚羣"問題（好比 memcached節點都失效了，反覆的查詢讓您的數據庫不堪重負...這個問題在FAQ的其餘提到過），或者優化很差的查詢。記住，Memcached 並非您逃避優化查詢的藉口。

若是您的麻煩僅僅是從新生成緩存數據須要消耗很長時間（15秒到超過5分鐘），您能夠考慮從新使用數據庫。這裏給出一些提示：

使用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，等等。

上面的方法均可以引入memcached，在重啓memcached的時候仍然提供很好的性能。因爲您不須要小心"hot"的item被 memcached LRU算法忽然淘汰，用戶不再用花幾分鐘來等待從新生成緩存數據（當緩存數據忽然從內存中消失時），所以上面的方法能夠全面提升性能。

關於這些方法的細節，詳見博客：http://dormando.livejournal.com/495593.html 。

memcached是如何作身份驗證的？
沒有身份認證機制！memcached是運行在應用下層的軟件（身份驗證應該是應用上層的職責）。memcached的客戶端和服務器端之因此是輕量級的，部分緣由就是徹底沒有實現身份驗證機制。這樣，memcached能夠很快地建立新鏈接，服務器端也無需任何配置。

若是您但願限制訪問，您可使用防火牆，或者讓memcached監聽unix domain socket。

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在負載極高的場景下的性能。

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

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

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

爲何單個item的大小被限制在1M byte以內？
啊...這是一個你們常常問的問題！

簡單的回答：由於內存分配器的算法就是這樣的。

詳細的回答：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中存取很大的數據...不要嘗試把巨大的網頁放到mencached中。把這樣大的數據結構load和unpack到內存中須要花費很長的時間，從而致使您的網站性能反而很差。

若是您確實須要存儲大於1MB的數據，你能夠修改slabs.c:POWER_BLOCK的值，而後從新編譯memcached；或者使用低效的malloc/free。其餘的建議包括數據庫、MogileFS等。

我能夠在不一樣的memcached節點上使用大小不等的緩存空間嗎？這麼作以後，memcached可以更有效地使用內存嗎？
Memcache客戶端僅根據哈希算法來決定將某個key存儲在哪一個節點上，而不考慮節點的內存大小。所以，您能夠在不一樣的節點上使用大小不等的緩存。可是通常都是這樣作的：擁有較多內存的節點上能夠運行多個memcached實例，每一個實例使用的內存跟其餘節點上的實例相同。

什麼是二進制協議，我該關注嗎？
關於二進制最好的信息固然是二進制協議規範：http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol 。

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

在這個郵件列表的thread中能夠找到一些舊的信息：http://lists.danga.com/pipermail/memcached/2007-July/004636.html 。

memcached的內存分配器是如何工做的？爲何不適用malloc/free！？爲什麼要使用slabs？
實際上，這是一個編譯時選項。默認會使用內部的slab分配器。您確實確實應該使用內建的slab分配器。最先的時候，memcached只使用malloc/free來管理內存。然而，這種方式不能與OS的內存管理之前很好地工做。反覆地malloc/free形成了內存碎片，OS最終花費大量的時間去查找連續的內存塊來知足malloc的請求，而不是運行memcached進程。若是您不一樣意，固然可使用malloc！只是不要在郵件列表中抱怨啊:)

slab分配器就是爲了解決這個問題而生的。內存被分配並劃分紅chunks，一直被重複使用。由於內存被劃分紅大小不等的slabs，若是item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。Steven Grimm正在這方面已經作出了有效的改進。

郵件列表中有一些關於slab的改進（power of n 仍是 power of 2）和權衡方案：http://lists.danga.com/pipermail/memcached/2006-May/002163.html http://lists.danga.com/pipermail/memcached/2007-March/003753.html 。

若是您想使用malloc/free，看看它們工做地怎麼樣，您能夠在構建過程當中定義USE_SYSTEM_MALLOC。這個特性沒有通過很好的測試，因此太不可能獲得開發者的支持。

memcached是原子的嗎？
固然！好吧，讓咱們來明確一下：
全部的被髮送到memcached的單個命令是徹底原子的。若是您針對同一份數據同時發送了一個set命令和一個get命令，它們不會影響對方。它們將被串行化、前後執行。即便在多線程模式，全部的命令都是原子的，除非程序有bug:)
命令序列不是原子的。若是您經過get命令獲取了一個item，修改了它，而後想把它set回memcached，咱們不保證這個item沒有被其餘進程（process，未必是操做系統中的進程）操做過。在併發的狀況下，您也可能覆寫了一個被其餘進程set的item。

memcached 1.2.5以及更高版本，提供了gets和cas命令，它們能夠解決上面的問題。若是您使用gets命令查詢某個key的item，memcached會給您返回該item當前值的惟一標識。若是您覆寫了這個item並想把它寫回到memcached中，您能夠經過cas命令把那個惟一標識一塊兒發送給memcached。若是該item存放在memcached中的惟一標識與您提供的一致，您的寫操做將會成功。若是另外一個進程在這期間也修改了這個item，那麼該item存放在memcached中的惟一標識將會改變，您的寫操做就會失敗。

一般，基於memcached中item的值來修改item，是一件棘手的事情。除非您很清楚本身在作什麼，不然請不要作這樣的事情。

Memcached FAQ(3) 性能和客戶端庫方面的問題收藏

最後更新時間 2009-04-10 更新人 dormando@rydia.net
這裏收集了常常被問到的關於memcached的問題

性能方面的問題
- memcached沒有個人database快，爲何？
客戶端庫方面的問題
- memcached有哪些客戶端庫？
- 使用不一樣的客戶端庫，可以訪問到memcached中相同的數據嗎？（不一樣客戶端庫的能夠協做嗎？）
- 什麼是一致性哈希的客戶端？
客戶端FAQ

性能方面的問題

Memcached沒有個人數據庫快，爲何？
在一對一比較中，memcached可能沒有您的SQL查詢快。可是，這不是memcached的設計目標。Memcached的目標是可伸縮性。當鏈接和請求增長的時候，memcached的性能將比大多數數據庫好。您能夠先在高負載的環境（併發的鏈接和請求）中測試您的代碼，而後再決定memcached是否適合您。

客戶端庫

memcached有哪些客戶端庫？
看看上面的"如何訪問memcached"小節。

使用不一樣的客戶端庫，能夠訪問到memcached中相同的數據嗎？
從技術上說，是能夠的。可是您可能會遇到下面三個問題：

不一樣的庫採用不一樣的方式序列化數據。舉個例子，perl的Cache::Memcached使用Storable來序列化結構複雜的數據（好比hash references, objects, 等）。其餘語言的客戶端庫極可能不能讀取這種格式的數據。若是您要存儲複雜的數據而且想被多種客戶端庫讀取，那麼您應該以簡單的string格式來存儲，而且這種格式能夠被JSON、XML等外部庫解析。

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

各個客戶端庫可能使用不一樣的哈希算法（階段一哈希）。在鏈接到多個memcached服務器端的狀況下，客戶端庫根據自身實現的哈希算法把key映射到某臺memcached上。正是由於不一樣的客戶端庫使用不一樣的哈希算法，因此被Perl客戶端庫映射到memcached A的key，可能又會被Python客戶端庫映射到memcached B，等等。Perl客戶端庫還容許爲每臺memcached指定不一樣的權重（weight），這也是致使這個問題的一個因素。

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

一致性哈希算法是a new approach to managing the first-layer hashing system for memcached clients。這裏有一篇文章很好地解釋了它的用處：http://www.last.fm/user/RJ/journal/2007/04/10/392555 。

客戶端FAQ

目前有一些記錄：
客戶端能夠經過"前綴"來給key設置一個域（命名空間）。例如，在一個共享主機的環境中，您能夠將客戶姓名做爲"前綴"，爲key建立一個特定的域。在存儲數據的時候，"前綴"能夠用在key上，可是不該該參與哈希計算。目前，memcached本身尚未實現針對複雜結構數據的序列化方法，JSON則是一種被普遍使用的對象序列化格式。

最後更新時間 2009-04-10 更新人 dormando@rydia.net
這裏收集了常常被問到的關於memcached的問題