探索Redis設計與實現5：Redis內部數據結構詳解——quicklist

本文轉自互聯網html

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到個人倉庫裏查看node

https://github.com/h2pl/Java-Tutorialgit

喜歡的話麻煩點下Star哈github

文章首發於個人我的博客：面試

www.how2playlife.comredis

本文是微信公衆號【Java技術江湖】的《探索Redis設計與實現》其中一篇，本文部份內容來源於網絡，爲了把本文主題講得清晰透徹，也整合了不少我認爲不錯的技術博客內容，引用其中了一些比較好的博客文章，若有侵權，請聯繫做者。算法

該系列博文會告訴你如何從入門到進階，Redis基本的使用方法，Redis的基本數據結構，以及一些進階的使用方法，同時也須要進一步瞭解Redis的底層數據結構，再接着，還會帶來Redis主從複製、集羣、分佈式鎖等方面的相關內容，以及做爲緩存的一些使用方法和注意事項，以便讓你更完整地瞭解整個Redis相關的技術體系，造成本身的知識框架。數組

若是對本系列文章有什麼建議，或者是有什麼疑問的話，也能夠關注公衆號【Java技術江湖】聯繫做者，歡迎你參與本系列博文的創做和修訂。緩存

微信

本文是《Redis內部數據結構詳解》系列的第五篇。在本文中，咱們介紹一個Redis內部數據結構——quicklist。Redis對外暴露的list數據類型，它底層實現所依賴的內部數據結構就是quicklist。

咱們在討論中還會涉及到兩個Redis配置（在redis.conf中的ADVANCED CONFIG部分）：

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

咱們在討論中會詳細解釋這兩個配置的含義。

注：本文討論的quicklist實現基於Redis源碼的3.2分支。

quicklist概述

Redis對外暴露的上層list數據類型，常常被用做隊列使用。好比它支持的以下一些操做：

lpush: 在左側（即列表頭部）插入數據。
rpop: 在右側（即列表尾部）刪除數據。
rpush: 在右側（即列表尾部）插入數據。
lpop: 在左側（即列表頭部）刪除數據。

這些操做都是O(1)時間複雜度的。

固然，list也支持在任意中間位置的存取操做，好比lindex和linsert，但它們都須要對list進行遍歷，因此時間複雜度較高，爲O(N)。

概況起來，list具備這樣的一些特色：它是一個能維持數據項前後順序的列表（各個數據項的前後順序由插入位置決定），便於在表的兩端追加和刪除數據，而對於中間位置的存取具備O(N)的時間複雜度。這不正是一個雙向鏈表所具備的特色嗎？

list的內部實現quicklist正是一個雙向鏈表。在quicklist.c的文件頭部註釋中，是這樣描述quicklist的：

A doubly linked list of ziplists

它確實是一個雙向鏈表，並且是一個ziplist的雙向鏈表。

這是什麼意思呢？

咱們知道，雙向鏈表是由多個節點（Node）組成的。這個描述的意思是：quicklist的每一個節點都是一個ziplist。ziplist咱們已經在上一篇介紹過。

ziplist自己也是一個能維持數據項前後順序的列表（按插入位置），並且是一個內存緊縮的列表（各個數據項在內存上先後相鄰）。好比，一個包含3個節點的quicklist，若是每一個節點的ziplist又包含4個數據項，那麼對外表現上，這個list就總共包含12個數據項。

quicklist的結構爲何這樣設計呢？總結起來，大概又是一個空間和時間的折中：

雙向鏈表便於在表的兩端進行push和pop操做，可是它的內存開銷比較大。首先，它在每一個節點上除了要保存數據以外，還要額外保存兩個指針；其次，雙向鏈表的各個節點是單獨的內存塊，地址不連續，節點多了容易產生內存碎片。
ziplist因爲是一整塊連續內存，因此存儲效率很高。可是，它不利於修改操做，每次數據變更都會引起一次內存的realloc。特別是當ziplist長度很長的時候，一次realloc可能會致使大批量的數據拷貝，進一步下降性能。

因而，結合了雙向鏈表和ziplist的優勢，quicklist就應運而生了。

不過，這也帶來了一個新問題：到底一個quicklist節點包含多長的ziplist合適呢？好比，一樣是存儲12個數據項，既能夠是一個quicklist包含3個節點，而每一個節點的ziplist又包含4個數據項，也能夠是一個quicklist包含6個節點，而每一個節點的ziplist又包含2個數據項。

這又是一個須要找平衡點的難題。咱們只從存儲效率上分析一下：

每一個quicklist節點上的ziplist越短，則內存碎片越多。內存碎片多了，有可能在內存中產生不少沒法被利用的小碎片，從而下降存儲效率。這種狀況的極端是每一個quicklist節點上的ziplist只包含一個數據項，這就蛻化成一個普通的雙向鏈表了。
每一個quicklist節點上的ziplist越長，則爲ziplist分配大塊連續內存空間的難度就越大。有可能出現內存裏有不少小塊的空閒空間（它們加起來不少），但卻找不到一塊足夠大的空閒空間分配給ziplist的狀況。這一樣會下降存儲效率。這種狀況的極端是整個quicklist只有一個節點，全部的數據項都分配在這僅有的一個節點的ziplist裏面。這其實蛻化成一個ziplist了。

可見，一個quicklist節點上的ziplist要保持一個合理的長度。那到底多長合理呢？這可能取決於具體應用場景。實際上，Redis提供了一個配置參數list-max-ziplist-size，就是爲了讓使用者能夠來根據本身的狀況進行調整。

list-max-ziplist-size -2

咱們來詳細解釋一下這個參數的含義。它能夠取正值，也能夠取負值。

當取正值的時候，表示按照數據項個數來限定每一個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給出的默認值）
-1: 每一個quicklist節點上的ziplist大小不能超過4 Kb。

另外，list的設計目標是可以用來存儲很長的數據列表的。好比，Redis官網給出的這個教程：Writing a simple Twitter clone with PHP and Redis，就是使用list來存儲相似Twitter的timeline數據。

當列表很長的時候，最容易被訪問的極可能是兩端的數據，中間的數據被訪問的頻率比較低（訪問起來性能也很低）。若是應用場景符合這個特色，那麼list還提供了一個選項，可以把中間的數據節點進行壓縮，從而進一步節省內存空間。Redis的配置參數list-compress-depth就是用來完成這個設置的。

list-compress-depth 0

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

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

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

因爲0是個特殊值，很容易看出quicklist的頭節點和尾節點老是不被壓縮的，以便於在表的兩端進行快速存取。

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

quicklist的數據結構定義

quicklist相關的數據結構定義能夠在quicklist.h中找到：

typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;
    unsigned int sz;             /* ziplist size in bytes */
    unsigned int count : 16;     /* count of items in ziplist */
    unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
    unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
    unsigned int recompress : 1; /* was this node previous compressed? */
    unsigned int attempted_compress : 1; /* node can't compress; too small */
    unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;

typedef struct quicklistLZF {
    unsigned int sz; /* LZF size in bytes*/
    char compressed[];
} quicklistLZF;

typedef struct quicklist {
    quicklistNode *head;
    quicklistNode *tail;
    unsigned long count;        /* total count of all entries in all ziplists */
    unsigned int len;           /* number of quicklistNodes */
    int fill : 16;              /* fill factor for individual nodes */
    unsigned int compress : 16; /* depth of end nodes not to compress;0=off */
} quicklist;

quicklistNode結構表明quicklist的一個節點，其中各個字段的含義以下：

prev: 指向鏈表前一個節點的指針。
next: 指向鏈表後一個節點的指針。
zl: 數據指針。若是當前節點的數據沒有壓縮，那麼它指向一個ziplist結構；不然，它指向一個quicklistLZF結構。
sz: 表示zl指向的ziplist的總大小（包括zlbytes, zltail, zllen, zlend和各個數據項）。須要注意的是：若是ziplist被壓縮了，那麼這個sz的值仍然是壓縮前的ziplist大小。
count: 表示ziplist裏面包含的數據項個數。這個字段只有16bit。稍後咱們會一塊兒計算一下這16bit是否夠用。
encoding: 表示ziplist是否壓縮了（以及用了哪一個壓縮算法）。目前只有兩種取值：2表示被壓縮了（並且用的是LZF壓縮算法），1表示沒有壓縮。
container: 是一個預留字段。原本設計是用來代表一個quicklist節點下面是直接存數據，仍是使用ziplist存數據，或者用其它的結構來存數據（用做一個數據容器，因此叫container）。可是，在目前的實現中，這個值是一個固定的值2，表示使用ziplist做爲數據容器。
recompress: 當咱們使用相似lindex這樣的命令查看了某一項原本壓縮的數據時，須要把數據暫時解壓，這時就設置recompress=1作一個標記，等有機會再把數據從新壓縮。
attempted_compress: 這個值只對Redis的自動化測試程序有用。咱們不用管它。
extra: 其它擴展字段。目前Redis的實現裏也沒用上。

quicklistLZF結構表示一個被壓縮過的ziplist。其中：

sz: 表示壓縮後的ziplist大小。
compressed: 是個柔性數組（flexible array member），存放壓縮後的ziplist字節數組。

真正表示quicklist的數據結構是同名的quicklist這個struct：

head: 指向頭節點（左側第一個節點）的指針。
tail: 指向尾節點（右側第一個節點）的指針。
count: 全部ziplist數據項的個數總和。
len: quicklist節點的個數。
fill: 16bit，ziplist大小設置，存放list-max-ziplist-size參數的值。
compress: 16bit，節點壓縮深度設置，存放list-compress-depth參數的值。

上圖是一個quicklist的結構圖舉例。圖中例子對應的ziplist大小配置和節點壓縮深度配置，以下：

list-max-ziplist-size 3
list-compress-depth 2

這個例子中咱們須要注意的幾點是：

兩端各有2個橙黃色的節點，是沒有被壓縮的。它們的數據指針zl指向真正的ziplist。中間的其它節點是被壓縮過的，它們的數據指針zl指向被壓縮後的ziplist結構，即一個quicklistLZF結構。
左側頭節點上的ziplist裏有2項數據，右側尾節點上的ziplist裏有1項數據，中間其它節點上的ziplist裏都有3項數據（包括壓縮的節點內部）。這表示在表的兩端執行過屢次push和pop操做後的一個狀態。

如今咱們來大概計算一下quicklistNode結構中的count字段這16bit是否夠用。

咱們已經知道，ziplist大小受到list-max-ziplist-size參數的限制。按照正值和負值有兩種狀況：

當這個參數取正值的時候，就是剛好表示一個quicklistNode結構中zl所指向的ziplist所包含的數據項的最大值。list-max-ziplist-size參數是由quicklist結構的fill字段來存儲的，而fill字段是16bit，因此它所能表達的值可以用16bit來表示。
當這個參數取負值的時候，可以表示的ziplist最大長度是64 Kb。而ziplist中每個數據項，最少須要2個字節來表示：1個字節的prevrawlen，1個字節的data（len字段和data合二爲一；詳見上一篇）。因此，ziplist中數據項的個數不會超過32 K，用16bit來表達足夠了。

實際上，在目前的quicklist的實現中，ziplist的大小還會受到另外的限制，根本不會達到這裏所分析的最大值。

下面進入代碼分析階段。

quicklist的建立

當咱們使用lpush或rpush命令第一次向一個不存在的list裏面插入數據的時候，Redis會首先調用quicklistCreate接口建立一個空的quicklist。

quicklist *quicklistCreate(void) {
    struct quicklist *quicklist;

    quicklist = zmalloc(sizeof(*quicklist));
    quicklist->head = quicklist->tail = NULL;
    quicklist->len = 0;
    quicklist->count = 0;
    quicklist->compress = 0;
    quicklist->fill = -2;
    return quicklist;
}

在不少介紹數據結構的書上，實現雙向鏈表的時候常常會多增長一個空餘的頭節點，主要是爲了插入和刪除操做的方便。從上面quicklistCreate的代碼能夠看出，quicklist是一個不包含空餘頭節點的雙向鏈表（head和tail都初始化爲NULL）。

quicklist的push操做

quicklist的push操做是調用quicklistPush來實現的。

void quicklistPush(quicklist *quicklist, void *value, const size_t sz,
                   int where) {
    if (where == QUICKLIST_HEAD) {
        quicklistPushHead(quicklist, value, sz);
    } else if (where == QUICKLIST_TAIL) {
        quicklistPushTail(quicklist, value, sz);
    }
}

/* Add new entry to head node of quicklist.
 *
 * Returns 0 if used existing head.
 * Returns 1 if new head created. */
int quicklistPushHead(quicklist *quicklist, void *value, size_t sz) {
    quicklistNode *orig_head = quicklist->head;
    if (likely(
            _quicklistNodeAllowInsert(quicklist->head, quicklist->fill, sz))) {
        quicklist->head->zl =
            ziplistPush(quicklist->head->zl, value, sz, ZIPLIST_HEAD);
        quicklistNodeUpdateSz(quicklist->head);
    } else {
        quicklistNode *node = quicklistCreateNode();
        node->zl = ziplistPush(ziplistNew(), value, sz, ZIPLIST_HEAD);

        quicklistNodeUpdateSz(node);
        _quicklistInsertNodeBefore(quicklist, quicklist->head, node);
    }
    quicklist->count++;
    quicklist->head->count++;
    return (orig_head != quicklist->head);
}

/* Add new entry to tail node of quicklist.
 *
 * Returns 0 if used existing tail.
 * Returns 1 if new tail created. */
int quicklistPushTail(quicklist *quicklist, void *value, size_t sz) {
    quicklistNode *orig_tail = quicklist->tail;
    if (likely(
            _quicklistNodeAllowInsert(quicklist->tail, quicklist->fill, sz))) {
        quicklist->tail->zl =
            ziplistPush(quicklist->tail->zl, value, sz, ZIPLIST_TAIL);
        quicklistNodeUpdateSz(quicklist->tail);
    } else {
        quicklistNode *node = quicklistCreateNode();
        node->zl = ziplistPush(ziplistNew(), value, sz, ZIPLIST_TAIL);

        quicklistNodeUpdateSz(node);
        _quicklistInsertNodeAfter(quicklist, quicklist->tail, node);
    }
    quicklist->count++;
    quicklist->tail->count++;
    return (orig_tail != quicklist->tail);
}

不論是在頭部仍是尾部插入數據，都包含兩種狀況：

若是頭節點（或尾節點）上ziplist大小沒有超過限制（即_quicklistNodeAllowInsert返回1），那麼新數據被直接插入到ziplist中（調用ziplistPush）。
若是頭節點（或尾節點）上ziplist太大了，那麼新建立一個quicklistNode節點（對應地也會新建立一個ziplist），而後把這個新建立的節點插入到quicklist雙向鏈表中（調用_quicklistInsertNodeAfter）。

在_quicklistInsertNodeAfter的實現中，還會根據list-compress-depth的配置將裏面的節點進行壓縮。它的實現比較繁瑣，咱們這裏就不展開討論了。

quicklist的其它操做

quicklist的操做較多，且實現細節都比較繁雜，這裏就不一一分析源碼了，咱們簡單介紹一些比較重要的操做。

quicklist的pop操做是調用quicklistPopCustom來實現的。quicklistPopCustom的實現過程基本上跟quicklistPush相反，先從頭部或尾部節點的ziplist中把對應的數據項刪除，若是在刪除後ziplist爲空了，那麼對應的頭部或尾部節點也要刪除。刪除後還可能涉及到裏面節點的解壓縮問題。

quicklist不只實現了從頭部或尾部插入，也實現了從任意指定的位置插入。quicklistInsertAfter和quicklistInsertBefore就是分別在指定位置後面和前面插入數據項。這種在任意指定位置插入數據的操做，狀況比較複雜，有衆多的邏輯分支。

當插入位置所在的ziplist大小沒有超過限制時，直接插入到ziplist中就行了；
當插入位置所在的ziplist大小超過了限制，但插入的位置位於ziplist兩端，而且相鄰的quicklist鏈表節點的ziplist大小沒有超過限制，那麼就轉而插入到相鄰的那個quicklist鏈表節點的ziplist中；
當插入位置所在的ziplist大小超過了限制，但插入的位置位於ziplist兩端，而且相鄰的quicklist鏈表節點的ziplist大小也超過限制，這時須要新建立一個quicklist鏈表節點插入。
對於插入位置所在的ziplist大小超過了限制的其它狀況（主要對應於在ziplist中間插入數據的狀況），則須要把當前ziplist分裂爲兩個節點，而後再其中一個節點上插入數據。

quicklistSetOptions用於設置ziplist大小配置參數（list-max-ziplist-size）和節點壓縮深度配置參數（list-compress-depth）。代碼比較簡單，就是將相應的值分別設置給quicklist結構的fill字段和compress字段。

下一篇咱們將介紹skiplist和它所支撐的Redis數據類型sorted set，敬請期待。

原創文章，轉載請註明出處，幷包含下面的二維碼！不然拒絕轉載！ 本文連接：http://zhangtielei.com/posts/blog-redis-quicklist.html