面試官:你看過Redis數據結構底層實現嗎?

面試中,redis也是很受面試官親睞的一部分。我向在這裏講的是redis的底層數據結構,而不是你理解的五大數據結構。你有沒有想過redis底層是怎樣的數據結構呢,他們和咱們java中的HashMap、List、等使用的數據結構有什麼區別呢。java

1. 字符串處理(string)

咱們都知道redis是用C語言寫,可是C語言處理字符串和數組的成本是很高的,下面我分別說幾個例子。node

沒有數據結構支撐的幾個問題

  1. 及其容易形成緩衝區溢出問題,好比用strcat(),在用這個函數以前必需要先給目標變量分配足夠的空間,不然就會溢出。
  2. 若是要獲取字符串的長度,沒有數據結構的支撐,可能就須要遍歷,它的複雜度是O(N)
  3. 內存重分配。C字符串的每次變動(曾長或縮短)都會對數組做內存重分配。一樣,若是是縮短,沒有處理好多餘的空間,也會形成內存泄漏。

好了,Redis本身構建了一種名叫Simple dynamic string(SDS)的數據結構,他分別對這幾個問題做了處理。咱們先來看看它的結構源碼:面試

struct sdshdr{
     //記錄buf數組中已使用字節的數量
     //等於 SDS 保存字符串的長度
     int len;
     //記錄 buf 數組中未使用字節的數量
     int free;
     //字節數組,用於保存字符串
     char buf[];
}

再來講說它的優勢:redis

  1. 開發者不用擔憂字符串變動形成的內存溢出問題。
  2. 常數時間複雜度獲取字符串長度len字段
  3. 空間預分配free字段,會默認留夠必定的空間防止屢次重分配內存。

更多瞭解:https://redis.io/topics/internals-sds算法

這就是string的底層實現,更是redis對全部字符串數據的處理方式(SDS會被嵌套到別的數據結構裏使用)。segmentfault

2. 鏈表

Redis的鏈表在雙向鏈表上擴展了頭、尾節點、元素數等屬性。數組

2.1 源碼

ListNode節點數據結構:數據結構

typedef  struct listNode{
       //前置節點
       struct listNode *prev;
       //後置節點
       struct listNode *next;
       //節點的值
       void *value;  
}listNode

鏈表數據結構:函數

typedef struct list{
     //表頭節點
     listNode *head;
     //表尾節點
     listNode *tail;
     //鏈表所包含的節點數量
     unsigned long len;
     //節點值複製函數
     void (*free) (void *ptr);
     //節點值釋放函數
     void (*free) (void *ptr);
     //節點值對比函數
     int (*match) (void *ptr,void *key);
}list;

從上面能夠看到,Redis的鏈表有這幾個特色:性能

  1. 能夠直接得到頭、尾節點。
  2. 常數時間複雜度獲得鏈表長度。
  3. 是雙向鏈表。

3. 字典(Hash)

Redis的Hash,就是在數組+鏈表的基礎上,進行了一些rehash優化等。

3.1 數據結構源碼

哈希表:

typedef struct dictht {
    // 哈希表數組
    dictEntry **table;
    // 哈希表大小
    unsigned long size;
    // 哈希表大小掩碼,用於計算索引值
    // 老是等於 size - 1
    unsigned long sizemask;
    // 該哈希表已有節點的數量
    unsigned long used;
} dictht;

Hash表節點:

typedef struct dictEntry {
    //
    void *key;
    //
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    // 指向下個哈希表節點,造成鏈表
    struct dictEntry *next;  // 單鏈表結構
} dictEntry;

字典:

typedef struct dict {
    // 類型特定函數
    dictType *type;
    // 私有數據
    void *privdata;
    // 哈希表
    dictht ht[2];
    // rehash 索引
    // 當 rehash 不在進行時,值爲 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
} dict;

能夠看出:

  1. Reids的Hash採用鏈地址法來處理衝突,而後它沒有使用紅黑樹優化。
  2. 哈希表節點採用單鏈表結構。
  3. rehash優化。

下面咱們講一下它的rehash優化。

3.2 rehash

當哈希表的鍵對泰國或者太少,就須要對哈希表的大小進行調整,redis是如何調整的呢?

  1. 咱們仔細能夠看到dict結構裏有個字段dictht ht[2]表明有兩個dictht數組。第一步就是爲ht[1]哈希表分配空間,大小取決於ht[0]當前使用的狀況。
  2. 將保存在ht[0]中的數據rehash(從新計算哈希值)到ht[1]上。
  3. 當ht[0]中全部鍵值對都遷移到ht[1]後,釋放ht[0],將ht[1]設置爲ht[0],並ht[1]初始化,爲下一次rehash作準備。

3.3 漸進式rehash

咱們在3.2中看到,redis處理rehash的流程,可是更細一點的講,它如何進行數據遷的呢?

這就涉及到了漸進式rehash,redis考慮到大量數據遷移帶來的cpu繁忙(可能致使一段時間內中止服務),因此採用了漸進式rehash的方案。步驟以下:

  1. 爲ht[1]分配空間,同時持有兩個哈希表(一個空表、一個有數據)。
  2. 維持一個技術器rehashidx,初始值0。
  3. 每次對字典增刪改查,會順帶將ht[0]中的數據遷移到ht[1],rehashidx++(注意:ht[0]中的數據是隻減不增的)。
  4. 直到rehash操做完成,rehashidx值設爲-1。

它的好處:採用分而治之的思想,將龐大的遷移工做量劃分到每一次CURD中,避免了服務繁忙。

4. 跳躍表

這個數據結構是我面試中見過最多的,它其實特別簡單。學過的人可能都知道,它和平衡樹性能很類似,但爲何不用平衡樹而用skipList呢?

4.1 skipList & AVL 之間的選擇

  1. 從算法實現難度上來比較,skiplist比平衡樹要簡單得多。
  2. 平衡樹的插入和刪除操做可能引起子樹的調整,邏輯複雜,而skiplist的插入和刪除只須要修改相鄰節點的指針,操做簡單又快速。
  3. 查找單個key,skiplist和平衡樹的時間複雜度都爲O(log n),大致至關。
  4. 在作範圍查找的時候,平衡樹比skiplist操做要複雜。
  5. skiplist和各類平衡樹(如AVL、紅黑樹等)的元素是有序排列的。

能夠看到,skipList中的元素是有序的,因此跳躍表在redis中用在有序集合鍵、集羣節點內部數據結構

4.2 源碼

跳躍表節點:

typedef struct zskiplistNode {
 
    // 後退指針
    struct zskiplistNode *backward;
 
    // 分值
    double score;
 
    // 成員對象
    robj *obj;
 
    //
    struct zskiplistLevel {
 
        // 前進指針
        struct zskiplistNode *forward;
 
        // 跨度
        unsigned int span;
 
    } level[];
 
} zskiplistNode;

跳躍表:

typedef struct zskiplist {
 
    // 表頭節點和表尾節點
    struct zskiplistNode *header, *tail;
 
    // 表中節點的數量
    unsigned long length;
 
    // 表中層數最大的節點的層數
    int level;
 
} zskiplist;

它有幾個概念:

4.2.1 層(level[])

層,也就是level[]字段,層的數量越多,訪問節點速度越快。(由於它至關因而索引,層數越多,它索引就越細,就能很快找到索引值)

4.2.2 前進指針(forward)

層中有一個forward字段,用於從表頭向表尾方向訪問。

4.2.3 跨度(span)

用於記錄兩個節點之間的距離

4.2.4 後退指針(backward)

用於從表尾向表頭方向訪問。

案例

level0    1---------->5
level1    1---->3---->5
level2    1->2->3->4->5->6->7->8

好比我要找鍵爲6的元素,在level0中直接定位到5,而後再日後走一個元素就找到了。

5. 整數集合(intset)

Reids對整數存儲專門做了優化,intset就是redis用於保存整數值的集合數據結構。當一個結合中只包含整數元素,redis就會用這個來存儲。

127.0.0.1:6379[2]> sadd number 1 2 3 4 5 6
(integer) 6
127.0.0.1:6379[2]> object encoding number
"intset"

源碼

intset數據結構:

typedef struct intset {
 
    // 編碼方式
    uint32_t encoding;
 
    // 集合包含的元素數量
    uint32_t length;
 
    // 保存元素的數組
    int8_t contents[];
 
} intset;

你確定很好奇編碼方式(encoding)字段是幹嗎用的呢?

  • 若是 encoding 屬性的值爲 INTSET_ENC_INT16 , 那麼 contents 就是一個 int16_t 類型的數組, 數組裏的每一個項都是一個 int16_t 類型的整數值 (最小值爲 -32,768 ,最大值爲 32,767 )。
  • 若是 encoding 屬性的值爲 INTSET_ENC_INT32 , 那麼 contents 就是一個 int32_t 類型的數組, 數組裏的每一個項都是一個 int32_t 類型的整數值 (最小值爲 -2,147,483,648 ,最大值爲 2,147,483,647 )。
  • 若是 encoding 屬性的值爲 INTSET_ENC_INT64 , 那麼 contents 就是一個 int64_t 類型的數組, 數組裏的每一個項都是一個 int64_t 類型的整數值 (最小值爲 -9,223,372,036,854,775,808 ,最大值爲 9,223,372,036,854,775,807 )。

說白了就是根據contents字段來判斷用哪一個int類型更好,也就是對int存儲做了優化。

說到優化,那redis如何做的呢?就涉及到了升級。

5.1 encoding升級

若是咱們有個Int16類型的整數集合,如今要將65535(int32)加進這個集合,int16是存儲不下的,因此就要對整數集合進行升級。

它是怎麼升級的呢(過程)?

假如如今有2個int16的元素:1和2,新加入1個int32位的元素65535。

  1. 內存重分配,新加入後應該是3個元素,因此分配3*32-1=95位。
  2. 選擇最大的數65535, 放到(95-32+1, 95)位這個內存段中,而後2放到(95-32-32+1+1, 95-32)位...依次類推。
升級的好處是什麼呢?
  1. 提升了整數集合的靈活性。
  2. 儘量節約內存(能用小的就不用大的)。
5.2 不支持降級

按照上面的例子,若是我把65535又刪掉,encoding會不會又回到Int16呢,答案是不會的。官方沒有給出理由,我以爲應該是下降性能消耗吧,畢竟調整一次是O(N)的時間複雜度。

6. 壓縮列表(ziplist)

ziplist是redis爲了節約內存而開發的順序型數據結構。它被用在列表鍵和哈希鍵中。通常用於小數據存儲。

引用https://segmentfault.com/a/1190000016901154中的兩個圖:

6.1 源碼

ziplist沒有明肯定義結構體,這裏只做大概的演示。

typedef struct entry {
     /*前一個元素長度須要空間和前一個元素長度*/
    unsigned int prevlengh;
     /*元素內容編碼*/
    unsigned char encoding;
     /*元素實際內容*/
    unsigned char *data;
}zlentry;
typedef struct ziplist{
     /*ziplist分配的內存大小*/
     uint32_t zlbytes;
     /*達到尾部的偏移量*/
     uint32_t zltail;
     /*存儲元素實體個數*/
     uint16_t zllen;
     /*存儲內容實體元素*/
     unsigned char* entry[];
     /*尾部標識*/
     unsigned char zlend;
}ziplist;

第一次看可能會特別矇蔽,你細細的把我這段話看完就必定能懂。

Entry的分析

entry結構體裏面有三個重要的字段:

  1. previous_entry_length: 這個字段記錄了ziplist中前一個節點的長度,什麼意思?就是說經過該屬性能夠進行指針運算達到表尾向表頭遍歷,這個字段還有一個大問題下面會講。
  2. encoding:記錄了數據類型(int16? string?)和長度。
  3. data/content: 記錄數據。
連鎖更新
previous_entry_length字段的分析

上面有說到,previous_entry_length這個字段存放上個節點的長度,那默認長度給分配多少呢?redis是這樣分的,若是前節點長度小於254,就分配1字節,大於的話分配5字節,那問題就來了。

若是前一個節點的長度剛開始小於254字節,後來大於254,那不就存放不下了嗎? 這就涉及到previous_entry_length的更新,可是改一個確定不行阿,後面的節點內存信息都須要改。因此就須要從新分配內存,而後連鎖更新包括該受影響節點後面的全部節點。

除了增長新節點會引起連鎖更新、刪除節點也會觸發。

7. 快速列表(quicklist)

一個由ziplist組成的雙向鏈表。可是一個quicklist能夠有多個quicklist節點,它很像B樹的存儲方式。是在redis3.2版本中新加的數據結構,用在列表的底層實現。

結構體源碼

表頭結構:

typedef struct quicklist {
    //指向頭部(最左邊)quicklist節點的指針
    quicklistNode *head;
 
    //指向尾部(最右邊)quicklist節點的指針
    quicklistNode *tail;
 
    //ziplist中的entry節點計數器
    unsigned long count;        /* total count of all entries in all ziplists */
 
    //quicklist的quicklistNode節點計數器
    unsigned int len;           /* number of quicklistNodes */
 
    //保存ziplist的大小,配置文件設定,佔16bits
    int fill : 16;              /* fill factor for individual nodes */
 
    //保存壓縮程度值,配置文件設定,佔16bits,0表示不壓縮
    unsigned int compress : 16; /* depth of end nodes not to compress;0=off */
} quicklist;

quicklist節點結構:

typedef struct quicklistNode {
    struct quicklistNode *prev;     //前驅節點指針
    struct quicklistNode *next;     //後繼節點指針
 
    //不設置壓縮數據參數recompress時指向一個ziplist結構
    //設置壓縮數據參數recompress指向quicklistLZF結構
    unsigned char *zl;
 
    //壓縮列表ziplist的總長度
    unsigned int sz;                  /* ziplist size in bytes */
 
    //ziplist中包的節點數,佔16 bits長度
    unsigned int count : 16;          /* count of items in ziplist */
 
    //表示是否採用了LZF壓縮算法壓縮quicklist節點,1表示壓縮過,2表示沒壓縮,佔2 bits長度
    unsigned int encoding : 2;        /* RAW==1 or LZF==2 */
 
    //表示一個quicklistNode節點是否採用ziplist結構保存數據,2表示壓縮了,1表示沒壓縮,默認是2,佔2bits長度
    unsigned int container : 2;       /* NONE==1 or ZIPLIST==2 */
 
    //標記quicklist節點的ziplist以前是否被解壓縮過,佔1bit長度
    //若是recompress爲1,則等待被再次壓縮
    unsigned int recompress : 1; /* was this node previous compressed? */
 
    //測試時使用
    unsigned int attempted_compress : 1; /* node can't compress; too small */
 
    //額外擴展位,佔10bits長度
    unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;
相關配置

在redis.conf中的ADVANCED CONFIG部分:

list-max-ziplist-size -2
list-compress-depth 0
list-max-ziplist-size參數

咱們來詳細解釋一下list-max-ziplist-size這個參數的含義。它能夠取正值,也能夠取負值。

當取正值的時候,表示按照數據項個數來限定每一個quicklist節點上的ziplist長度。好比,當這個參數配置成5的時候,表示每一個quicklist節點的ziplist最多包含5個數據項。

當取負值的時候,表示按照佔用字節數來限定每一個quicklist節點上的ziplist長度。這時,它只能取-1到-5這五個值,每一個值含義以下:

-5: 每一個quicklist節點上的ziplist大小不能超過64 Kb。(注:1kb => 1024 bytes)

-4: 每一個quicklist節點上的ziplist大小不能超過32 Kb。

-3: 每一個quicklist節點上的ziplist大小不能超過16 Kb。

-2: 每一個quicklist節點上的ziplist大小不能超過8 Kb。(-2是Redis給出的默認值)

list-compress-depth參數

這個參數表示一個quicklist兩端不被壓縮的節點個數。注:這裏的節點個數是指quicklist雙向鏈表的節點個數,而不是指ziplist裏面的數據項個數。實際上,一個quicklist節點上的ziplist,若是被壓縮,就是總體被壓縮的。

參數list-compress-depth的取值含義以下:

0: 是個特殊值,表示都不壓縮。這是Redis的默認值。 1: 表示quicklist兩端各有1個節點不壓縮,中間的節點壓縮。 2: 表示quicklist兩端各有2個節點不壓縮,中間的節點壓縮。 3: 表示quicklist兩端各有3個節點不壓縮,中間的節點壓縮。 依此類推…

Redis對於quicklist內部節點的壓縮算法,採用的LZF——一種無損壓縮算法。

相關文章
相關標籤/搜索