Redis中的zset，首先它是一个set，set中的元素具有不可重复性，其次它也是一个有序集合，其中的元素按照一定的评分进行排序。Set的内部结构我们就不说了，可以参考上一节的内容《Redis笔记（三）- 基础数据结构_Hash和Set》，我们这次主要探讨一下zset中元素是怎么实现有序的。
概括
实际上zset对于排序有两种结构实现，一种是在元素个数比较少且总长度比较短的时候使用压缩列表（ziplist，参考《Redis笔记（二）- 基础数据结构_List》中的部分内容），另一种是不符合上述条件时使用跳跃列表（skiplist）。
ziplist使用条件：
- 元素数量小于128个。
- 所有元素成员的长度小于64字节。
zset中的压缩列表ziplist
先来回顾一下ziplist的结构
struct ziplist<T> {
int32 zlbytes; // 整个压缩列表占用字节数
int32 zltail_offset; // 最后一个元素距离压缩列表起始位置的偏移量，用于快速定位到最后一个节点
int16 zllength; // 元素个数
T[] entries; // 元素内容列表，紧凑的连续内存空间
int8 zlend; // 标志压缩列表的结束，值恒为 0xFF
}
每一个entry的结构：
struct entry {
int<var> prevlen; // 前一个 entry 的字节长度
int<var> encoding; // 元素类型编码
optional byte[] content; // 元素内容
}
zset中的ziplist元素是怎样存的呢？entries中每两个连续entry为一组，表示一个元素，第一个entry保存的是其元素的值，第二个entry保存的是其评分，评分低的排在entries数组的前面，评分高的排在entries数组的后面。
zset中的跳跃列表skiplist
先来张图解释下跳跃列表：
最底层是一个有序的链表，查找一个元素，需要O(n)的时间复杂度，但是如果从这个链表抽出一部分元素，形成一个新的链表，把这个链表当做粗略的索引，遍历索引的次数要比遍历原始链表的次数大大降低。典型的空间换时间的思维。
检索过程
举个例子，如果我要查找"13"这个元素，首先从最高的第二级索引层遍历，当遍历过元素"7"之后，发现我要找的"13"这个元素是小于下一个元素"14"的，因此，进入第一级索引层继续从"7"遍历到"14",当遍历过元素"10"之后，要找的"13"这个元素还是小于下一个元素"14"的，于是继续在下一级的原始链表中从"10"遍历到"14"，最后就能在这个范围中找到"13"这个元素。
插入过程
redis的跳跃列表并不是按照严格的"上一层的索引节点数是下一层的二分之一"这样的规则进行构造的，因为假如按照这个规则进行插入，则插入元素的左右节点的层数都要调整。而实际上每插入一个元素，这个元素所拥有的层数是随机的。看个插入过程的例子：
每插入一个元素随机层数的计算方法如下：
- 首先，每个节点肯定都有第1层指针（每个节点都在第1层链表里）。
- 如果一个节点有第i层(i>=1)指针（即节点已经在第1层到第i层链表中），那么它有第(i+1)层指针的概率为p^(i-1)，p默认1/4。
- 节点最大的层数不允许超过一个最大值，记为MaxLevel。
总结
- 查询元素的分数值，是用zset中的hash结构来查的。
- 范围查询或者获取元素的排名是根据skiplist来查的。这里skiplist做了一点小优化，就是在元素的每层索引的指针扩展了一个属性，这个属性存储了这个元素到指针指向的下一个元素之前有多少个节点，又称跨度，这样在检索一个元素的时候就可以很方便的知道在这个元素在整个链表的排名。
