之前寫過一篇 Redis 數據類型的底層數據結構的實現，其中提到，ZSet 對象的底層數據結構實現之一是跳錶。
然後，有讀者就問：爲什麼不使用平衡樹（如紅黑樹、AVL 樹）？
我們先來了解下跳錶，再來回答這個問題。
跳錶
Redis 只有 Zset 對象的底層實現用到了跳錶，跳錶的優勢是能支持平均 O(logN) 複雜度的節點查找。
zset 結構體裏有兩個數據結構：一個是跳錶，一個是哈希表。這樣的好處是既能進行高效的範圍查詢，也能進行高效單點查詢。
typedef struct zset {
dict *dict;
zskiplist *zsl;
} zset;
Zset 對象在執行數據插入或是數據更新的過程中，會依次在跳錶和哈希表中插入或更新相應的數據，從而保證了跳錶和哈希表中記錄的信息一致。
Zset 對象能支持範圍查詢（如 ZRANGEBYSCORE 操作），這是因爲它的數據結構設計採用了跳錶，而又能以常數複雜度獲取元素權重（如 ZSCORE 操作），這是因爲它同時採用了哈希表進行索引。
可能很多人會奇怪，爲什麼我開頭說 Zset 對象的底層數據結構是「壓縮列表」或者「跳錶」，而沒有說哈希表呢？
Zset 對象在使用跳錶作爲數據結構的時候，是使用由「哈希表+跳錶」組成的 struct zset，但是我們討論的時候，都會說跳錶是 Zset 對象的底層數據結構，而不會提及哈希表，是因爲 struct zset 中的哈希表只是用於以常數複雜度獲取元素權重，大部分操作都是跳錶實現的。
接下來，詳細的說下跳錶。
跳錶結構設計
鏈表在查找元素的時候，因爲需要逐一查找，所以查詢效率非常低，時間複雜度是O(N)，於是就出現了跳錶。跳錶是在鏈表基礎上改進過來的，實現了一種「多層」的有序鏈表，這樣的好處是能快讀定位數據。
那跳錶長什麼樣呢？我這裏舉個例子，下圖展示了一個層級爲 3 的跳錶。
圖中頭節點有 L0~L2 三個頭指針，分別指向了不同層級的節點，然後每個層級的節點都通過指針連接起來：
- L0 層級共有 5 個節點，分別是節點1、2、3、4、5；
- L1 層級共有 3 個節點，分別是節點 2、3、5；
- L2 層級只有 1 個節點，也就是節點 3 。
如果我們要在鏈表中查找節點 4 這個元素，只能從頭開始遍歷鏈表，需要查找 4 次，而使用了跳錶後，只需要查找 2 次就能定位到節點 4，因爲可以在頭節點直接從 L2 層級跳到節點 3，然後再往前遍歷找到節點 4。
可以看到，這個查找過程就是在多個層級上跳來跳去，最後定位到元素。當數據量很大時，跳錶的查找複雜度就是 O(logN)。
那跳錶節點是怎麼實現多層級的呢？這就需要看「跳錶節點」的數據結構了，如下：
typedef struct zskiplistNode {
//Zset 對象的元素值
sds ele;
//元素權重值
double score;
//後向指針
struct zskiplistNode *backward;
//節點的level數組，保存每層上的前向指針和跨度
struct zskiplistLevel {
struct zskiplistNode *forward;
unsigned long span;
} level[];
} zskiplistNode;
Zset 對象要同時保存「元素」和「元素的權重」，對應到跳錶節點結構裏就是 sds 類型的 ele 變量和 double 類型的 score 變量。每個跳錶節點都有一個後向指針（struct zskiplistNode *backward），指向前一個節點，目的是爲了方便從跳錶的尾節點開始訪問節點，這樣倒序查找時很方便。
跳錶是一個帶有層級關係的鏈表，而且每一層級可以包含多個節點，每一個節點通過指針連接起來，實現這一特性就是靠跳錶節點結構體中的zskiplistLevel 結構體類型的 level 數組。
level 數組中的每一個元素代表跳錶的一層，也就是由 zskiplistLevel 結構體表示，比如 leve[0] 就表示第一層，leve[1] 就表示第二層。zskiplistLevel 結構體裏定義了「指向下一個跳錶節點的指針」和「跨度」，跨度時用來記錄兩個節點之間的距離。
比如，下面這張圖，展示了各個節點的跨度。
第一眼看到跨度的時候，以爲是遍歷操作有關，實際上並沒有任何關係，遍歷操作只需要用前向指針（struct zskiplistNode *forward）就可以完成了。
跨度實際上是爲了計算這個節點在跳錶中的排位。具體怎麼做的呢？因爲跳錶中的節點都是按序排列的，那麼計算某個節點排位的時候，從頭節點點到該結點的查詢路徑上，將沿途訪問過的所有層的跨度累加起來，得到的結果就是目標節點在跳錶中的排位。
舉個例子，查找圖中節點 3 在跳錶中的排位，從頭節點開始查找節點 3，查找的過程只經過了一個層（L2），並且層的跨度是 3，所以節點 3 在跳錶中的排位是 3。
另外，圖中的頭節點其實也是 zskiplistNode 跳錶節點，只不過頭節點的後向指針、權重、元素值都沒有用到，所以圖中省略了這部分。
問題來了，由誰定義哪個跳錶節點是頭節點呢？這就介紹「跳錶」結構體了，如下所示：
typedef struct zskiplist {
struct zskiplistNode *header, *tail;
unsigned long length;
int level;
} zskiplist;
跳錶結構裏包含了：
- 跳錶的頭尾節點，便於在O(1)時間複雜度內訪問跳錶的頭節點和尾節點；
- 跳錶的長度，便於在O(1)時間複雜度獲取跳錶節點的數量；
- 跳錶的最大層數，便於在O(1)時間複雜度獲取跳錶中層高最大的那個節點的層數量；
跳錶節點查詢過程
查找一個跳錶節點的過程時，跳錶會從頭節點的最高層開始，逐一遍歷每一層。在遍歷某一層的跳錶節點時，會用跳錶節點中的 SDS 類型的元素和元素的權重來進行判斷，共有兩個判斷條件：
- 如果當前節點的權重「小於」要查找的權重時，跳錶就會訪問該層上的下一個節點。
- 如果當前節點的權重「等於」要查找的權重時，並且當前節點的 SDS 類型數據「小於」要查找的數據時，跳錶就會訪問該層上的下一個節點。
如果上面兩個條件都不滿足，或者下一個節點爲空時，跳錶就會使用目前遍歷到的節點的 level 數組裏的下一層指針，然後沿着下一層指針繼續查找，這就相當於跳到了下一層接着查找。
舉個例子，下圖有個 3 層級的跳錶。
如果要查找「元素：abcd，權重：4」的節點，查找的過程是這樣的：
- 先從頭節點的最高層開始，L2 指向了「元素：abc，權重：3」節點，這個節點的權重比要查找節點的小，所以要訪問該層上的下一個節點；
- 但是該層的下一個節點是空節點（ leve[2]指向的是空節點），於是就會跳到「元素：abc，權重：3」節點的下一層去找，也就是 leve[1];
- 「元素：abc，權重：3」節點的 leve[1] 的下一個指針指向了「元素：abcde，權重：4」的節點，然後將其和要查找的節點比較。雖然「元素：abcde，權重：4」的節點的權重和要查找的權重相同，但是當前節點的 SDS 類型數據「大於」要查找的數據，所以會繼續跳到「元素：abc，權重：3」節點的下一層去找，也就是 leve[0]；
- 「元素：abc，權重：3」節點的 leve[0] 的下一個指針指向了「元素：abcd，權重：4」的節點，該節點正是要查找的節點，查詢結束。
跳錶節點層數設置
跳錶的相鄰兩層的節點數量的比例會影響跳錶的查詢性能。
舉個例子，下圖的跳錶，第二層的節點數量只有 1 個，而第一層的節點數量有 6 個。
這時，如果想要查詢節點 6，那基本就跟鏈表的查詢複雜度一樣，就需要在第一層的節點中依次順序查找，複雜度就是 O(N) 了。所以，爲了降低查詢複雜度，我們就需要維持相鄰層結點數間的關係。
跳錶的相鄰兩層的節點數量最理想的比例是 2:1，查找複雜度可以降低到 O(logN)。
下圖的跳錶就是，相鄰兩層的節點數量的比例是 2 : 1。
那怎樣才能維持相鄰兩層的節點數量的比例爲 2 : 1 呢？
如果採用新增節點或者刪除節點時，來調整跳錶節點以維持比例的方法的話，會帶來額外的開銷。
Redis 則採用一種巧妙的方法是，跳錶在創建節點的時候，隨機生成每個節點的層數，並沒有嚴格維持相鄰兩層的節點數量比例爲 2 : 1 的情況。
具體的做法是，跳錶在創建節點時候，會生成範圍爲[0-1]的一個隨機數，如果這個隨機數小於 0.25（相當於概率 25%），那麼層數就增加 1 層，然後繼續生成下一個隨機數，直到隨機數的結果大於 0.25 結束，最終確定該節點的層數。
這樣的做法，相當於每增加一層的概率不超過 25%，層數越高，概率越低，層高最大限制是 64。
爲什麼用跳錶而不用平衡樹？
爲什麼 Zset 的實現用跳錶而不用平衡樹（如 AVL樹、紅黑樹等）？
對於這個問題，Redis的作者 @antirez 是怎麼說的：
There are a few reasons:
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.
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.
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.
簡單翻譯一下，主要是從內存佔用、對範圍查找的支持、實現難易程度這三方面總結的原因：
- 它們不是非常內存密集型的。基本上由你決定。改變關於節點具有給定級別數的概率的參數將使其比 btree 佔用更少的內存。
- Zset 經常需要執行 ZRANGE 或 ZREVRANGE 的命令，即作爲鏈表遍歷跳錶。通過此操作，跳錶的緩存局部性至少與其他類型的平衡樹一樣好。
- 它們更易於實現、調試等。例如，由於跳錶的簡單性，我收到了一個補丁（已經在Redis master中），其中擴展了跳錶，在 O(log(N) 中實現了 ZRANK。它只需要對代碼進行少量修改。
我再詳細補充點：
- 從內存佔用上來比較，跳錶比平衡樹更靈活一些。平衡樹每個節點包含 2 個指針（分別指向左右子樹），而跳錶每個節點包含的指針數目平均爲 1/(1-p)，具體取決於參數 p 的大小。如果像 Redis裏的實現一樣，取 p=1/4，那麼平均每個節點包含 1.33 個指針，比平衡樹更有優勢。
- 在做範圍查找的時候，跳錶比平衡樹操作要簡單。在平衡樹上，我們找到指定範圍的小值之後，還需要以中序遍歷的順序繼續尋找其它不超過大值的節點。如果不對平衡樹進行一定的改造，這裏的中序遍歷並不容易實現。而在跳錶上進行範圍查找就非常簡單，只需要在找到小值之後，對第 1 層鏈表進行若干步的遍歷就可以實現。
- 從算法實現難度上來比較，跳錶比平衡樹要簡單得多。平衡樹的插入和刪除操作可能引發子樹的調整，邏輯複雜，而跳錶的插入和刪除只需要修改相鄰節點的指針，操作簡單又快速。
[來源]：小林coding