Memcache[01]–通訊協定

1 -- 協議

memcached的用戶端通過TCP串連與伺服器通訊（UDP協議的介面也可以使用，詳細說明請參考”UDP 協議”部分）。一個給定的運行中的memcached伺服器在某個（可配置的）連接埠上監聽串連；用戶端串連該連接埠，發送命令給伺服器，讀取反饋，最後關閉串連。

沒有必要發送一個專門的命令去結束會話。用戶端可以在不需要該串連的時候就關閉它。注意：我們鼓勵用戶端緩衝它們與伺服器的串連，而不是每次要儲存或讀取資料的時候再次重建立立與伺服器的串連。memcache同時開啟很多串連不會對效能造成到大的影響，這是因為memcache在設計之處，就被設計成即使開啟了很多串連（數百或者需要時上千個串連）也可以高效的運行。緩衝串連可以節省與伺服器建立TCP串連的時間開銷（於此相比，在伺服器段為建立一個新的串連所做準備的開銷可以忽略不計）。

memcache通訊協定有兩種類型的資料：文本行和非結構化資料。文本行用來發送從用戶端到伺服器的命令以及從伺服器回送的反饋資訊。非結構化的資料用在用戶端希望儲存或者讀取資料時。伺服器會以字元流的形式嚴格準確的返回相應資料在儲存時儲存的資料。伺服器不關注位元組序，它也不知道位元組序的存在。memcahce對非結構化資料中的字元沒有任何限制，可以是任意的字元，讀取資料時，用戶端可以在前次返回的文本行中確切的知道接下來的資料區塊的長度。

文本行通常以“\r\n”結束。非結構化資料通常也是以“\r\n”結束，儘管\r、\n或者其他任何8位字元可以出現在資料區塊中。所以當用戶端從伺服器讀取資料時，必須使用前面提供的資料區塊的長度，來確定資料流的結束，二不是依據跟隨在字元流尾部的“\r\n”來確定資料流的結束，儘管實際上資料流格式如此。

2 -- 關鍵字 Keys

memcached使用關鍵字來區分儲存不同的資料。關鍵字是一個字串，可以唯一標識一條資料。當前關鍵字的長度限制是250個字元（當然目前用戶端似乎沒有需求用這麼長的關鍵字）；關鍵字一定不能包含控制字元和空格。

3 -- 命令Commands

memcahe有3種類型的命令：
1.儲存命令—（3個命令：set、add和replace）要求伺服器安裝關鍵字儲存資料。用戶端發送一個命令列，然後一個資料區塊；命令執行後用戶端等待一行反饋，用來表示命令執行成功與否。
2.讀取命令-- （只有1個命令：get）要求伺服器根據一組關鍵字讀取資料（在一個請求總可以包含一個或多個關鍵字）。用戶端發送一個包含請求關鍵字的命令列；命令傳遞到伺服器後，伺服器就尋找每一個關鍵字下的資料，然戶將資料以“一個關鍵字資料，一個反饋資訊行跟著一個資料區塊”的格式回送資料，直到伺服器發送“END”的反饋行。
3.其他命令，如flush_all，version等。這些命令不使用非結構化的資料。對於這些命令，用戶端發送一個文本的命令列，根據命令的特性等待一行資料或者在最後一行以“END“結尾的幾行反饋資訊。

 

所有的命令列總是以命令的名字開始，緊接著是以空格分割的參數。命令名稱都是小寫，並且是大小寫敏感的。

4 -- 逾時時間 Expiration times

一些發送到伺服器的命令包含逾時時間（該逾時時間對應於：資料項目儲存時間；用戶端操作限時）。在這些例子中，被發送的真即時間要麼是UNIX時間戳記（自1970年1月1日零時起的秒數數值），或者從目前時間開始算起的秒數。對於後一種情況，秒數的數值不能超過60*60*24*30（30天的秒數）；如果秒數的數值大於了這個數值，伺服器會認為該數值是UNIX時間戳記，而不是自目前時間開始的秒數位移值。

5 -- 錯誤資訊 Error strings

每個命令都有可能被反饋以一個錯誤訊息。這些錯誤訊息有以下三個類型：
1.“ERROR\r\n”
意味著用戶端發送了一個在協議中不存在的命令。
2."CLIENT_ERROR \r\n"
表示用戶端輸入的命令列上存在某種錯誤，輸入不符合協議規定。是一個人工可讀（human-readable）的錯誤注釋。
3."SERVER_ERROR \r\n"
表示伺服器在執行命令時發生了某些錯誤，致使伺服器無法執行下去。也是一個人工可讀（human-readable）的錯誤注釋。在一些情況下，錯誤導致伺服器不能再為用戶端服務（這樣的情況很少發生），伺服器就會在發生錯誤訊息後主動關閉串連。這也是伺服器主動關閉到用戶端串連的唯一情況。
後續秒數各種命令的時候，我們不再贅述錯誤訊息的情況，當我們要清楚錯誤是存在的，不可忽略。6 -- 儲存命令 Storage commands

首先，用戶端發生如下這樣的命令：
<command name>#<key>#<flags>#<exptime>#<bytes>\r\n
<data block>\r\n

 

其中：
<command name>是 set、add或者replace。set表示儲存該資料；add表示如果伺服器沒有儲存該關鍵字的情況下，儲存該資料；replace表示在伺服器已經擁有該關鍵字的情況下，替換原有內容。
<key>是用戶端要求伺服器儲存資料的關鍵字。
<flags>是一個16位的不帶正負號的整數，伺服器將它和資料一起儲存並且當該資料被檢索時一起返回。用戶端可能使用該數值作為一個位元影像來儲存特殊資料資訊；這個欄位對伺服器不是透明的。
<exptime>
是逾時時間。如果值為0表示該資料項目永遠不逾時（但有時候該資料項目可能被刪除以為其他資料騰出空間）；如果值不為0，可能是絕對的UNIX時間，也可能是自現在開始的位移值，它保證客戶段在這個逾時時間到達後，用戶端將取不到該資料項目。
<bytes>是隨後資料的位元組數，不包括終結符”\r\n”。<bytes>有可能是0，它後面將是一個空的資料區塊。
<data block>是真正要儲存資料流。
發送命令列和資料後，用戶端等待反饋，可以是如下幾種情況：
1."STORED\r\n" 表示儲存資料成功。
2."NOT_STORED\r\n" 表示發送的資料沒有儲存，但這不因為錯誤，而是發生在add或者replace命令不能滿足條件時，或者資料項目正處於要刪除的隊列中。
3.錯誤訊息

7 -- 讀取命令 Retrieval command

讀取命令如下所示：
get#<key>*\r\n
<key>*表示一個或多個使用空格分割的關鍵字字串。
發送命令後，用戶端等待返回一個或多個資料項目，每個資料項目的格式是一個文本行，後跟著一個資料區塊。當所有的資料項目發送完畢後，伺服器發送字串”END\r\n”表示伺服器反饋資料的結束。
返回資料項目的格式如下：
VALUE#<key>#<flags>#<bytes>\r\n
<data block>\r\n

 

<key>是發生資料項目的關鍵字。
<flags>是儲存該資料項目時，用戶端命令中的標誌欄位。
<bytes>是緊跟文本行後資料區塊的長度，不包括終結符”\r\n”。
<data block>是資料項目的資料部分。
如果請求命令列中的有些關鍵字對應的資料項目沒有被返回，這意味著伺服器沒有該關鍵字標示下的資料項目（有可能是從來沒有被儲存過，或者儲存過但被刪除掉以騰出記憶體空間，或者資料項目逾時了，再或者它被某個用戶端刪除了）。

8 -- 刪除 Deletion

刪除命令允許直接刪除資料項目，命令格式如下：
delete#<key>#<time>\r\n

 

<key>是用戶端希望伺服器刪除資料項目的關鍵字
<time>是用戶端希望伺服器阻止add和replace命令使用該關鍵字資料項目的秒數，可以是相對時間也可以是UNIX的絕對時間。在這段時間內，資料項目被放入一個刪除隊列，它不能被get命令讀取，在其上使用add和replace也會失敗，但使用set命令可以成功。當這個時間過去後，資料項目從伺服器的記憶體中真正的刪除。該參數是選擇性參數，如果不存在預設為0，這意味著立即從伺服器上刪除。
伺服器返回資訊：
1."DELETED\r\n" 表示資料項目刪除成功
2."NOT_FOUND\r\n" 表示該關鍵字指定的資料項目在伺服器上沒有找到
3.其他錯誤訊息
下面的flush_all命令使得所有存在的資料項目立即失效。

9 -- 增加/減少 Increment/Decrement

“incr”和”decr”命令用來修改以及存在的資料項目的內容，增加或者減少它。該資料被當作32位不帶正負號的整數處理。如果當前資料非此類資料，則經將該內容當作0來處理。另外在其上施加incr/decr命令的資料項目必須是業已存在的；對於不存在的資料項目不會將它作為0對待，而是以錯誤結束。
用戶端發送命令列如下格式：
incr#<key>#<value>\r\n
或者
decr#<key>#<value>\r\n
<key>是用戶端要修改資料項目的關鍵字
<value>是對該資料行進行增加或者減少的運算元。它是一個32位的不帶正負號的整數。
反饋資訊有如下幾種：
1."NOT_FOUND\r\n"
表明在伺服器上沒有找到該資料項目。
2."\r\n "
value是執行完增加/減少命令後，該資料項目新的數值。
3.錯誤資訊。
注意到“decr”命令的下溢問題，如果用戶端嘗試減少的數量小於0，其結果是0。“incr”命令的溢出問題沒有檢查。另外減少一個資料而使它減少了長度，但不保證減少它返回時的長度。該數字可能是附加空格的數字，但這隻是實現的最佳化，所以你不能相信它。

 

10 -- 統計 Statistics

“stats”命令用來查詢服務器的運行情況和其他內部資料。它有兩種情況，以有無參數來區分：
stats\r\n
或者
stats#<args>\r\n
第一種情況它導致伺服器輸出一般統計資訊以及設定資訊和文檔化內容。
第二種情況根據具體的參數，伺服器發送各種內部資料。這部分沒有在協議中文檔化，因為與memcache的開發人員有關其可能是隨時變化的。

 

11 -- 多用途統計 General-purpose statistics

當接收到沒有帶參數的“stats”命令後，伺服器發送許多類似與如下格式的文本行：
STAT#<name>#<value>\r\n
當類似的文本行全部發送完畢後，伺服器發送如下的文本行結束反饋資訊：
END\r\n
在所有STAT文本行中，<name>是該統計項目的名稱，<value>是其資料。下面是一份stats命令反饋的所有統計項目的列表，後面跟著其值的資料類型。在資料類型列中，”32u”表示一個32位不帶正負號的整數，”64u”表示一個64位不帶正負號的整數，”32u:32u”表示是兩個用冒號分割的32位不帶正負號的整數。

名稱	實值型別	含義
pid	32u	伺服器處理序的進程號
uptime	32u	伺服器自運行以來的秒數
time	32u	當前伺服器上的UNIX時間
version	string	伺服器的版本字串
rusage_user	32u:32u	伺服器處理序積累的使用者時間（秒:微妙）
rusage_system	32u:32u	伺服器處理序積累的系統時間（秒:微妙）
curr_items	32u	當前在伺服器上儲存的資料項目的個數
total_items	32u	在伺服器上曾經儲存過的資料項目的個數
bytes	64u	當前伺服器上儲存資料的位元組數
curr_connections	32u	處於開啟狀態的串連數目
total_connections	32u	曾經開啟過的所有串連的數目
connection_structures	32u	伺服器分配的串連結構體的個數
cmd_get	64u	get命令請求的次數
cmd_set	64u	儲存命令請求的次數
get_hits	64u	關鍵字擷取命中的次數
get_misses	64u	關鍵字擷取沒有命中的次數
evictions	64u	所有因逾時而被替換出記憶體的資料項目的個數
bytes_read	64u	伺服器從網路上讀取到的位元組數
bytes_write	64u	伺服器向網路上寫的位元組數
limit_maxbytes	64u	伺服器允許儲存資料的最大值

 

12 -- 其他命令 Other commands

"flush_all"是一個帶有可選數字參數的命令，它的執行總是成功的，伺服器總是響應以"OK\r\n"字串。它的作用是使得所有的資料項目立即（預設）或者經過一個指定的逾時時間後全部失效。在置資料項目失效後，對於讀取命令將不會返回任何內容，除非在失效後這些資料再次被儲存。flush_all並沒有真正的釋放這些存在過的資料項目佔用的記憶體空間；資料空間真實被佔用的情況發生在使用新的資料項目覆蓋老的資料項目時。該命令作用最準確的定義是：它導致所有更新時間早於該命令設定的時間點的資料項目，在被檢索時被忽略，其表現就像已被刪除了一樣。
使用帶有延時flush_all命令的目的是，當你有個memcached伺服器集區，需要重新整理所有的內容時，但不能在同一時間刷洗所有的伺服器，這樣就可能因為所有的伺服器突然都要重建立立資料內容，而導致資料庫壓力的顛簸。延時選項允許你設定他們隔10秒失效（設定第一個延時為0，第二個10秒，第三個20秒等等）。
"version"是一個沒有參數的命令，命令格式如下：
version\r\n
伺服器發回的反饋資訊如下：
1."VERSION#<version>\r\n"
<version>是從伺服器返回的版本字串。
2.錯誤訊息。
"verbosity"是一個帶有數字參數的命令。它的執行總是成功的，伺服器反饋以"OK\r\n"表示執行完成。它用來設定日誌輸出的詳細等級。
"quit"是一個沒有參數的命令。其格式如下：
quit\r\n
當伺服器接受到此命令後，就關閉與該客戶的串連。不管怎樣，用戶端可以在任意不需要該串連的時刻關閉它，而不需要發送該命令。

 

13 -- UDP協議 UDP protocol

當基於TCP協議的串連數超過TCP串連的上限時，我們可以使用UDP協議來替代。但是UDP協議介面不提供可靠的傳輸，所以多用在不嚴格要求成功的操作上；典型的get請求會因為緩衝的問題，引起丟失或者不完整的傳輸。
每個UDP資料包包含一個簡單的幀頭，接著就是如TCP協議描述的資料格式的資料流。在當前的實現中，請求必須包含在一個單獨的UDP資料包中，但返回可能分散在多個資料包中。（唯一的可以拆分請求資料包的是大的多關鍵字get請求和set請求，鑒於可靠性相比而言他們更適合用TCP傳輸。）
幀頭有8位元組長，如下是其格式（所有的數字都是16位網路位元組序整形，高位在前）：
0 - 1 請求ID
2 - 3 序號
4 - 5 在當前的訊息中含有的資料包的個數
6 - 7 保留以後使用，當前必須為0
請求ID由用戶端提供。它的典型值是一個從隨機種子開始遞增值，實際上用戶端可以使用任意的請求ID。伺服器的反饋資訊中包含了和請求命令中一樣的請求ID。用戶端憑藉這個請求ID區分來自於同一伺服器的反饋。每一個包含未知請求ID的資料包，可能是由於延時反饋造成，這些資料包都應該拋棄不用。
序號從0到n-1，n是訊息中總的資料包的個數。用戶端按照序號排序重組資料包；結果序列中包含了一個完整的如TCP協議一樣格式的反饋資訊（包含了“\r\n”總結字串）。