memcache協(xié)議中文版-資料下載頁
2025-08-05 18:41本頁面
【正文】 取回請求總數(shù)cmd_set32u存儲請求總數(shù)get_hits32u請求成功的總次數(shù)get_misses32u請求失敗的總次數(shù)bytes_read64u服務器從網(wǎng)絡讀取到的總字節(jié)數(shù)bytes_written64u服務器向網(wǎng)絡發(fā)送的總字節(jié)數(shù)limit_maxbytes32u服務器在存儲時被允許使用的字節(jié)總數(shù)其它命令“flush_all”命令有一個可選的數(shù)字參數(shù)。它總是執(zhí)行成功，服務器會發(fā)送“OK\r\n”回應。它的效果是使已經(jīng)存在的項目立即失效（缺省），或在指定的時間后。此后執(zhí)行取回命令，將不會有任何內(nèi)容返回（除非重新存儲同樣的鍵名）。flush_all 實際上沒有立即釋放項目所占用的內(nèi)存，而是在隨后陸續(xù)有新的項目被儲存時執(zhí)行。flush_all 效果具體如下：它導致所有更新時間早于flush_all所設定時間的項目，在被執(zhí)行取回命令時命令被忽略。“version”命令沒有參數(shù)：version\r\n在回應中，服務器發(fā)送：VERSION version\r\nversion 是服務器的版本字串。“quit”命令沒有參數(shù)：quit\r\n接收此命令后，服務器關閉連接。不過，客戶端可以在不再需要時，簡單地關閉連接就行，并不一定需要發(fā)送這個命令。UDP 協(xié)議當來自客戶端的連接數(shù)遠大于TCP連接的上限時，可以使用基于UDP的接口。UDP接口不能保證傳輸?shù)轿?，所以只有在不要求成功的操作中使用；比如被用于一個“get”請求時，會因不當?shù)木彺嫣幚矶l(fā)生錯誤或回應有遺失。每個UDP數(shù)據(jù)包都包含一個簡單的幀頭，數(shù)據(jù)之后的內(nèi)容與TCP協(xié)議的描述類似。在執(zhí)行所產(chǎn)生的數(shù)據(jù)流中，請求必須被包含在單獨的一個UDP數(shù)據(jù)包中，但是回應可能跨越多個數(shù)據(jù)包。（只有“get”和“set”請求例外，跨越了多個數(shù)據(jù)包）幀頭有8字節(jié)長，如下（均由16位整數(shù)組成，網(wǎng)絡字節(jié)順序，高位在前）： 01 請求ID 23 序號 45 該信息的數(shù)據(jù)包總數(shù) 67 保留位，必須為0 請求ID有客戶端提供。一般它會是一個從隨機基數(shù)開始的遞增值，不過客戶端想用什么樣的請求ID都可以。服務器的回應會包含一個和請求中的同樣的ID?？蛻舳耸褂谜埱驣D來區(qū)分每一個回應。任何一個沒有請求ID的數(shù)據(jù)包，可能是之前的請求遭到延遲而造成的，應該被丟棄。序號的返回是從0到n1，n是該條信息的數(shù)據(jù)包數(shù)量。7
環(huán)評公示相關推薦
鄂ICP備17016276號-1