Memcached

一、memcached能接受的key的最大長度是多少？ (250字符)
key的最大長度是250個字符。須要注意的是，250是memcached服務器端內部的限制，若是您使用的客戶端支持"key的前綴"或相似特性，那麼key（前綴+原始key）的最大長度是能夠超過250個字符的。咱們推薦使用使用較短的key，由於能夠節省內存和帶寬。 （咱們對key+value的總長度控制在64kb，沒有對key單獨作限制）
 
二、memcached對item的過時時間有什麼限制？ （最大過時時間30天）
過時時間最大能夠達到30天。memcached把傳入的過時時間（時間段）解釋成時間點後，一旦到了這個時間點，memcached就把item置爲失效狀態。這是一個簡單但obscure的機制。(咱們不限制，到2038年)
 
三、memcached最大能存儲多大的單個item？  (1MB)
1MB。若是你的數據大於1MB，能夠考慮在客戶端壓縮或拆分到多個key中。
      （咱們對key+value的總長度控制在64kb，沒有對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實例，每一個實例使用的內存跟其餘節點上的實例相同。
 
六、memcached的內存分配器是如何工做的？爲何不適用malloc/free！？爲什麼要使用slabs？
實際上，這是一個編譯時選項。默認會使用內部的slab分配器。您確實確實應該使用內建的slab分配器。最先的時候，memcached只使用malloc/free來管理內存。然而，這種方式不能與OS的內存管理之前很好地工做。反覆地malloc/free形成了內存碎片，OS最終花費大量的時間去查找連續的內存塊來知足malloc的請求，而不是運行memcached進程。若是您不一樣意，固然可使用malloc！只是不要在郵件列表中抱怨啊:)
       slab分配器就是爲了解決這個問題而生的。內存被分配並劃分紅chunks，一直被重複使用。由於內存被劃分紅大小不等的slabs，若是item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。Steven Grimm正在這方面已經作出了有效的改進。

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

1三、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實例，這種方式可以更有效地處理multigets。若是系統的負載並不重，那麼不須要啓用多線程工做模式。