redis使用跳表不用B+數的原因是：redis是內存數據庫，而B+樹純粹是為了mysql這種IO數據庫准備的。B+樹的每個節點的數量都是一個mysql分區頁的大小(阿里面試)
還有個幾個姊妹篇：介紹mysql的B+索引原理 參考：一步步分析為什么B+樹適合作為索引的結構 以及索引原理 (阿里面試)
參考：kafka如何實現高並發存儲-如何找到一條需要消費的數據(阿里)
參考：二分查找法：各種排序算法的時間復雜度和空間復雜度(阿里)
關於mysql 存儲引擎 介紹包括默認的索引方式參考：MySql的多存儲引擎架構, 默認的引擎InnoDB與 MYISAM的區別(滴滴 阿里)
敲黑板：
每級遍歷 3 個結點即可，而跳表的高度為 h ，所以每次查找一個結點時，需要遍歷的結點數為 3*跳表高度 ，所以忽略低階項和系數后的時間復雜度就是 ○(㏒n),空間復雜度是O(n)
| 數據結構 | 實現原理 | key查詢方式 | 查找效率 | 存儲大小 | 插入、刪除效率 |
|---|---|---|---|---|---|
| Hash | 哈希表 | 支持單key | 接近O(1) | 小，除了數據沒有額外的存儲 | O(1) |
| B+樹 | 平衡二叉樹擴展而來 | 單key,范圍，分頁 | O(Log(n) | 除了數據，還多了左右指針，以及葉子節點指針 | O(Log(n)，需要調整樹的結構，算法比較復雜 |
| 跳表 | 有序鏈表擴展而來 | 單key，分頁 | O(Log(n) | 除了數據，還多了指針，但是每個節點的指針小於<2,所以比B+樹占用空間小 | O(Log(n)，只用處理鏈表，算法比較簡單 |
對LSM結構感興趣的可以看下cassandra vs mongo (1)存儲引擎
問題
如果對以下問題感到困惑或一知半解，請繼續看下去，相信本文一定會對你有幫助
- mysql 索引如何實現
- mysql 索引結構B+樹與hash有何區別。分別適用於什么場景
- 數據庫的索引還能有其他實現嗎
- redis跳表是如何實現的
- 跳表和B+樹，LSM樹有和區別呢
解析
首先為什么要把mysql索引和redis跳表放在一起討論呢，因為他們解決的都是同一種問題，用於解決數據集合的查找問題，即根據指定的key，快速查到它所在的位置（或者對應的value）
當你站在這個角度去思考問題時，還會不知道B+樹索引和hash索引的區別嗎
數據集合的查找問題
現在我們將問題領域邊界划分清楚了，就是為了解決數據集合的查找問題。這一塊需要考慮哪些問題呢
- 需要支持哪些查找方式，單key/多key/范圍查找，
- 插入/刪除效率
- 查找效率（即時間復雜度）
- 存儲大小（空間復雜度）
我們看下幾種常用的查找結構
hash
hash是key,value形式，通過一個散列函數，能夠根據key快速找到value
關於hash算法 ，這也是阿里的必考題 深度的原理 我寫了幾篇博客：尤其是最后一篇resize ，以及resize之前與之后的hashmap的情況，
參考：Hashtable數據存儲結構-遍歷規則，Hash類型的復雜度為啥都是O(1)-源碼分析
參考：HashMap, HashTable，HashSet,TreeMap 的時間復雜度
參考：HashMap底層實現原理/HashMap與HashTable區別/HashMap與HashSet區別
參考：ConcurrentHashMap原理分析（1.7與1.8）-put和 get 兩次Hash到達指定的HashEntry
resize 參考：HashMap多線程並發問題分析-正常和異常的rehash1(阿里)
B+ 樹：
注意 這是關於B+樹的總結，如果你掌握到這個程度 是遠遠不夠的，
請參考詳細的B+樹原理：一步步分析為什么B+樹適合作為索引的結構 以及索引原理 (阿里面試)
B+樹 的數據都在葉子節點，非葉子節點存放 索引
B+樹是在平衡二叉樹基礎上演變過來，為什么我們在算法課上沒學到B+樹和跳表這種結構呢。因為他們都是從工程實踐中得到，在理論的基礎上進行了妥協。
B+樹首先是有序結構，為了不至於樹的高度太高，影響查找效率，在葉子節點上存儲的不是單個數據，而是一頁數據，提高了查找效率，而為了更好的支持范圍查詢，B+樹在葉子節點冗余了非葉子節點數據，為了支持翻頁，葉子節點之間通過指針連接。
跳表
跳表：為什么 Redis 一定要用跳表來實現有序集合？
上幾篇主要是學習二分查找算法，但是二分查找底層依賴的是數組隨機訪問的特性，所以只能用數組來實現。如果數據存儲在鏈表中，就沒辦法使用二分查找了嗎？
此時跳表出現了，跳表（Skip list） 實際上就是在鏈表的基礎上改造生成的。
跳表是一種各方面性能都比較優秀的 動態數據結構，可以支持快速的插入、刪除、查找操作，寫起來也不復雜，甚至可以替代 紅黑樹？？。
Redis 一共有5種數據結構，包括：
1、字符串(String)
redis對於KV的操作效率很高，可以直接用作計數器。例如，統計在線人數等等，另外string類型是二進制存儲安全的，所以也可以使用它來存儲圖片，甚至是視頻等。
2、哈希(hash)
存放鍵值對，一般可以用來存某個對象的基本屬性信息，例如，用戶信息，商品信息等，另外，由於hash的大小在小於配置的大小的時候使用的是ziplist結構，比較節約內存，所以針對大量的數據存儲可以考慮使用hash來分段存儲來達到壓縮數據量，節約內存的目的，例如，對於大批量的商品對應的圖片地址名稱。比如：商品編碼固定是10位，可以選取前7位做為hash的key,后三位作為field，圖片地址作為value。這樣每個hash表都不超過999個，只要把redis.conf中的hash-max-ziplist-entries改為1024，即可。
3、列表(List)
列表類型，可以用於實現消息隊列，也可以使用它提供的range命令，做分頁查詢功能。
4、集合(Set)
集合，整數的有序列表可以直接使用set。可以用作某些去重功能，例如用戶名不能重復等，另外，還可以對集合進行交集，並集操作，來查找某些元素的共同點
5、有序集合(zset)
有序集合，可以使用范圍查找，排行榜功能或者topN功能。
其中第五個zset 有序集合 就是用跳表來實現的。那 Redis 為什么會選擇用跳表來實現有序集合呢？
一、如何理解跳表？
對於單鏈表來說，我們查找某個數據，只能從頭到尾遍歷鏈表，此時時間復雜度是 ○(n)。
那么怎么提高單鏈表的查找效率呢？看下圖，對鏈表建立一級 索引，每兩個節點提取一個結點到上一級，被抽出來的這級叫做 索引 或 索引層。
開發中經常會用到一種處理方式，hashmap 中存儲的值類型是一個 list，這里就可以把索引當做 hashmap 中的鍵，將每 2 個結點看成每個鍵對應的值 list。
所以要找到13，就不需要將16前的結點全遍歷一遍，只需要遍歷索引，找到13，然后發現下一個結點是17，那么16一定是在 [13,17] 之間的，此時在13位置下降到原始鏈表層，找到16，加上一層索引后，查找一個結點需要遍歷的結點個數減少了，也就是說查找效率提高了
那么我們再加一級索引呢？
跟前面建立一級索引的方式相似，我們在第一級索引的基礎上，每兩個結點就抽出一個結點到第二級索引。此時再查找16，只需要遍歷 6 個結點了，需要遍歷的結點數量又減少了。
當結點數量多的時候，這種添加索引的方式，會使查詢效率提高的非常明顯、
二、用跳表查詢到底有多快
在一個單鏈表中，查詢某個數據的時間復雜度是 ○(n)，那在一個具有多級索引的跳表中，查詢某個數據的時間復雜度是多少呢？
按照上面的示例，每兩個節點就抽出一個一級索引，每兩個一級索引又抽出一個二級索引，所以第一級索引的結點個數大約就是 n/2，第二級索引的結點個數就是 n/4，第 k 級索引的結點個數就是 n/2^k。
假設一共建立了 h 級索引，最高級的索引有兩個節點（如果最高級索引只有一個結點，那么這一級索引起不到判斷區間的作用，那么是沒什么意義的），所以有：
根據上圖得知，每級遍歷 3 個結點即可，而跳表的高度為 h ，所以每次查找一個結點時，需要遍歷的結點數為 3*跳表高度 ，所以忽略低階項和系數后的時間復雜度就是 ○(㏒n)
其實此時就相當於基於單鏈表實現了二分查找。但是這種查詢效率的提升，由於建立了很多級索引，會不會很浪費內存呢？
三、跳表是不是很浪費內存？
來分析一下跳表的空間復雜度。 為O(n)
所以如果將包含 n 個結點的單鏈表構造成跳表，我們需要額外再用接近 n 個結點的存儲空間，那怎么才能降低索引占用的內存空間呢？
前面是每兩個結點抽一個結點到上級索引，如果我們每三個，或每五個結點，抽一個結點到上級索引，是不是就不用那么多索引結點了呢？
計算空間復雜度的過程與前面的一致，盡管最后空間復雜度依然是 ○(n)，但我們知道，使用大○表示法忽略的低階項或系數，實際上同樣會產生影響，只不過我們為了關注高階項而將它們忽略。
實際上，在實際開發中，我們不需要太在意索引占據的額外空間，在學習數據結構與算法時，我們習慣的將待處理數據看成整數，但是實際開發中，原始鏈表中存儲的很可能是很大的對象，而索引結點只需要存儲關鍵值（用來比較的值）和幾個指針（找到下級索引的指針），並不需要存儲原始鏈表中完整的對象，所以當對象比索引結點大很多時，那索引占用的額外空間就可以忽略了。
四、高效的動態插入和刪除
跳表這個動態數據結構，不僅支持查找操作，還支持動態的插入、刪除操作，而且插入、刪除操作的時間復雜度也是 ○(㏒n)。
對於單純的單鏈表，需要遍歷每個結點來找到插入的位置。但是對於跳表來說，因為其查找某個結點的時間復雜度是 ○(㏒n)，所以這里查找某個數據應該插入的位置，時間復雜度也是 ○(㏒n)。
那么刪除操作呢？
五、跳表索引動態更新
當我們不停的往跳表中插入數據時，如果我們不更新索引，就可能出現某 2 個索引結點之間數據非常多的情況。極端情況下，跳表會退化成單鏈表。
跳表是通過隨機函數來維護前面提到的 平衡性。
我們往跳表中插入數據的時候，可以選擇同時將這個數據插入到第幾級索引中，比如隨機函數生成了值 K，那我們就將這個結點添加到第一級到第 K 級這 K 級索引中。
跳表的實現有點復雜，並且跳表的實現並不是這篇的重點。主要是學習思路。
六、解答開篇
Redis 中的有序集合是通過跳表來實現的，嚴格點講，還用到了散列表（關於散列表），如果查看 Redis 開發手冊，會發現 Redis 中的有序集合支持的核心操作主要有下面這幾個：
- 插入一個數據
- 刪除一個數據
- 查找一個數據
- 按照區間查找數據（比如查找在[100,356]之間的數據）
- 迭代輸出有序序列
其中，插入、查找、刪除以及迭代輸出有序序列這幾個操作，紅黑樹也能完成，時間復雜度和跳表是一樣的，但是，按照區間來查找數據這個操作，紅黑樹的效率沒有跳表高。
對於按照區間查找數據這個操作，跳表可以做到 ○(㏒n) 的時間復雜度定位區間的起點，然后在原始鏈表中順序往后遍歷就可以了。這樣做非常高效。
當然，還有其他原因，比如，跳表代碼更容易實現，可讀性好不易出錯。跳表更加靈活，可以通過改變索引構建策略，有效平衡執行效率和內存消耗。
不過跳表也不能完全替代紅黑樹。因為紅黑樹出現的更早一些。很多編程語言中的 Map 類型都是用紅黑樹來實現的。寫業務的時候直接用就行，但是跳表沒有現成的實現，開發中想用跳表，得自己實現。