redis——命令请求的执行过程
發(fā)送命令請(qǐng)求
當(dāng)用戶在客戶端中鍵入一個(gè)命令請(qǐng)求時(shí), 客戶端會(huì)將這個(gè)命令請(qǐng)求轉(zhuǎn)換成協(xié)議格式, 然后通過連接到服務(wù)器的套接字, 將協(xié)議格式的命令請(qǐng)求發(fā)送給服務(wù)器。
讀取命令請(qǐng)求
當(dāng)客戶端與服務(wù)器之間的連接套接字因?yàn)榭蛻舳说膶懭攵兊每勺x時(shí), 服務(wù)器將調(diào)用命令請(qǐng)求處理器來執(zhí)行以下操作:
命令執(zhí)行器:查找命令實(shí)現(xiàn)
命令執(zhí)行器要做的第一件事就是根據(jù)客戶端狀態(tài)的?argv[0]?參數(shù), 在命令表(command table)中查找參數(shù)所指定的命令, 并將找到的命令保存到客戶端狀態(tài)的?cmd?屬性里面。
命令表是一個(gè)字典, 字典的鍵是一個(gè)個(gè)命令名字,比如?"set"?、?"get"?、?"del"?,等等; 而字典的值是一個(gè)個(gè)?redisCommand?結(jié)構(gòu), 每個(gè)?redisCommand?結(jié)構(gòu)記錄了一個(gè) Redis 命令的實(shí)現(xiàn)信息。
命令名字的大小寫不影響命令表的查找結(jié)果
因?yàn)槊畋硎褂玫氖谴笮憻o關(guān)的查找算法, 無論輸入的命令名字是大寫、小寫或者混合大小寫, 只要命令的名字是正確的, 就能找到相應(yīng)的 redisCommand 結(jié)構(gòu)。
比如說, 無論用戶輸入的命令名字是 "SET" 、 "set" 、 "SeT" 又或者 "sEt" , 命令表返回的都是同一個(gè) redisCommand 結(jié)構(gòu)。
redis> SET msg "hello world" OKredis> set msg "hello world" OKredis> SeT msg "hello world" OKredis> sEt msg "hello world" OK命令執(zhí)行器:執(zhí)行預(yù)備操作
到目前為止, 服務(wù)器已經(jīng)將執(zhí)行命令所需的命令實(shí)現(xiàn)函數(shù)(保存在客戶端狀態(tài)的?cmd?屬性)、參數(shù)(保存在客戶端狀態(tài)的?argv?屬性)、參數(shù)個(gè)數(shù)(保存在客戶端狀態(tài)的?argc?屬性)都收集齊了, 但是在真正執(zhí)行命令之前, 程序還需要進(jìn)行一些預(yù)備操作, 從而確保命令可以正確、順利地被執(zhí)行, 這些操作包括:
- 檢查客戶端狀態(tài)的?cmd?指針是否指向?NULL?, 如果是的話, 那么說明用戶輸入的命令名字找不到相應(yīng)的命令實(shí)現(xiàn), 服務(wù)器不再執(zhí)行后續(xù)步驟, 并向客戶端返回一個(gè)錯(cuò)誤。
- 根據(jù)客戶端?cmd?屬性指向的?redisCommand?結(jié)構(gòu)的?arity?屬性, 檢查命令請(qǐng)求所給定的參數(shù)個(gè)數(shù)是否正確, 當(dāng)參數(shù)個(gè)數(shù)不正確時(shí), 不再執(zhí)行后續(xù)步驟, 直接向客戶端返回一個(gè)錯(cuò)誤。 比如說, 如果?redisCommand?結(jié)構(gòu)的?arity?屬性的值為?-3?, 那么用戶輸入的命令參數(shù)個(gè)數(shù)必須大于等于?3?個(gè)才行。
- 檢查客戶端是否已經(jīng)通過了身份驗(yàn)證, 未通過身份驗(yàn)證的客戶端只能執(zhí)行?AUTH?命令, 如果未通過身份驗(yàn)證的客戶端試圖執(zhí)行除?AUTH?命令之外的其他命令, 那么服務(wù)器將向客戶端返回一個(gè)錯(cuò)誤。
- 如果服務(wù)器打開了?maxmemory?功能, 那么在執(zhí)行命令之前, 先檢查服務(wù)器的內(nèi)存占用情況, 并在有需要時(shí)進(jìn)行內(nèi)存回收, 從而使得接下來的命令可以順利執(zhí)行。 如果內(nèi)存回收失敗, 那么不再執(zhí)行后續(xù)步驟, 向客戶端返回一個(gè)錯(cuò)誤。
- 如果服務(wù)器上一次執(zhí)行?BGSAVE?命令時(shí)出錯(cuò), 并且服務(wù)器打開了?stop-writes-on-bgsave-error?功能, 而且服務(wù)器即將要執(zhí)行的命令是一個(gè)寫命令, 那么服務(wù)器將拒絕執(zhí)行這個(gè)命令, 并向客戶端返回一個(gè)錯(cuò)誤。
- 如果客戶端當(dāng)前正在用?SUBSCRIBE?命令訂閱頻道, 或者正在用?PSUBSCRIBE?命令訂閱模式, 那么服務(wù)器只會(huì)執(zhí)行客戶端發(fā)來的?SUBSCRIBE?、?PSUBSCRIBE?、?UNSUBSCRIBE?、?PUNSUBSCRIBE?四個(gè)命令, 其他別的命令都會(huì)被服務(wù)器拒絕。
- 如果服務(wù)器正在進(jìn)行數(shù)據(jù)載入, 那么客戶端發(fā)送的命令必須帶有?l?標(biāo)識(shí)(比如?INFO?、?SHUTDOWN?、?PUBLISH?,等等)才會(huì)被服務(wù)器執(zhí)行, 其他別的命令都會(huì)被服務(wù)器拒絕。
- 如果服務(wù)器因?yàn)閳?zhí)行 Lua 腳本而超時(shí)并進(jìn)入阻塞狀態(tài), 那么服務(wù)器只會(huì)執(zhí)行客戶端發(fā)來的?SHUTDOWN nosave?命令和?SCRIPT KILL?命令, 其他別的命令都會(huì)被服務(wù)器拒絕。
- 如果客戶端正在執(zhí)行事務(wù), 那么服務(wù)器只會(huì)執(zhí)行客戶端發(fā)來的?EXEC?、?DISCARD?、?MULTI?、?WATCH?四個(gè)命令, 其他命令都會(huì)被放進(jìn)事務(wù)隊(duì)列中。
- 如果服務(wù)器打開了監(jiān)視器功能, 那么服務(wù)器會(huì)將要執(zhí)行的命令和參數(shù)等信息發(fā)送給監(jiān)視器。
當(dāng)完成了以上預(yù)備操作之后, 服務(wù)器就可以開始真正執(zhí)行命令了。
命令執(zhí)行器:調(diào)用命令的實(shí)現(xiàn)函數(shù)
在前面的操作中, 服務(wù)器已經(jīng)將要執(zhí)行命令的實(shí)現(xiàn)保存到了客戶端狀態(tài)的?cmd?屬性里面, 并將命令的參數(shù)和參數(shù)個(gè)數(shù)分別保存到了客戶端狀態(tài)的?argv?屬性和?argc?屬性里面, 當(dāng)服務(wù)器決定要執(zhí)行命令時(shí), 它只要執(zhí)行以下語句就可以了:
// client 是指向客戶端狀態(tài)的指針client->cmd->proc(client);因?yàn)閳?zhí)行命令所需的實(shí)際參數(shù)都已經(jīng)保存到客戶端狀態(tài)的?argv?屬性里面了, 所以命令的實(shí)現(xiàn)函數(shù)只需要一個(gè)指向客戶端狀態(tài)的指針作為參數(shù)即可。
命令執(zhí)行器:執(zhí)行后續(xù)工作
在執(zhí)行完實(shí)現(xiàn)函數(shù)之后, 服務(wù)器還需要執(zhí)行一些后續(xù)工作:
- 如果服務(wù)器開啟了慢查詢?nèi)罩竟δ?#xff0c; 那么慢查詢?nèi)罩灸K會(huì)檢查是否需要為剛剛執(zhí)行完的命令請(qǐng)求添加一條新的慢查詢?nèi)罩尽?/li>
- 根據(jù)剛剛執(zhí)行命令所耗費(fèi)的時(shí)長(zhǎng), 更新被執(zhí)行命令的?redisCommand?結(jié)構(gòu)的?milliseconds?屬性, 并將命令的?redisCommand?結(jié)構(gòu)的?calls?計(jì)數(shù)器的值增一。
- 如果服務(wù)器開啟了 AOF 持久化功能, 那么 AOF 持久化模塊會(huì)將剛剛執(zhí)行的命令請(qǐng)求寫入到 AOF 緩沖區(qū)里面。
- 如果有其他從服務(wù)器正在復(fù)制當(dāng)前這個(gè)服務(wù)器, 那么服務(wù)器會(huì)將剛剛執(zhí)行的命令傳播給所有從服務(wù)器。
當(dāng)以上操作都執(zhí)行完了之后, 服務(wù)器對(duì)于當(dāng)前命令的執(zhí)行到此就告一段落了, 之后服務(wù)器就可以繼續(xù)從文件事件處理器中取出并處理下一個(gè)命令請(qǐng)求了。
將命令回復(fù)發(fā)送給客戶端
前面說過, 命令實(shí)現(xiàn)函數(shù)會(huì)將命令回復(fù)保存到客戶端的輸出緩沖區(qū)里面, 并為客戶端的套接字關(guān)聯(lián)命令回復(fù)處理器, 當(dāng)客戶端套接字變?yōu)榭蓪憼顟B(tài)時(shí), 服務(wù)器就會(huì)執(zhí)行命令回復(fù)處理器, 將保存在客戶端輸出緩沖區(qū)中的命令回復(fù)發(fā)送給客戶端。
當(dāng)命令回復(fù)發(fā)送完畢之后, 回復(fù)處理器會(huì)清空客戶端狀態(tài)的輸出緩沖區(qū), 為處理下一個(gè)命令請(qǐng)求做好準(zhǔn)備。
客戶端接收并打印命令回復(fù)
當(dāng)客戶端接收到協(xié)議格式的命令回復(fù)之后, 它會(huì)將這些回復(fù)轉(zhuǎn)換成人類可讀的格式, 并打印給用戶觀看(假設(shè)使用的是 Redis 自帶的?客戶端)
?
?
以上就是 Redis 客戶端和服務(wù)器執(zhí)行命令請(qǐng)求的整個(gè)過程了。
?
總結(jié)
以上是生活随笔為你收集整理的redis——命令请求的执行过程的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: servlet基础总结
- 下一篇: leetcode82. 删除排序链表中的