Redis的知名度不必多说，相信从事后端开发的朋友多半都是知道的。而大家学习的时候，必然也是要了解到它的数据结构，其中跳表又是一个非常重要的概念，废话不多说，直接说下我最近的想法总结，分享给大家，欢迎讨论。

说到跳表的数据结构，我们都知道一些基本定义，这里直接放张网络图片

 我们都知道zskiplist里面有length和level属性，他们定义分别如下

 他们有一个相同点：不包含头节点。

不知道大家有没有过和我一样的疑问，为什么不包含呢？设计者这么设计的原因是出于什么考虑呢？下面是我对这个问题的思考，抛砖引玉哈。

首先，我们从结果来反推一下。zskiplist表示的是跳表，他的length和level属性自然表示的就是整个跳表的属性，如果length和level不包含头节点的话，那就说明，头节点是没有存储数据的。

既然没有存储数据，那一定是有某些原因导致头节点不方便存放数据。

我们继续看跳表的特性，跳表查询性能非常依赖于他“层”，从起始节点开始，由高到低依次遍历层，找到层中下一个节点，依据下一个节点的值，来判断跳跃到当前层下一个节点，还是下到下一层继续比较。

跳表的查找逻辑就决定了，第一个节点的层高必然要是最高的。因为如果第一个节点不是最高，那大于第一个节点层高的层将没有意义，因为根本访问不到他们。打个比方，如果跳表第一个节点有4层，第三个节点有10层，根据查找逻辑，从第一个节点的层开始遍历，最高只会到4，也就是会访问到第三个节点的4层，第三个节点5至10层都不会用到。

所以总结第一点：由于跳表查找特性，头节点的层高一定要是最高的。

就算基于第一点，也不见得header节点就不能放元素啊。下面继续分享我的想法。

基于第一点，假如我们header节点可以放元素，那他的节点就必然要拉到最高，拉到上限还是随着跳表元素的插入随时改动呢？都不行，因为跳表中的顺序是随时会变的，假如当前的节点排序在第一，被当做header，那如果后续插入了一个score更小的元素呢，此时怎么办，难道让header指向新插入的元素，然后把层高拉到和原来的第一个节点一样？如果这样，长期下去，整个跳表的节点层高都会变的很高，跳表就跳不动了。

所以基于上面描述，得出第二点：header节点由于层高机制，最好层高不可变，且拉到最高。

基于上面两点：首节点层高必须最高，且因为要保证最高，所以必须要拉满，并且排序不可变。

那基于上面，自然就会想到，将header节点独立出来，只是作为访问跳表元素的起点来使用，不存放集合元素，层高设置到最高且不变，也就是上限64。由于不存在元素，自然也就不会在length的计数当中被计入，level也是一样。