Redis跳表的实现原理：为什么ZSet选择跳表而非红黑树？
一、跳表是什么？从链表到"多层电梯"
想象一个单向链表查找元素的场景：若要从头到尾找到节点13，需要逐个遍历7次（时间复杂度O(n)）。这种效率显然无法满足高性能场景的需求。于是，**跳表（Skip List）**应运而生------它通过在链表上构建多级索引，将查找效率提升到O(log n)。
跳表的核心设计：
- 多层索引：每一层都是一个有序链表，上层索引的节点数是下层的约1/2，类似"电梯"快速跨越多个节点。
- 跳跃式查询：从最高层索引开始，若当前节点的下一个节点值小于目标值，则向右移动；否则向下移动一层继续查找。
例如，在下图（假设存在）中查找13时，跳表通过索引层快速跳跃，只需6次访问即可找到目标，而普通链表需要7次。
二、跳表的关键操作
1. 插入与删除：随机性与链表的结合
- 插入：随机决定新节点的层数（如抛硬币，连续正面则增加层数），然后像普通链表一样插入到每一层的对应位置。
- 删除：找到目标节点在所有层的引用，逐层删除。
例如，插入13.5时，若随机生成2层索引，则需在底层链表和第1层索引中插入该节点。
2. 时间复杂度
- 平均O(log n)：得益于多层索引，跳表能快速缩小搜索范围。
- 最坏O(n)：所有节点集中在同一层，退化为普通链表（但概率极低）。
三、Redis跳表的特殊设计
1. 为什么支持score重复？
Redis的ZSet允许成员（member）的分数（score）相同，此时按成员的字典序排序。跳表的节点结构包含score和member，通过联合比较实现排序。
2. 回退指针：双向链表的优势
Redis跳表在每层索引中增加了前驱指针（backward pointer），使得节点可以向前回溯。这样做的好处：
- 提升范围查询效率：例如查询排名区间内的成员时，可直接从起点向后遍历，无需重新从头部开始。
- 简化指针更新逻辑：删除节点时，前驱指针能快速定位相邻节点，减少指针调整的复杂度。
四、为什么Redis选择跳表而非红黑树？
虽然红黑树的查询、插入、删除操作也能达到O(log n)，但Redis的ZSet选择跳表，主要基于以下原因：
1. 范围查询的高效性
- 跳表的最底层是完整的有序链表，遍历连续元素时只需顺序访问，时间复杂度为O(k)（k为范围内元素数量），且内存连续，缓存友好。
- 红黑树范围查询需通过中序遍历实现，需维护栈结构或父指针，隐性成本更高。
2. 实现复杂度低
- 跳表的插入、删除仅需调整相邻节点的指针，而红黑树需处理颜色变换、旋转等复杂操作。
- 跳表的代码实现更简洁，调试和维护成本更低。
3. 并发场景友好
- 跳表的分层结构更容易实现无锁并发（如Java的ConcurrentSkipListMap），而红黑树的并发优化更为复杂。
五、总结：跳表在Redis中的实践价值
Redis的ZSet通过跳表实现了以下核心功能：
- 快速单点查询：基于score快速定位成员。
- 高效范围查询：ZRANGE、ZRANK等命令直接利用底层链表遍历。
- 灵活的更新操作：插入、删除时仅需局部调整指针。
跳表以"空间换时间"的思维（额外存储索引层），在简单性与高性能之间找到了完美平衡。这也是Redis这一内存数据库在追求极致性能时的经典设计选择。
思考题：如果Redis的ZSet需要支持频次极高的写入场景，跳表是否仍是最优解？欢迎在评论区探讨！