稍微猜想的話應該能猜到，
redis是根據不同的命令來找到不同的處理函式的。
這些命令的構成基本有以下規則
command key value…那麼redis是怎麼根據不同的command找到對應的處理函式的？
redis comand的原型宣告
在開始理解這部分之前，有個前提需要說明
這部分分析是脫離了redis對client傳輸到服務端的資料獲取和解析過程的，
因為這部分邏輯涉及到事件迴圈和核心初始化**，
只分析資料物件的話可以跳過這部分。回頭再補過。
command的結構定義在redis.h中，
struct rediscommand
;
第二個 proc，是命令的執行函式。
執行函式的原型定義如下
typedef
void
rediscommandproc
(redisclient *c)
;
他們都在redis.h的1293行開始宣告。
比如反覆舉例的 set 命令，
void
setcommand
(redisclient *c)
;
上面說到redis原始碼定義了乙個rediscommand結構體，
看redis.c的120行，
這裡定義了乙個叫 rediscommandtable 的陣列，
struct rediscommand rediscommandtable=
,,..
.
,
「set」，是結構體裡的name，
setcommand，是結構體裡的 proc 指標。
顯而易見，
redis服務在解析出客戶端傳過來的命令是哪個操作之後，就可以從rediscommandtable裡拿到對應的結構體，
然後把解析完的命令分配給他們去操作。
命令的註冊是從 populatecommandtable 開始的，
它在redis.c的1787行開始，
void
populatecommandtable
(void
) f++;}
retval1 =
dictadd
(server.commands,
sdsnew
(c->name)
, c)
;/* populate an additional dictionary that will be unaffected
* by rename-command statements in redis.conf. */
retval2 =
dictadd
(server.orig_commands,
sdsnew
(c->name)
, c)
;redisassert
(retval1 == dict_ok && retval2 == dict_ok);}
}
依據 key-value 的形式，
從上面的**可以看出來，
key 是命令的name，
value 是命令的 proc 指標。
而這些東西通通都放到 server.commands 和 server.oigin_commands 這兩個dict裡。
匹配匹配命令的邏輯比較清晰，簡單說就是拿到command後，去dict裡查詢匹配的rediscommand結構體。
在redis.c的1874開始，有幾個lookup函式都是幹這事的。
比如下面這個
struct rediscommand *
lookupcommand
(sds name)
有興趣可以跟進去 dictfetchvalue 看看，最後會跑到 dictfind 函式。
redis 資料結構與物件
簡單說下redis的資料結構，這些在網上也都有很詳細的解釋，redis 設計與實現 這本書基於redis3.0的，但是現在已經5.0 了，所以有些資料結構發生了變化，其中我自己實現發現了一部分，可能還有沒發現的。慢慢實踐吧 簡單動態字串是在c語音傳統的字串基礎上構建的，其資料結構為 struct s...
Redis資料結構與物件
redis使用五種型別物件實現實現鍵值對資料庫 字串 列表 雜湊 集合 有序集合 列表編碼 ziplist或linkedlist 雜湊編碼 ziplist或hashtable 集合編碼 intset或hashtable 有序集合編碼 ziplist或skiplist struct sdshdr 二進...
Redis資料結構與物件（二）
1 物件共享 如果redis中已經set了乙個字串或數字，再set同樣值，這時會實現物件引用共享。值物件的refcount會出現變化，增加。redis set a 100 ok redis set b 100 redis object refcount a integer 2 object refc...