什么？跳表都不知道的你還敢去面BAT！
跳表這一數(shù)據(jù)結構，已經(jīng)成為了Redis面試的高頻考點。前兩年沒這么卷的時候，可能大家從開始學習，到拿到大廠offer這一過程，都可能沒聽說過跳表這一數(shù)據(jù)結構。
那什么是跳表呢？它是用來干啥的？AVL樹紅黑樹知道吧，對，跳表跟他干的事情差不多。我舉個例子大家就明白了。假設目前有一個有序數(shù)列：
[2, 11，22, 33, 44, 52, 63]
我們想基于單鏈表的思想，設計一個數(shù)據(jù)結構，實現(xiàn)查找時間復雜度為O(logn)。單鏈表的話，它的結構長這個樣子。
當然這個結構，查找時間復雜度妥妥的O(n)，那咋改呢？
那換個問法：一般做算法題，手撕代碼面試的時候，當咱寫了個時間復雜度為O(n)的解法，面試官搖搖頭，問你有沒有更好的方法，你會怎么做？
常見復雜度O(nlogn) O(n) O(logn) O(1)，要優(yōu)化，一步步來的話，只能上O(logn)了，那復雜度logn最常見的算法是哪個？當然是二分！
思路對了，那對著鏈表，咋把二分思想融合進去呢？
要不單鏈表指針這邊動動刀子？讓指針除了指向后面元素，還能越過幾個節(jié)點，指向更后面元素？類似二叉查找樹？先來看看這個數(shù)組對應的二叉查找樹長什么樣。
當然，由于我們的結構是單鏈表，所以只能有由小值，指向大值，這個二叉樹得改改。
好像有點意思在里面了，再把原先單鏈表的性質加上。
走線有點凌亂，按單鏈表的布局顯示方式改改：（值得注意的是，我們需要新建一個數(shù)組項，每個數(shù)組項存儲一個指針，指向剛剛二叉搜索樹每一層最左側的節(jié)點）
（咋感覺越看越像B+樹了（霧））
來看個查找邏輯吧：
當查找到的結點保存的數(shù)，比要查找的數(shù)小時，跳表就會繼續(xù)訪問該層上的下一個結點。
當不滿足時，跳表就會用到當前查找到的結點的指針數(shù)組的下一層指針，然后沿著下一層指針繼續(xù)查找。
對于這種數(shù)據(jù)結構，我們需要從上往下依次查詢三個鏈表，比如我們想查大于35的數(shù)字。
首先按左側數(shù)組第一個找，發(fā)現(xiàn)中間節(jié)點是33，比較一下比35小。 
發(fā)現(xiàn)33比35小，跳下一個節(jié)點。 
發(fā)現(xiàn)該節(jié)點是Null，跳33的下一層節(jié)點。 
發(fā)現(xiàn)52比35大，再跳下一層節(jié)點。 
發(fā)現(xiàn)44比35大，跳下一層節(jié)點，但由于這是最后一層節(jié)點，即44是第一個比33大的數(shù)，滿足最終條件，就找到了第一個比35大的數(shù)字。
我們知道，二叉平衡樹，如果設計插入操作，會特別特別麻煩。對于由二叉平衡樹思想改的跳表也是如此，對于我們這邊的情況，每增加，或者減少一個新節(jié)點，每個節(jié)點的高度都需要變化。。那有沒有高人改進呢？
既然把二叉平衡樹改成這四不像了，為啥再不改改，能不能讓他不平衡的同時，還能保證查找效率？
說實話，還真可以，來看看這種跳表。
雖然這個跳表跟咱剛剛講的跳表比起來，奇形怪狀的，但按剛剛的查找思路，還是能做比較好的查詢工作的。
而且既然表都長這么奇形怪狀了，那添加或者刪新元素，其他節(jié)點高度不變問題也不大了。
而且驚人的是，如果我們對新插入節(jié)點的高度進行隨機產(chǎn)生(每次隨機大于p，接著往上加高度，小于p停下來)，然后別的節(jié)點高度保持不變，查找效率還是為O(logn)，不會出現(xiàn)像二叉查找樹那種直接退化成O(logn)的情況。
有興趣想看推導的同學點個贊，點贊破100，咱寫波推導。（目前面試還沒卷到要證明跳表時間復雜度的程度，所以不知道咋推沒問題）
參考：
https://blog.csdn.net/helloworld_ptt/article/details/105801262 Redis設計與實現(xiàn) Redis源碼剖析與實戰(zhàn)