寫在前面： 前不久在工作中被問到關(guān)于MC一致哈希的問題，由于時隔太久差點兒忘記，特前來惡補一下MC，下面是前幾年在工作中學(xué)習(xí)MC時的一些資料，來歷不明，特整理一下，希望對大家的學(xué)習(xí)也能有幫助。

關(guān)于memcache的安裝，有興趣的朋友請參考這篇文章： http://blog.csdn.net/xifeijian/article/details/22000173

1、memcached 介紹

1.1 memcached 是什么？

memcached 是以LiveJournal 旗下Danga Interactive 公司的Brad Fitzpatric 為首開發(fā)的一款軟件。如今已成為mixi、hatena、Facebook、Vox、LiveJournal 等眾多服務(wù)中提高Web

應(yīng)用擴展性的重要因素。很多Web 應(yīng)用都將數(shù)據(jù)保存到RDBMS 中，應(yīng)用server從中讀取數(shù)據(jù)并在瀏覽器中顯示。但隨著數(shù)據(jù)量的增大、訪問的集中，就會出現(xiàn)RDBMS 的負(fù)擔(dān)加重、數(shù)據(jù)庫響應(yīng)惡化、站點顯示延遲等重大影響。這時就該memcached 大顯身手了。memcached 是高性能的分布式內(nèi)存緩存server。一般的使用目的是，通過緩存數(shù)據(jù)庫查詢結(jié)果，降低數(shù)據(jù)庫訪問次數(shù)，以提高動態(tài)Web 應(yīng)用的速度、提高可擴展性。

內(nèi)置內(nèi)存存儲方式

為了提高性能，memcached 中保存的數(shù)據(jù)都存儲在memcached 內(nèi)置的內(nèi)存存儲空間中。由于數(shù)據(jù)僅存在于內(nèi)存中，因此重新啟動memcached、重新啟動操作系統(tǒng)會導(dǎo)致全部數(shù)據(jù)消失。另外，內(nèi)容容量達到指定值之后，就基于LRU(Least Recently Used)算法自己主動刪除不使用的緩存。memcached 本身是為緩存而設(shè)計的server，因此并沒有過多考慮數(shù)據(jù)的永久性問題

memcached 不互相通信的分布式

memcached 盡管是 “ 分布式 ” 緩存server，但server端并沒有分布式功能。各個

memcached 不會互相通信以共享信息。那么，如何進行分布式呢？這全然取決于client的實現(xiàn)。

2.2 memcached 啟動

memcached 啟動的命令在安裝文件夾的bin 二級文件夾下，如/home/test/app/memcahced-1.4.2/bin/memcached -p 11222 -m 128 – d

經(jīng)常使用的一些啟動選項介紹選項說明

-p 偵聽的端口，默覺得11211

-m 使用內(nèi)存大小，默認(rèn)的64m

-d 作為daemon 在后臺啟動

-vv 用very vrebose 模式啟動，調(diào)試信息和錯誤輸出到控制臺

-l 偵聽的地址，默覺得全部能夠訪問的地址

-M 用于在內(nèi)存溢出的時候，返回一個錯誤，禁止自己主動的移出數(shù)

據(jù)，替代的是返回一個error

-P Pid 文件存在的路徑，僅限加上-d 參數(shù)是用

-c 最大同一時候的連接數(shù)，默覺得1024

其它的一些選項，能夠通過 – h 命令來進行查看

2.3 命令行訪問 memcached

下面假設(shè)memcached 啟動時的-p 參數(shù)為11311，命令操作在啟動memcached

本機首先telnet 連接到memcached server

telnet 127.0.0.1 11311

telnet 成功之后，大概會顯示下面的信息

Trying 127.0.0.1...

Connected to localhost.localdomain (127.0.0.1).

Escape character is '^]'.

?

各種狀態(tài)（ stats ）

STAT <name> <value>\r\n

如：stats 命令，則返回下面信息：

stats
STAT pid 26804
STAT uptime 182783
STAT time 1404973716
STAT version 1.4.13
STAT libevent 2.0.11-stable
STAT pointer_size 64
STAT rusage_user 2.320647
STAT rusage_system 5.411177
STAT curr_connections 34
STAT total_connections 558
STAT connection_structures 37
STAT reserved_fds 20
STAT cmd_get 127292
STAT cmd_set 60056
STAT cmd_flush 145
STAT cmd_touch 0
STAT get_hits 83811
STAT get_misses 43481
STAT delete_misses 15970
STAT delete_hits 11992
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT touch_hits 0
STAT touch_misses 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 14300156
STAT bytes_written 11507140
STAT limit_maxbytes 134217728 ? ??? # ?分配給memcache的內(nèi)存大小（字節(jié)）
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT hash_power_level 16
STAT hash_bytes 524288
STAT hash_is_expanding 0
STAT expired_unfetched 16884
STAT evicted_unfetched 0
STAT bytes 609350 ?? ?# 當(dāng)前server存儲items占用的字節(jié)數(shù)
STAT curr_items 4668 ??? # server當(dāng)前存儲的items數(shù)量
STAT total_items 60056
STAT evictions 0 ? ?? # 分配給memcache的空間用滿后須要刪除舊的items數(shù)，踢出。
STAT reclaimed 27160 ?#回收再利用，已過期的數(shù)據(jù)條目來存儲新數(shù)據(jù)。
END

?

存儲命令（ set ,add ,replace ）

client會發(fā)送一行像這樣的命令：

<command name> <key> <flags> <exptime> <bytes>\r\n

如：

set key1 0 600 5\r\nvalue\r\n

add key2 0 500 2\r\n

replace key1 0 600 6\r\nvalue1\r\n

具體的命令說明，能夠見附錄的memcached 中英文協(xié)議內(nèi)容

?

讀取命令（get ）

命令例如以下：get <key>*\r\n

- <key>* 表示一個或多個鍵值，由空格隔開的字串

如：

get key1

VALUE key1 0 7

value12

?

刪除命令（ delete ）

命令如：delete <key> <time>\r\n

<key> 是client希望server刪除的內(nèi)容的鍵名

- <time> 是一個單位為秒的時間（或代表直到某一刻的Unix 時間），在該時間內(nèi)server會拒絕對于此鍵名的 “ add ” 和 “ replace ” 命令。此時內(nèi)容被放入delete 隊列，無法再通過 “ get ” 得到該內(nèi)容，也無法是用 “ add ” 和 “ replace ” 命令（可是 “ set ” 命令可用）。直到指定時間，這些內(nèi)容被終于從server的內(nèi)存中徹底清除

<time> 參數(shù)是可選的，缺省為0 （表示內(nèi)容會立馬清除，并且隨后的存儲命令均可用

如：delete key1

退出命令 (quit)

如： quit

4、理解memcached 的內(nèi)存存儲

4.1Slab Allocation 機制：整理內(nèi)存以便反復(fù)使用

近期的memcached 默認(rèn)情況下採用了名為Slab Allocator 的機制分配、管理內(nèi)存。在該機制出現(xiàn)以前，內(nèi)存的分配是通過對全部記錄簡單地進行malloc和free 來進行的。可是，這樣的方式會導(dǎo)致內(nèi)存碎片，加重操作系統(tǒng)內(nèi)存管理器的負(fù)擔(dān)，最壞的情況下，會導(dǎo)致操作系統(tǒng)比memcached 進程本身還慢。 Slab Allocator 就是為解決該問題而誕生的

Slab Allocation 的原理相當(dāng)簡單。將分配的內(nèi)存切割成各種尺寸的塊

（chunk），并把尺寸同樣的塊分成組（chunk 的集合）

并且， slab allocator 還有反復(fù)使用已分配的內(nèi)存的目的。 也就是說， 分配到的內(nèi)存不會釋放，而是反復(fù)利用。

Slab Allocation 的主要術(shù)語

Page

分配給Slab 的內(nèi)存空間，默認(rèn)是1MB。 分配給Slab 之后依據(jù)slab 的大小切分成chunk 。

Chunk

用于緩存記錄的內(nèi)存空間。

Slab Class

特定大小的chunk 的組

4.2 在 Slab 中緩存記錄的原理

memcached 依據(jù)收到的數(shù)據(jù)的大小，選擇最適合數(shù)據(jù)大小的slab，memcached 中保存著slab 內(nèi)空暇chunk 的列表，依據(jù)該列表選擇chunk，然

后將數(shù)據(jù)緩存于當(dāng)中

4.3 Slab Allocator 的缺點

由于分配的是特定長度的內(nèi)存，因此無法有效利用分配的內(nèi)存。比如，將100 字節(jié)的數(shù)據(jù)緩存到128 字節(jié)的chunk 中，剩余的28字節(jié)就浪費了

對于該問題眼下還沒有完美的解決方式，但在文檔中記載了比較有效的解決方式。就是說，假設(shè)預(yù)先知道client發(fā)送的數(shù)據(jù)的公用大小，或者僅緩存大小同樣的數(shù)據(jù)的情況下，僅僅要使用適合數(shù)據(jù)大小的組的列表，就能夠降低浪費。可是非常遺憾，如今還不能進行不論什么調(diào)優(yōu)，僅僅能期待以后的版本號了。可是，我們能夠調(diào)節(jié)slab class 的大小的區(qū)別。接下來說明growth factor 選項。

?

4.4 使用 Growth Factor 進行調(diào)優(yōu)

memcached 在啟動時指定Growth Factor 因子（通過f 選項），就能夠在某種程度上控制slab 之間的差異。默認(rèn)值為1.25。 可是，在該選項出現(xiàn)之前，這個因子以前固定為2，稱為 “ powers of 2 ” 策略。

下面是啟動后的verbose 輸出：

slab class 1: chunk size 128 perslab 8192

slab class 2: chunk size 256 perslab 4096

slab class 3: chunk size 512 perslab 2048

slab class 4: chunk size 1024 perslab 1024

slab class 5: chunk size 2048 perslab 512

slab class 6: chunk size 4096 perslab 256

slab class 7: chunk size 8192 perslab 128

slab class 8: chunk size 16384 perslab 64

slab class 9: chunk size 32768 perslab 32

slab class 10: chunk size 65536 perslab 16

slab class 11: chunk size 131072 perslab 8

slab class 12: chunk size 262144 perslab 4

slab class 13: chunk size 524288 perslab 2

可見，從128 字節(jié)的組開始，組的大小依次增大為原來的2 倍。這樣設(shè)置的問題是，slab 之間的區(qū)別比較大，有些情況下就相當(dāng)浪費內(nèi)存。因此，為盡量降低內(nèi)存浪費，兩年前追加了growth factor 這個選項來看看如今的默認(rèn)設(shè)置（f=1.25）時的輸出（篇幅所限，這里僅僅寫到第10 組）：

slab class 1: chunk size 88 perslab 11915

slab class 2: chunk size 112 perslab 9362

slab class 3: chunk size 144 perslab 7281

slab class 4: chunk size 184 perslab 5698

slab class 5: chunk size 232 perslab 4519

slab class 6: chunk size 296 perslab 3542

slab class 7: chunk size 376 perslab 2788

slab class 8: chunk size 472 perslab 2221

slab class 9: chunk size 592 perslab 1771

slab class 10: chunk size 744 perslab 1409

可見，組間差距比因子為2 時小得多，更適合緩存幾百字節(jié)的記錄。從上面的輸出結(jié)果來看，可能會覺得有些計算誤差，這些誤差是為了保持字節(jié)數(shù)的對齊而有益設(shè)置的。將memcached 引入產(chǎn)品，或是直接使用默認(rèn)值進行部署時，最好是又一次計算一下數(shù)據(jù)的預(yù)期平均長度，調(diào)整growth factor，以獲得最恰當(dāng)?shù)脑O(shè)置。內(nèi)存是珍貴的資源，浪費就太可惜了。

5、memcached 刪除機制

memcached 是緩存，不須要永久的保存到server上，本章介紹memcache 的刪除機制

5.1 memcached 在數(shù)據(jù)刪除方面有效的利用資源

Memcached 不會釋放已經(jīng)分配的內(nèi)存，記錄過期之后，client無法再看到這一條記錄，其存儲空間就能夠利用。

Lazy Expiration

memcached 內(nèi)部不會監(jiān)視記錄是否過期，而是在get 時查看記錄的時間戳，檢查記錄是否過期。這樣的技術(shù)被稱為lazy（惰性）expiration。因此，memcached不會在過期監(jiān)視上耗費CPU 時間

5.2 LRU ：從緩存中有效刪除數(shù)據(jù)的原理

memcached 會優(yōu)先使用已超時的記錄的空間，但即使如此，也會發(fā)生追加新記錄時空間不足的情況，此時就要使用名為Least Recently Used（LRU）機制來分配空間。顧名思義，這是刪除 “ 近期最少使用 ” 的記錄的機制。因此，當(dāng)memcached 的內(nèi)存空間不足時（無法從slab class 獲取到新的空間時），就從近期未被使用的記錄中搜索，并將其空間分配給新的記錄。從緩存的有用角度來看，該模型十分理想。只是，有些情況下LRU 機制反倒會造成麻煩。memcached 啟動時通過 “ M ” 參數(shù)能夠禁止LRU，例如以下所看到的：

$ memcached -M – m 1024

啟動時必須注意的是，小寫的 “ m ” 選項是用來指定最大內(nèi)存大小的。不指定具體數(shù)值則使用默認(rèn)值64MB。

指定 “ M ” 參數(shù)啟動后，內(nèi)存用盡時memcached 會返回錯誤。話說回來，memcached 畢竟不是存儲器，而是緩存，所以推薦使用LRU

6、memcached 的分布式算法

6.1memcached 的分布式

memcached 盡管稱為 “ 分布式 ” 緩存server，但server端并沒有 “ 分布式 ” 功能。memcached 的分布式，則是全然由client程序庫實現(xiàn)的。這樣的分布式是memcached 的最大特點

memcached 的分布式是什么意思？

下面假設(shè)memcached server有node1～node3 三臺，應(yīng)用程序要保存鍵名為 “ tokyo ” 、 “ kanagawa ” 、 “ chiba ” 、 “ saitama ” 、 “ gunma ” 的數(shù)據(jù)

首先向memcached 中加入 “ tokyo ” 。將 “ tokyo ” 傳給client程序庫后，client實現(xiàn)的算法就會依據(jù) “ 鍵 ” 來決定保存數(shù)據(jù)的memcached server。server選定后，即命令它保存 “ tokyo ” 及其值

同樣， “ kanagawa ” 、 “ chiba ” 、 “ saitama ” 、 “ gunma ” 都是先選擇server再保接下來獲取保存的數(shù)據(jù)。獲取時也要將要獲取的鍵 “ tokyo ” 傳遞給函數(shù)庫。函數(shù)庫通過與數(shù)據(jù)保存時同樣的算法，依據(jù) “ 鍵 ” 選擇server。使用的算法同樣，就能選中與保存時同樣的server，然后發(fā)送get 命令。僅僅要數(shù)據(jù)沒有由于某些原因被刪除，就能獲得保存的值。

這樣，將不同的鍵保存到不同的server上，就實現(xiàn)了memcached 的分布式。memcached server增多后，鍵就會分散，即使一臺memcached server發(fā)生問題無法連接，也不會影響其它的緩存，系統(tǒng)依舊能繼續(xù)執(zhí)行

6.2 余數(shù)分布式算法

就是 “ 依據(jù)server臺數(shù)的余數(shù)進行分散 ” 。求得鍵的整數(shù)哈希值，再除以server臺數(shù)，依據(jù)其余數(shù)來選擇server

余數(shù)算法的缺點

余數(shù)計算的方法簡單，數(shù)據(jù)的分散性也相當(dāng)優(yōu)秀，但也有其缺點。那就是當(dāng)加入或移除server時，緩存重組的代價相當(dāng)巨大。加入server后，余數(shù)就會產(chǎn)生巨變，這樣就無法獲取與保存時同樣的server，從而影響緩存的命中。

6.3Consistent Hashing（一致哈希）

知識補充：哈希算法，即散列函數(shù)。將隨意長度的二進制值映射為較短的固定長度的二進制值，這個小的二進制值稱為哈希值。哈希值是一段數(shù)據(jù)唯一且極其緊湊的數(shù)值表示形式。假設(shè)散列一段明文并且哪怕僅僅更改該段落的一個字母，隨后的哈希都將產(chǎn)生不同的值。要找到散列為同一個值的兩個不同的輸入，在計算上是不可能的，所以數(shù)據(jù)的哈希值能夠檢驗數(shù)據(jù)的完整性。一般用于高速查找和加密算法。（常見的有MD5，SHA-1）

Consistent Hashing 的簡單說明

Consistent Hashing 例如以下所看到的：首先求出memcached server（節(jié)點）的哈希值（一般的方法能夠使用 cache 機器的 IP 地址或者機器名作為 hash 輸入。），并將其配置到0～ 2 ³² 的圓（continuum）上。然后用同樣的方法求出存儲數(shù)據(jù)的 鍵 的哈希值，并映射到圓上。然后從數(shù)據(jù)映射到的位置開始順時針查找，將數(shù)據(jù)保存到找到的第一個server上。假設(shè)超過 2 ³² 仍然找不到server，就會保存到第一臺memcached server上。

從上圖的狀態(tài)中加入一臺memcached server。余數(shù)分布式算法由于保存鍵的server會發(fā)生巨大變化，而影響緩存的命中率，但Consistent Hashing中，僅僅有在continuum 上添加server的地點逆時針方向的第一臺server上的鍵會受到影響

?Consistent hashing 的基本思想就是將對象和 cache 都映射到同一個 hash 數(shù)值空間中，并且使用同樣的 hash 算法。

如今 cache 和對象都已經(jīng)通過同一個 hash 算法映射到 hash 數(shù)值空間中了，接下來要考慮的就是如何將對象映射到 cache 上面了。

在這個環(huán)形空間中，假設(shè)沿著順時針方向從對象的 key 值出發(fā)，直到遇見一個 cache ，那么就將該對象存儲在這個 cache 上，由于對象和 cache 的 hash 值是固定的，因此這個 cache 必定是唯一和確定的。這樣不就找到了對象和 cache 的映射方法了嗎？

Consistent Hashing ：加入server

因此，Consistent Hashing 最大限度地抑制了鍵的又一次分布。并且，有的Consistent Hashing 的實現(xiàn)方法還採用了虛擬節(jié)點的思想。使用一般的hash函數(shù)的話，server的映射地點的分布非常不均勻。因此，使用虛擬節(jié)點的思想，為每一個物理節(jié)點（server）在continuum上分配100～200 個點。這樣就能抑制分布不均勻，最大限度地減小server增減時的緩存又一次分布。

通過上文中介紹的使用Consistent Hashing 算法的memcached client函數(shù)庫進行測試的結(jié)果是，由server臺數(shù)（n）和添加的server臺數(shù)（m）計算添加server后的命中率計算公式例如以下：

(1 n/(n+m)) * 100

存儲命令

<command name> <key> <flags> <exptime> <bytes>\r\n

- <command name> 是set, add, 或者repalce

- <key> 是接下來的client所要求儲存的數(shù)據(jù)的鍵值

- <flags> 是在取回內(nèi)容時，與數(shù)據(jù)和發(fā)送塊一同保存server上的隨意16 位無符號整形（用十進制來書寫）。client能夠用它作為 “ 位域 ” 來存儲一些特定的信息；它對server是不透明的。

- <exptime> 是終止時間。假設(shè)為0 ，該項永只是期(盡管它可能被刪除，以便為其它緩存項目騰出位置)。假設(shè)非0（Unix 時間戳或當(dāng)前時刻的秒偏移），到達終止時間后，client無法再獲得這項內(nèi)容。

- <bytes> 是隨后的數(shù)據(jù)區(qū)塊的字節(jié)長度，不包含用于分野的 “ \r\n ” 。它能夠是0 （這時后面尾隨一個空的數(shù)據(jù)區(qū)塊）。

- <data block> 是大段的8 位數(shù)據(jù)，其長度由前面的命令行中的<bytes>指定。

?

? set 意思是 “ 儲存此數(shù)據(jù) ”

? add 意思是 “ 儲存此數(shù)據(jù)，僅僅在server* 未*保留此鍵值的數(shù)據(jù)時 ”

? replace 意思是 “ 儲存此數(shù)據(jù)，僅僅在server* 曾*保留此鍵值的數(shù)據(jù)時 ”

?

發(fā)送命令行和數(shù)據(jù)區(qū)塊以后，client等待回復(fù)，可能的回復(fù)例如以下：

- "STORED\r\n" 表明成功.

- "NOT_STORED\r\n" 表明數(shù)據(jù)沒有被存儲，但不是由于錯誤發(fā)生。這通常意味著add 或replace 命令的條件不成立，或者，項目已經(jīng)位列刪除隊列（參考后文的 “ delete ” 命令）。

?

取回命令

get <key>*\r\n

- <key>* 表示一個或多個鍵值，由空格隔開的字串這行命令以后，client的等待0 個或多個項目，每項都會收到一行文本，然后跟著數(shù)據(jù)區(qū)塊。全部項目傳送完成后，server發(fā)送下面字串："END\r\n"來指示回應(yīng)完成,server用下面形式發(fā)送每項內(nèi)容：

VALUE <key> <flags> <bytes>\r\n

<data block>\r\n

- <key> 是所發(fā)送的鍵名

- <flags> 是存儲命令所設(shè)置的記號

- <bytes> 是隨后數(shù)據(jù)塊的長度，* 不包含* 它的界定符 “ \r\n ”

- <data block> 是發(fā)送的數(shù)據(jù)

假設(shè)在取回請求中發(fā)送了一些鍵名，而server沒有送回項目列表，這意味著server沒這些鍵名（可能由于它們從未被存儲，或者為給其它內(nèi)容騰出空間而被刪除，或者到期，或者被已client刪除）。

?

刪除

delete <key> <time>\r\n

- <key> 是client希望server刪除的內(nèi)容的鍵名

- <time> 是一個單位為秒的時間（或代表直到某一刻的Unix 時間），在該時間內(nèi)server會拒絕對于此鍵名的 “ add ” 和 “ replace ” 命令。此時內(nèi)容被放入delete 隊列，無法再通過 “ get ” 得到該內(nèi)容，也無法是用 “ add ” 和 “ replace ” 命令（可是 “ set ” 命令可用）。直到指定時間，這些內(nèi)容被終于從server的內(nèi)存中徹底清除。<time> 參數(shù)是可選的，缺省為0（表示內(nèi)容會立馬清除，并且隨后的存儲命令均可用）。

此命令有一行回應(yīng)：- "DELETED\r\n" 表示執(zhí)行成功

- "NOT_FOUND\r\n" 表示沒有找到這項內(nèi)容

?

添加/ 降低

命令 “ incr ” 和 “ decr ” 被用來改動數(shù)據(jù)，當(dāng)一些內(nèi)容須要替換、添加或降低時。這些數(shù)據(jù)必須是十進制的32 位無符號整新。假設(shè)不是，則當(dāng)作0 來處理。改動的內(nèi)容必須存在，當(dāng)使用 “ incr ” / “ decr ” 命令改動不存在的內(nèi)容時，不會被當(dāng)作0 處理，而是操作失敗。

client發(fā)送命令行：

incr <key> <value>\r\n 或decr <key> <value>\r\n

- <key> 是client希望改動的內(nèi)容的建名

- <value> 是client要添加/ 降低的總數(shù)。

回復(fù)為下面集中情形：

- "NOT_FOUND\r\n" 指示該項內(nèi)容的值，不存在。

- <value>\r\n ，<value> 是添加/降低。

注意"decr" 命令發(fā)生下溢：假設(shè)client嘗試降低的結(jié)果小于0 時，結(jié)果會是0。"incr" 命令不會發(fā)生溢出。

?

狀態(tài)

命令"stats" 被用于查詢server的執(zhí)行狀態(tài)和其它內(nèi)部數(shù)據(jù)。有兩種格式。不帶參數(shù)的：

stats\r\n

這會在隨后輸出各項狀態(tài)、設(shè)定值和文檔。還有一種格式帶有一些參數(shù)：

stats <args>\r\n

通過<args> ，server傳回各種內(nèi)部數(shù)據(jù)。由于隨時可能發(fā)生變動，本文不提供參數(shù)的種類及其傳回數(shù)據(jù)。

?

各種狀態(tài)

受到無參數(shù)的"stats" 命令后，server發(fā)送多行內(nèi)容，例如以下：

STAT <name> <value>\r\n

server用下面一行來終止這個清單：END\r\n，在每行狀態(tài)中，<name> 是狀態(tài)的名字，<value>使?fàn)顟B(tài)的數(shù)據(jù)。下面清單，是全部的狀態(tài)名稱，數(shù)據(jù)類型，和數(shù)據(jù)代表的含義。

在 “ 類型 ” 一列中，"32u"表示32 位無符號整型，"64u"表示64 位無符號整型，"32u:32u"表示用冒號隔開的兩個32 位無符號整型。

?

名稱	類型	含義
pid	32u	server進程ID
uptime	32u	server執(zhí)行時間，單位秒
time	32u	server當(dāng)前的UNIX時間
version	string	server的版本號號
rusage_user	32u	該進程累計的用戶時間(秒:微妙)
rusage_system	32u	該進程累計的系統(tǒng)時間(秒:微妙)
curr_items	32u	server當(dāng)前存儲的內(nèi)容數(shù)量
total_items	32u	server啟動以來存儲過的內(nèi)容總數(shù)
bytes	64u	server當(dāng)前存儲內(nèi)容所占用的字節(jié)數(shù)
curr_connections	32u	連接數(shù)
total_connections	32u	server執(zhí)行以來接受的連接總數(shù)
connection_structures	32u	server分配的連接結(jié)構(gòu)的數(shù)量
cmd_get	32u	取回請求總數(shù)
cmd_set	32u	存儲請求總數(shù)
get_hits	32u	請求成功的總次數(shù)
get_misses	32u	請求失敗的總次數(shù)
bytes_read	64u	server從網(wǎng)絡(luò)讀取到的總字節(jié)數(shù)
bytes_written	64u	server向網(wǎng)絡(luò)發(fā)送的總字節(jié)數(shù)
limit_maxbytes	32u	server在存儲時被同意使用的字節(jié)總數(shù)

?

?假設(shè)不想每次通過輸入stats來查看memcache狀態(tài)，能夠通過echo "stats" |nc ?ip port 來查看，比如：echo "stats" | nc 127.0.0.1 9023。