redis源碼之dict

你們都知道redis默認是16個db，可是這些db底層的設計結構是什麼樣的呢？
咱們來簡單的看一下源碼,重要的字段都有所註釋

typedef struct redisDb {
    dict *dict;                 /* The keyspace for this DB   字典數據結構，很是重要*/
    dict *expires;              /* Timeout of keys with a timeout set   過時時間*/
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP)  list一些數據結構中用到的阻塞api*/
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS  事務相關處理 */
    int id;                     /* Database ID */
    long long avg_ttl;          /* Average TTL, just for stats */
    unsigned long expires_cursor; /* Cursor of the active expire cycle. */
    list *defrag_later;         /* List of key names to attempt to defrag one by one, gradually. */
} redisDb;

redis中的全部kv都是存放在dict中的，dict類型在redis中很是重要。

字典disc的數據結構以下

typedef struct dict {
    dictType *type;  //
    void *privdata;  
    dictht ht[2];    //hashtable,每一個dict都有兩個這樣的數據結構，主要用於hash擴容
    long rehashidx; /* rehashing not in progress if rehashidx == -1  rehash的做用  防止鏈表無限增加*/
    unsigned long iterators; /* number of iterators currently running   遍歷記錄的一些字段*/
} dict;

redis中當出現hash衝突的時候，咱們會採用頭插法(鏈表)的方式來解決，可是鏈表無限增常的話hashtable會退化，退化成一個鏈表，影響查詢效率，這個時候咱們就須要對以前的數組進行擴容，把老的數據搬到新數組上面，這個過程就是rehash

接下來我們來看看dictType的類型

typedef struct dictType {
    uint64_t (*hashFunction)(const void *key);
    void *(*keyDup)(void *privdata, const void *key);  //key用於數據類型的複製
    void *(*valDup)(void *privdata, const void *obj);  //value用於數據類型的複製
    int (*keyCompare)(void *privdata, const void *key1, const void *key2); //hash衝突的時候須要在衝突的值裏面一個一個的對比
    void (*keyDestructor)(void *privdata, void *key);
    void (*valDestructor)(void *privdata, void *obj);
} dictType;

typedef struct dictht {
    dictEntry **table;  //指向數組的首地址  是健值對的核心結構
    unsigned long size;//數組的長度
    unsigned long sizemask; //恆等於size-1
    unsigned long used;
} dictht;

typedef struct  {
    void *key;  //指向SDS的數據結構
    union {  //聯合體表示value類型,只會用到一個字段
        void *val;    //指向redis對象 redisObject
        uint64_t u64;
        int64_t s64;
        double d;  
    } v;
    struct dictEntry *next;  //頭插法解決hash衝突
} dictEntry;

接下來咱們看一下內存關係的對應圖

typedef struct redisObject {
    unsigned type:4;  //當前對象類型 list  string hash set zset等
    unsigned encoding:4; //redis作的底層優化(編碼)
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

最後我們有一張總的圖來表是redis的內存關係

encoding存儲的優化策略

1:整型編碼的處理

咱們先來看一個例子

127.0.0.1:6379> set type-int 12345
OK
127.0.0.1:6379> object encoding type-int
"int"
//返回的encoding類型是int
127.0.0.1:6379> set type-int-long 12345678901234567890
OK
127.0.0.1:6379> object encoding type-int-long
"embstr"
//返回的encoding類型是embstr

咱們能夠發現，在都是數字的時候，若是長度小於20，就會自動轉換爲int類型，這是redis中專門作的處理

if (len <= 20 && string2l(s, len, &value))

在一個redisObject中，就能夠直接用ptr去存儲整型值，而不用從新去開闢一塊sds的空間

2:redis對象字符串存儲相關優化

127.0.0.1:6379> set type-str-short xxx
OK
127.0.0.1:6379> object encoding type-str-short
"embstr"




127.0.0.1:6379> set type-str-long xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-x
//字符串長度45
127.0.0.1:6379> object encoding type-str-long
"raw"



127.0.0.1:6379> set type-str-long2 xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-
//字符串長度44
127.0.0.1:6379> object encoding type-str-long2
"embstr"

一個redisobject是存在內存中的，cpu在完成一個io的時候，它是怎麼來讀數據的呢，其實cup的io中有一個緩衝行的概念，在linux系統中，一個緩衝行通常是64個字節
接下來咱們看看一個redis對象大概佔多大的內存空間，其實咱們能夠大概算出來。

typedef struct redisObject {
    unsigned type:4;  //4bit
    unsigned encoding:4; //4bit
    unsigned lru:LRU_BITS; //24bit
    int refcount;   //4byte
    void *ptr;   //8byte
} robj;

一個redis對象自己就須要佔 （4bit+4bit+24bit = 4byte） + 4byte + 8byte = 16byte的大小

這樣的話一個緩衝行還剩餘48個byte的大小，有點浪費，
48個byte，按照sds的分配策略應該在sdshdr8那個區間中，而sdshdr8自己就須要佔3個字節，sds須要兼容c語言的函數庫，都會在結尾加上\0，因此sdshdr8自己是佔用4個字節，因此一個緩衝行中還剩餘44個字節，來存儲剩餘的數據，因此在redis字符串對象中，當長度小於44的時候，encoding的類型是embstr，沒有新開闢一塊sds空間

關注個人技術公衆號，每週都有優質技術文章推送。
微信掃一掃下方二維碼便可關注：