摘要：讀取命令請求當客戶端與服務(wù)器之間的套接字因客戶端的寫入變得可讀時，服務(wù)器將調(diào)用命令請求處理器執(zhí)行以下操作讀取套接字中的命令請求，并將其保存到客戶端狀態(tài)的輸入緩沖區(qū)。

繼續(xù)我們上一節(jié)的討論。服務(wù)器啟動了，客戶端也發(fā)送命令了。接下來，就要到服務(wù)器“表演”的時刻了。

服務(wù)器讀取到命令請求后，會進行一系列的處理。

當客戶端與服務(wù)器之間的套接字因客戶端的寫入變得可讀時，服務(wù)器將調(diào)用命令請求處理器執(zhí)行以下操作：

讀取套接字中的命令請求，并將其保存到客戶端狀態(tài)的輸入緩沖區(qū)。

對輸入緩沖區(qū)的命令請求進行分析，提取出命令請求中包含的命令參數(shù)及參數(shù)個數(shù)，然后分別將參數(shù)和參數(shù)個數(shù)保存到客戶端狀態(tài)的 argv 屬性和 argc 屬性里。

調(diào)用命令執(zhí)行器，執(zhí)行客戶端指定的命令。

上面的 SET 命令保存到客戶端狀態(tài)的輸入緩存區(qū)之后，客戶端狀態(tài)如圖 4。

之后，分析程序?qū)斎刖彌_區(qū)中的協(xié)議進行分析，并將得出的結(jié)果保存的客戶端的 argv 和 argc 屬性中，如圖 5 所示：

之后，服務(wù)器將通過調(diào)用命令執(zhí)行器來完成執(zhí)行命令的余下步驟。

命令執(zhí)行器要做的第一件事就是根據(jù) argv[0] 參數(shù)，在命令表（commandtable）中查找參數(shù)所指定的命令，并將找到的命令保存到 cmd 屬性中。

命令表是一個字典，字典的鍵是一個個命令名稱，比如 "SET"、"GET" 等。而字典的值則是一個個 redisCommand 結(jié)構(gòu)，每個 redisCommand 結(jié)構(gòu)記錄了 Redis 命令的實現(xiàn)信息。源碼如下：

# server.h/redisCommand
struct redisCommand {
    char *name;   // 命令名稱。如 "SET"
    redisCommandProc *proc; // 對應函數(shù)指針，指向命令的實現(xiàn)函數(shù)。比如 SET 對應的 setCommand 函數(shù)
    int arity;    // 命令參數(shù)的格個數(shù)。用來檢查命令請求的格式是否合法。
                        // 要注意的命令的名稱也是一個參數(shù)。像我們上面的 SET KEY VALUE 命令，實際上有三個參數(shù)。
    char *sflags; // 字符串形式的標識值。記錄了命令的屬性。
    int flags;    // 對 sflags 標識分析得出的二進制標識，由程序自動生成。檢查命令時，實際上使用的是此字段
    redisGetKeysProc *getkeys_proc; // 指針函數(shù)，通過此方法來指定 key 的位置。
    int firstkey; // 第一個 key 的位置
    int lastkey;  // 最后一個 key 的位置
    int keystep;  // key 之間的間距
    long long microseconds, calls; // 命令的總調(diào)用時間及調(diào)用次數(shù)
};

另外，對于 sflags 屬性，可使用的標識值及含義如下表：

命令表結(jié)構(gòu)如圖 6：

對于我們上面的 SET KEY VALUE 命令，當程序以圖 5 中的 argv[0] 作為輸入，在命令表中進行查找時，命令表返回 "set" 鍵對于的 redisCommand 結(jié)構(gòu)，客戶端狀態(tài)的 cmd 指針會指向這個 redisCommand 結(jié)構(gòu)。如圖 7 所示：

要注意的是，對于 Redis 而言，命令名字的大小寫不影響命令表的查找結(jié)果，也就是命令名稱不區(qū)分大小寫。執(zhí)行 SET 和 set、Set 將獲得相同結(jié)果。

到目前為止，服務(wù)器已經(jīng)將執(zhí)行命令所需要的命令實現(xiàn)函數(shù)（客戶端 cmd 屬性）、參數(shù)（客戶端 argv 屬性）、參數(shù)個數(shù)（客戶端 argc 屬性）都初始化完畢。但在真正執(zhí)行命令之前，程序還會進行一些預備操作，保證命令可以正確、順利的被執(zhí)行。預備操作包括：

檢查客戶端的 cmd 指針是否指向 NULL，如果是的話，說明用戶輸入的命令名稱沒有對應的函數(shù)，服務(wù)器將不再執(zhí)行后續(xù)操作，并向客戶端返回一個錯誤。

根據(jù)客戶端 cmd 屬性指向的 redisCommand 結(jié)果的 arity 屬性，檢查命令請求所給定的參數(shù)個數(shù)是否正確。

檢查客戶端是否已經(jīng)通過了身份驗證。未通過身份驗證的客戶端只能執(zhí)行 AUTH 命令。否則，將會向客戶端返回一個錯誤。

如果服務(wù)器打開了 maxmemory 功能，在執(zhí)行命令之前，會先檢查服務(wù)器的內(nèi)存占用情況，并在有需要時進行內(nèi)存回收，從而使得接下來的命令可以順利執(zhí)行。如果內(nèi)存回收失敗，將不再執(zhí)行后續(xù)步驟，向客戶端返回一個錯誤。

如果服務(wù)器上一次執(zhí)行 BGSAVE 命令時出錯，并且服務(wù)器打開了 stop-writes-on-bgsave-error 功能，而將要執(zhí)行的命令是一個寫命令，那么服務(wù)器將拒絕執(zhí)行這個鞋命令，并向客戶端返回一個錯誤。

如果客戶端正在用 SUBSCRIBE 和 PSUBSCRIBE 命令訂閱頻道或模式，那么服務(wù)器只會執(zhí)行客戶端發(fā)來的 SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE、PUNSUBSCRIBE 四個命令，其它命令都會被拒絕。

如果服務(wù)器正在進行數(shù)據(jù)載入，那么客戶端發(fā)送是命令必須帶有 l 標識才會被服務(wù)器執(zhí)行。

如果客戶端正在執(zhí)行事務(wù)，那么服務(wù)器只會執(zhí)行 EXEC、DISCARD、MULTI、WATCH 四個命令，其他命令都會被放進事務(wù)隊列中。

如果服務(wù)器打開了監(jiān)視器功能，那么服務(wù)器會將要執(zhí)行的命令和參數(shù)等信息發(fā)送給監(jiān)視器。

當完成了以上預備操作之后，服務(wù)器就開始真正的執(zhí)行命令了。

要注意的是，上面列出的預備操作只是服務(wù)器在單機模式下的檢查操作。如果在復制或者集群模式下，預備操作還會更多。

在前面的操作中 ，服務(wù)器已經(jīng)將要執(zhí)行的命令實現(xiàn)、參數(shù)、參數(shù)個數(shù)保存在客戶端結(jié)構(gòu)中。

對于我們上面的 SET KEY VALUE 命令，圖 8 包含了命令實現(xiàn)、參數(shù)和參數(shù)個數(shù)結(jié)構(gòu)：

當服務(wù)器決定要執(zhí)行命令時，只要執(zhí)行以下語句即可：

// client 是指向客戶端狀態(tài)的指針。server.c/call()
client->cmd->proc(client);

上面的執(zhí)行語句實際上就是調(diào)用 setCommand 函數(shù)（t_string.c）。

被調(diào)用的命令實現(xiàn)函數(shù)會執(zhí)行指定的操作，并產(chǎn)生相應的命令回復，這些回復會被保存在客戶端狀態(tài)的輸出緩沖區(qū)中（bug 屬性 和 reply 屬性），之后實現(xiàn)函數(shù)會為客戶端的套接字關(guān)聯(lián)命令回復處理器，由命令回復處理器返回給客戶端。

回到我們的示例，setCommand(client) 將產(chǎn)生一個 "+OKrn" 回復，這個回復被保存在客戶端的 buf 屬性中。如圖 9 所示：

實現(xiàn)函數(shù)執(zhí)行完后，服務(wù)器還會執(zhí)行一些后續(xù)工作，主要包括：

如果服務(wù)器開啟了 slow-log 功能，那么慢查詢?nèi)罩灸K將會檢查是否需要將剛執(zhí)行的命令添加到慢查詢?nèi)罩尽?/p>

更新 redisCommand 結(jié)構(gòu)的 milliseconds 和 calls 屬性。

如果服務(wù)器開啟了 AOF 持久化功能，那么 AOF 持久化模塊會將剛剛執(zhí)行的命令請求寫入到 AOF 緩沖區(qū)中。

如果有其它服務(wù)器正在復制當前這個服務(wù)器，那么服務(wù)器將會把剛剛執(zhí)行的命令傳播給所有從服務(wù)器。

以上后續(xù)操作執(zhí)行完畢后，一條執(zhí)行命令也就執(zhí)行完成了。服務(wù)器可以繼續(xù)處理后續(xù)的命令。

上面過程中，命令實現(xiàn)函數(shù)會將命令回復保存到客戶端的輸出緩沖區(qū)中，并為客戶端的套接字關(guān)聯(lián)命令回復處理器。當客戶端套接字變?yōu)榭蓪憼顟B(tài)時，服務(wù)器就會執(zhí)行命令回復處理器，將命令回復發(fā)送給客戶端。

當命令回復發(fā)送完畢后，回復處理器會情況客戶端的輸出緩沖區(qū)，為處理下一個命令請求做好準備。

以圖 9 所示的客戶端狀態(tài)為例，當客戶端的套接字變?yōu)榭蓪憼顟B(tài)時，命令回復處理器會將協(xié)議格式的命令回復 "+OKrn" 發(fā)送給客戶端。

命令處理請求，函數(shù)調(diào)用堆棧信息如圖 3-7-1：

命令回復，函數(shù)調(diào)用堆棧信息如圖 3-7-2：

客戶端接收到命令回復之后，會將回復轉(zhuǎn)換成我們可讀的格式，并打印在屏幕上（對于 redis-cli 客戶端），如圖 10 所示。

至此，我們走完了從發(fā)起一個命令請求，到收到回復的所有過程。對于我們最開始提的問題，服務(wù)器如何響應客戶端請求，你有答案了嗎？

服務(wù)器通過 networking.c/readQueryFromClient() 讀取和執(zhí)行對應命令。

服務(wù)器通過 networking.c/writeToClient() 將命令回復發(fā)送給客戶端。