redis zset底層實現原理

一.Zset編碼的選擇

 

 

 

1.有序集合對象的編碼可以是ziplist或者skiplist。同時滿足以下條件時使用ziplist編碼：

• 元素數量小於128個
• 所有member的長度都小於64字節
• 其他：
• 不能滿足上面兩個條件的使用 skiplist 編碼。以上兩個條件也可以通過Redis配置文件zset-max-ziplist-entries 選項和 zset-max-ziplist-value 進行修改
• 對於一個 REDIS_ENCODING_ZIPLIST 編碼的 Zset， 只要滿足以上任一條件， 則會被轉換為 REDIS_ENCODING_SKIPLIST 編碼

2.zset操作命令

zadd(key, score, member)：向名稱為key的zset中添加元素member，score用於排序。如果該元素已經存在，則根據score更新該元素的順序。
zrem(key, member) ：刪除名稱為key的zset中的元素member
zincrby(key, increment, member) ：如果在名稱為key的zset中已經存在元素member，則該元素的score增加increment；否則向集合中添加該元素，其score的值為increment
zrank(key, member) ：返回名稱為key的zset（元素已按score從小到大排序）中member元素的rank（即index，從0開始），若沒有member元素，返回“nil”
zrevrank(key, member) ：返回名稱為key的zset（元素已按score從大到小排序）中member元素的rank（即index，從0開始），若沒有member元素，返回“nil”
zrange(key, start, end)：返回名稱為key的zset（元素已按score從小到大排序）中的index從start到end的所有元素
zrevrange(key, start, end)：返回名稱為key的zset（元素已按score從大到小排序）中的index從start到end的所有元素
zrangebyscore(key, min, max)：返回名稱為key的zset中score >= min且score <= max的所有元素 zcard(key)：返回名稱為key的zset的基數
zscore(key, element)：返回名稱為key的zset中元素element的score zremrangebyrank(key, min, max)：刪除名稱為key的zset中rank >= min且rank <= max的所有元素 zremrangebyscore(key, min, max) ：刪除名稱為key的zset中score >= min且score <= max的所有元素

二.ziplist

1. 介紹

ziplist 編碼的 Zset 使用緊挨在一起的壓縮列表節點來保存，第一個節點保存 member，第二個保存 score。ziplist 內的集合元素按 score 從小到大排序，其實質是一個雙向鏈表。雖然元素是按 score 有序排序的， 但對 ziplist 的節點指針只能線性地移動，所以在 REDIS_ENCODING_ZIPLIST 編碼的 Zset 中， 查找某個給定元素的復雜度為 O(N)O(N)。

2.

//操作
ZADD price 8.5 apple 5.0 banana 6.0 cherry

//存儲順序

 

 

 

3. 從以上的布局中，我們可以看到ziplist內存數據結構，由如下5部分構成：

 

 

各個部分在內存上是前后相鄰的並連續的，每一部分作用如下：

• zlbytes： 存儲一個無符號整數，固定四個字節長度（32bit），用於存儲壓縮列表所占用的字節（也包括<zlbytes>本身占用的4個字節），當重新分配內存的時候使用，不需要遍歷整個列表來計算內存大小。

• zltail： 存儲一個無符號整數，固定四個字節長度（32bit），表示ziplist表中最后一項（entry）在ziplist中的偏移字節數。<zltail>的存在，使得我們可以很方便地找到最后一項（不用遍歷整個ziplist），從而可以在ziplist尾端快速地執行push或pop操作。

• zllen： 壓縮列表包含的節點個數，固定兩個字節長度（16bit）， 表示ziplist中數據項（entry）的個數。由於zllen字段只有16bit，所以可以表達的最大值為2^16-1。

  注意點：如果ziplist中數據項個數超過了16bit能表達的最大值，ziplist仍然可以表示。ziplist是如何做到的？

  如果<zllen>小於等於2^16-2（也就是不等於2^16-1），那么<zllen>就表示ziplist中數據項的個數；否則，也就是<zllen>等於16bit全為1的情況，那么<zllen>就不表示數據項個數了，這時候要想知道ziplist中數據項總數，那么必須對ziplist從頭到尾遍歷各個數據項，才能計數出來。

• entry，表示真正存放數據的數據項，長度不定。一個數據項（entry）也有它自己的內部結構。

• zlend， ziplist最后1個字節，值固定等於255，其是一個結束標記。

 

 

三.skiplist

1.介紹

 

skiplist 編碼的 Zset 底層為一個被稱為 zset 的結構體，這個結構體中包含一個字典和一個跳躍表。跳躍表按 score 從小到大保存所有集合元素，查找時間復雜度為平均 

O(logN)O(logN)，最壞 O(N
O(N) 。字典則保存着從 member 到 score 的映射，這樣就可以用 O(1)O(1)​ 的復雜度來查找 member 對應的 score 值。雖然同時使用兩種結構，但它們會通過指針來共享相同元素的 member 和 score，因此不會浪費額外的內存。

 

2.詳解

 

跳表(skip List)是一種隨機化的數據結構，基於並聯的鏈表，實現簡單，插入、刪除、查找的復雜度均為O(logN)。簡單說來跳表也是鏈表的一種，只不過它在鏈表的基礎上增加了跳躍功能，正是這個跳躍的功能，使得在查找元素時，跳表能夠提供O(logN)的時間復雜度。

先來看一個有序鏈表，如下圖（最左側的灰色節點表示一個空的頭結點）：

在這樣一個鏈表中，如果我們要查找某個數據，那么需要從頭開始逐個進行比較，直到找到包含數據的那個節點，或者找到第一個比給定數據大的節點為止（沒找到）。也就是說，時間復雜度為O(n)。同樣，當我們要插入新數據的時候，也要經歷同樣的查找過程，從而確定插入位置。

假如我們每相鄰兩個節點增加一個指針，讓指針指向下下個節點，如下圖：

這樣所有新增加的指針連成了一個新的鏈表，但它包含的節點個數只有原來的一半（上圖中是7, 19, 26）。現在當我們想查找數據的時候，可以先沿着這個新鏈表進行查找。當碰到比待查數據大的節點時，再回到原來的鏈表中進行查找。比如，我們想查找23，查找的路徑是沿着下圖中標紅的指針所指向的方向進行的：

• 23首先和7比較，再和19比較，比它們都大，繼續向后比較。
• 但23和26比較的時候，比26要小，因此回到下面的鏈表（原鏈表），與22比較。
• 23比22要大，沿下面的指針繼續向后和26比較。23比26小，說明待查數據23在原鏈表中不存在，而且它的插入位置應該在22和26之間。

在這個查找過程中，由於新增加的指針，我們不再需要與鏈表中每個節點逐個進行比較了。需要比較的節點數大概只有原來的一半。

利用同樣的方式，我們可以在上層新產生的鏈表上，繼續為每相鄰的兩個節點增加一個指針，從而產生第三層鏈表。如下圖：

在這個新的三層鏈表結構上，如果我們還是查找23，那么沿着最上層鏈表首先要比較的是19，發現23比19大，接下來我們就知道只需要到19的后面去繼續查找，從而一下子跳過了19前面的所有節點。可以想象，當鏈表足夠長的時候，這種多層鏈表的查找方式能讓我們跳過很多下層節點，大大加快查找的速度。

skiplist正是受這種多層鏈表的想法的啟發而設計出來的。實際上，按照上面生成鏈表的方式，上面每一層鏈表的節點個數，是下面一層的節點個數的一半，這樣查找過程就非常類似於一個二分查找，使得查找的時間復雜度可以降低到O(log n)。但是，這種方法在插入數據的時候有很大的問題。新插入一個節點之后，就會打亂上下相鄰兩層鏈表上節點個數嚴格的2:1的對應關系。如果要維持這種對應關系，就必須把新插入的節點后面的所有節點（也包括新插入的節點）重新進行調整，這會讓時間復雜度重新蛻化成O(n)。刪除數據也有同樣的問題。

skiplist為了避免這一問題，它不要求上下相鄰兩層鏈表之間的節點個數有嚴格的對應關系，而是為每個節點隨機出一個層數(level)。比如，一個節點隨機出的層數是3，那么就把它鏈入到第1層到第3層這三層鏈表中。為了表達清楚，下圖展示了如何通過一步步的插入操作從而形成一個skiplist的過程：

從上面skiplist的創建和插入過程可以看出，每一個節點的層數（level）是隨機出來的，而且新插入一個節點不會影響其它節點的層數。因此，插入操作只需要修改插入節點前后的指針，而不需要對很多節點都進行調整。這就降低了插入操作的復雜度。實際上，這是skiplist的一個很重要的特性，這讓它在插入性能上明顯優於平衡樹的方案。這在后面我們還會提到。

skiplist，指的就是除了最下面第1層鏈表之外，它會產生若干層稀疏的鏈表，這些鏈表里面的指針故意跳過了一些節點（而且越高層的鏈表跳過的節點越多）。這就使得我們在查找數據的時候能夠先在高層的鏈表中進行查找，然后逐層降低，最終降到第1層鏈表來精確地確定數據位置。在這個過程中，我們跳過了一些節點，從而也就加快了查找速度。

剛剛創建的這個skiplist總共包含4層鏈表，現在假設我們在它里面依然查找23，下圖給出了查找路徑：

需要注意的是，前面演示的各個節點的插入過程，實際上在插入之前也要先經歷一個類似的查找過程，在確定插入位置后，再完成插入操作。

實際應用中的skiplist每個節點應該包含key和value兩部分。前面的描述中我們沒有具體區分key和value，但實際上列表中是按照key(score)進行排序的，查找過程也是根據key在比較。

執行插入操作時計算隨機數的過程，是一個很關鍵的過程，它對skiplist的統計特性有着很重要的影響。這並不是一個普通的服從均勻分布的隨機數，它的計算過程如下：

• 首先，每個節點肯定都有第1層指針（每個節點都在第1層鏈表里）。
• 如果一個節點有第i層(i>=1)指針（即節點已經在第1層到第i層鏈表中），那么它有第(i+1)層指針的概率為p。
• 節點最大的層數不允許超過一個最大值，記為MaxLevel。

這個計算隨機層數的偽碼如下所示：

1 2 3 4 5 6

randomLevel() level := 1 // random()返回一個[0...1)的隨機數 while random() < p and level < MaxLevel do level := level + 1 return level

randomLevel()的偽碼中包含兩個參數，一個是p，一個是MaxLevel。在Redis的skiplist實現中，這兩個參數的取值為：

1 2	p = 1/ 4 MaxLevel = 32

 

四.skiplist與平衡樹、哈希表的比較

• skiplist和各種平衡樹（如AVL、紅黑樹等）的元素是有序排列的，而哈希表不是有序的。因此，在哈希表上只能做單個key的查找，不適宜做范圍查找。所謂范圍查找，指的是查找那些大小在指定的兩個值之間的所有節點。
• 在做范圍查找的時候，平衡樹比skiplist操作要復雜。在平衡樹上，我們找到指定范圍的小值之后，還需要以中序遍歷的順序繼續尋找其它不超過大值的節點。如果不對平衡樹進行一定的改造，這里的中序遍歷並不容易實現。而在skiplist上進行范圍查找就非常簡單，只需要在找到小值之后，對第1層鏈表進行若干步的遍歷就可以實現。
• 平衡樹的插入和刪除操作可能引發子樹的調整，邏輯復雜，而skiplist的插入和刪除只需要修改相鄰節點的指針，操作簡單又快速。
• 從內存占用上來說，skiplist比平衡樹更靈活一些。一般來說，平衡樹每個節點包含2個指針（分別指向左右子樹），而skiplist每個節點包含的指針數目平均為1/(1-p)，具體取決於參數p的大小。如果像Redis里的實現一樣，取p=1/4，那么平均每個節點包含1.33個指針，比平衡樹更有優勢。
• 查找單個key，skiplist和平衡樹的時間復雜度都為O(log n)，大體相當；而哈希表在保持較低的哈希值沖突概率的前提下，查找時間復雜度接近O(1)，性能更高一些。所以我們平常使用的各種Map或dictionary結構，大都是基於哈希表實現的。
• 從算法實現難度上來比較，skiplist比平衡樹要簡單得多。

 

五.Redis中的skiplist實現

skiplist的數據結構定義：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

#define ZSKIPLIST_MAXLEVEL 32 #define ZSKIPLIST_P 0.25   typedef struct zskiplistNode { robj *obj; double score; struct zskiplistNode *backward; struct zskiplistLevel { struct zskiplistNode *forward; unsigned int span; } level[]; } zskiplistNode;   typedef struct zskiplist { struct zskiplistNode *header, *tail; unsigned long length; int level; } zskiplist;

簡單分析一下幾個查詢命令：

• zrevrank由數據查詢它對應的排名，這在前面介紹的skiplist中並不支持。
• zscore由數據查詢它對應的分數，這也不是skiplist所支持的。
• zrevrange根據一個排名范圍，查詢排名在這個范圍內的數據。這在前面介紹的skiplist中也不支持。
• zrevrangebyscore根據分數區間查詢數據集合，是一個skiplist所支持的典型的范圍查找（score相當於key，數據相當於value）。

實際上，Redis中sorted set的實現是這樣的：

• 當數據較少時，sorted set是由一個ziplist來實現的。
• 當數據多的時候，sorted set是由一個dict + 一個skiplist來實現的。簡單來講，dict用來查詢數據到分數的對應關系，而skiplist用來根據分數查詢數據（可能是范圍查找）。

看一下sorted set與skiplist的關系，：

• zscore的查詢，不是由skiplist來提供的，而是由那個dict來提供的。
• 為了支持排名(rank)，Redis里對skiplist做了擴展，使得根據排名能夠快速查到數據，或者根據分數查到數據之后，也同時很容易獲得排名。而且，根據排名的查找，時間復雜度也為O(log n)。
• zrevrange的查詢，是根據排名查數據，由擴展后的skiplist來提供。
• zrevrank是先在dict中由數據查到分數，再拿分數到skiplist中去查找，查到后也同時獲得了排名。

總結起來，Redis中的skiplist跟前面介紹的經典的skiplist相比，有如下不同：

• 分數(score)允許重復，即skiplist的key允許重復。這在最開始介紹的經典skiplist中是不允許的。
• 在比較時，不僅比較分數（相當於skiplist的key），還比較數據本身。在Redis的skiplist實現中，數據本身的內容唯一標識這份數據，而不是由key來唯一標識。另外，當多個元素分數相同的時候，還需要根據數據內容來進字典排序。
• 第1層鏈表不是一個單向鏈表，而是一個雙向鏈表。這是為了方便以倒序方式獲取一個范圍內的元素。
• 在skiplist中可以很方便地計算出每個元素的排名(rank)。

 

六.Redis為什么用skiplist而不用平衡樹？

這里從內存占用、對范圍查找的支持和實現難易程度這三方面總結的原因。

There are a few reasons:
1) They are not very memory intensive. It’s up to you basically. Changing parameters about the probability of a node to have a given number of levels will make then less memory intensive than btrees.
1) 也不是非常耗費內存，實際上取決於生成層數函數里的概率 p，取決得當的話其實和平衡樹差不多。

2) A sorted set is often target of many ZRANGE or ZREVRANGE operations, that is, traversing the skip list as a linked list. With this operation the cache locality of skip lists is at least as good as with other kind of balanced trees.
2) 因為有序集合經常會進行 ZRANGE 或 ZREVRANGE 這樣的范圍查找操作，跳表里面的雙向鏈表可以十分方便地進行這類操作。

3) They are simpler to implement, debug, and so forth. For instance thanks to the skip list simplicity I received a patch (already in Redis master) with augmented skip lists implementing ZRANK in O(log(N)). It required little changes to the code.
3) 實現簡單，ZRANK 操作還能達到 o(logn)的時間復雜度O

 

參考：https://zsr.github.io/2017/07/03/redis-zset%E5%86%85%E9%83%A8%E5%AE%9E%E7%8E%B0/