Redis的五种数据结构分析
Redis本身是一个Map，其中所有的数据都是采用key：value的形式存储
这里的数据类型主要是指存储的，也即是value的数据类型，key的数据类型永远都是String
redis中value使用的数据结构有：
String：字符串类型List：列表类型Hash：哈希表类型Set：无序集合类型- sorted set：有序集合类型
下面我们来一个一个分别来了解一下：
一、String：字符串类型
redis是使用C语言开发，但C中并没有String类型，只能使用指针或字符数组的形式表示一个字符串，所以redis设计了一种简单动态字符串(SDS[Simple Dynamic String])作为底层实现。
这个SDS的内部结构更像是一个ArrayList，内部维护着一个字节数组，并且在其内部预分配了一定的空间，以减少内存的频繁分配。
Redis的内存分配机制是这样：
当字符串的长度小于 1MB时，每次扩容都是加倍现有的空间。
如果字符串长度超过 1MB时，每次扩容时只会扩展 1MB 的空间。
这样既保证了内存空间够用，还不至于造成内存的浪费，字符串最大长度为 512MB。
上图就是字符串的基本结构，其中 content 里面保存的是字符串内容，0x\0作为结束字符不会被计算len中。
SDS的数据结构：
capacity 和 len两个属性都是泛型，为什么不直接用int类型？因为Redis内部有很多优化方案，为更合理的使用内存，不同长度的字符串采用不同的数据类型表示，且在创建字符串的时候 len 会和 capacity 一样大，不产生冗余的空间，所以String值可以是字符串、数字（整数、浮点数) 或者二进制。
redis中SDS和C语言字符串对比：
1）C语言中的字符串，遇到'\0'则结尾，用长度N+1的数组维护长度为N的字符串。
Redis的SDS是：
len表示字符串的长度；
free表示空闲的，未分配的空间；
buffer数组是真正的字符串，并且以'\0'结尾。
2）C 字符串并不记录自身的长度信息，获取一个C字符串的长度,必须遍历整个字符串,对遇到的字符进行计数,直到遇到代表字符串结尾的空字符为止，复杂度为O(n)
SDS 在len属性中记录了SDS的本身长度，复杂度为O(1)
3）C字符串不记录自身长度容易造成缓冲区溢出
SDS 的空间分配策略完全杜绝了发生缓冲区的可能性：当SDS API 需要对SDS进行修改时，API会先检查SDS的空间是否满足修改所需的要求,如果不满足的话,API会自动将SDS的空间扩展至执行修改所需的大小,然后才执行实际的修改操作，所以使用SDS既不需要修改SDS的空间大小,也不会出现前面所说的缓冲区溢出问题
4）减少修改字符串时带来的内存重分配次数
C字符串的长度和底层数组的长度之间存在这种关联性，所以每次增长或者缩短一个C字符串，总要对保存C字符串的数组进行一次内存重分配操作
在SDS中，buf数组的长度不一定就是字符数量加一，java培训数组里面可以包含为使用的字节，而这些字节的数量就由SDS的free属性记录。通过未使用空间，SDS实现了空间预分配和惰性空间释放两种优化策略
5）二级制安全
C字符串必须符合某种编码，并且除了字符串的末尾之外，字符串里面不能包含空字符
SDS的API都是二进制安全的，所有SDS API都会以处理二进制的方式来处理SDS存放在buf数组里的数据
6）C兼容所有字符串函数
SDS兼容部分C字符串函数
String类型的应用
1、可以存储base64的图片数据
2、作为缓存功能，降低mysql数据库的请求
3、做一些短时间的错误限制控制
二、List：列表类型
Redis中的list本质是链表结构
list 的实现在3.2版本之前有两种方式：
压缩列表ziplist
双向链表linkedlist
在3.2版本之后引入了：
快速列表quicklist
因为双向链表linkedlist占用的内存比压缩列表ziplist要多， 所以当创建新的列表键时，列表会优先考虑使用压缩列表ziplist， 并且在有需要的时候， 才从压缩列表ziplist实现转换到双向链表linkedlist实现。
而后续引入的quicklist可以看作是linkedlist和ziplist的结合体。
这三种列表内部使用哪一种类型是通过编码来区分的：
linkedlist
linkedlist是一个双向列表，每个节点都会存储指向上一个节点和指向下一个节点的指针。linkedlist因为每个节点的空间是不连续的，所以可能会造成过多的空间碎片。
linkedlist的存储结构，链表中每一个节点都是一个listNode对象(源码adlist.h内)，不过需要注意的是，列表中的value其实也是一个字符串对象。
然后会将其再进行封装成为一个list对象(源码adlist.h内)：
Redis中对linkedlist的访问是以NULL值为终点的，因为head节点的prev节点为NULL，tail节点的next节点为NULL。
所以，在Redis3.2之前我们可以得到如下简图：
ziplist
ziplist是为了节省内存而开发的一种压缩列表数据结构，哈希数据类型底层也用到了ziplist。
ziplist是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个ziplist可以包含任意多个entry，而每一个entry又可以保存一个字节数组或者一个整数值。
ziplist和linkedlist最大的区别是ziplist不存储指向上一个节点和下一个节点的指针，存储的是上一个节点的长度和当前节点的长度，牺牲了部分读写性能来换取高效的内存利用率，是一种时间换空间的思想。
ziplist适用于字段个数少和字段值少的场景。
ziplist的组成结构：
关于列表选择使用ziplist编码进行存储，必须满足下面两个条件：1）列表对象保存的所有字符串元素的长度都小于64字节。
2）列表对象保存的元素数量小于512个。
一旦不满足这两个条件中的任意一个，则会使用linkedlist编码来进行存储
这两个条件可以通过参数list-max-ziplist-value和list-max-ziplist-entries进行修改重新设定
quicklist
在Redis3.2之后，统一用quicklist来存储列表对象，quicklist存储了一个双向列表，每个列表的节点是一个ziplist，所以实际上quicklist就是linkedlist和ziplist的结合。
quicklist内部存储结构，quicklist中每一个节点都是一个quicklistNode对象，其数据结构定义为：
然后各个quicklistNode就构成了一个列表，quicklist：
根据上面两个结构图，可以得到Redis3.2之后列表的简图：
quicklist和原始两种列表的对比
quicklist同样采用了linkedlist的双端列表特性，然后quicklist中的每个节点又是一个ziplist，所以quicklist就是综合平衡考虑了空间碎片和读写性能两个维度。
使用quicklist需要注意以下2点：
1、如果ziplist中的entry个数过少，极端情况就是只有1个entry，此时就相当于退化成了一个普通的linkedlist。
2、如果ziplist中的entry过多，那么也会导致一次性需要申请的内存空间过大，而且因为ziplist本身的就是以时间换空间，所以会过多entry也会影响到列表对象的读写性能。
ziplist中的entry个数可以通过参数list-max-ziplist-size来控制：
list-max-ziplist-size 1
这个参数可以配置正数也可以配置负数。正数表示限制每个节点中的entry数量，如果是负数则只能为-1~-5
-1:每个ziplist最多只能为4KB
-2:每个ziplist最多只能为8KB
-3:每个ziplist最多只能为16KB
-4:每个ziplist最多只能为32KB
-5:每个ziplist最多只能为64KB
Redis Lrange 返回列表中指定区间内的元素，区间以偏移量 START 和 END 指定。其中 0 表示列表的第一个元素，1 表示列表的第二个元素，以此类推。也可以使用负数下标，以 -1 表示列表的最后一个元素， -2 表示列表的倒数第二个元素，以此类推。
List数据类型应用：
timeline：例如微博的时间轴，有人发布微博，用lpush加入时间轴，展示新的列表信息。
三、Hash：哈希表类型
Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象。
Redis 中每个 hash 可以存储 2^32 - 1 键值对（40多亿）
Redis的哈希对象的底层存储可以使用ziplist（压缩列表）和hashtable。
当hash对象可以同时满足以下两个条件时，哈希对象使用ziplist编码
1.哈希对象保存的所有键值对的键和值的字符串长度都小于64字节
2.哈希对象保存的键值对数量小于512个
常见操作命令：
所有hash的命令都是h开头的 hget、hset、hdel等
Hash数据类型应用：
1、缓存：能直观，相比string更节省空间的维护缓存信息，如：用户信息，视频信息等。
四、Set：无序集合类型
Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据，将一个重复的元素添加到set中将会被忽略。
集合对象的编码可以是 intset 或者 hashtable。
Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储40多亿个成员)
集合类型也是用来保存多个字符串的元素，但和列表不同的是，集合中：
-
不允许有重复的元素
-
集合中的元素是无序的，不能通过索引下标获取元素
-
支持集合间的操作，可以取多个集合取交集、并集、差集
Set数据类型应用：
1、标签（tag）,给用户添加标签，或者用户给消息添加标签，这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人
2、点赞，或点踩，收藏等，可以放到set中实现
五、Sorted Set
Redis的sorted_set是有序集合，在set的基础上增加score属性用来排序
在redis中，数据类型对应的命令一般以数据类型的首字母开头，但是单词s已经被string类型使用了，所以sorted_set类型的相关命令只能使用26个英文字母中的最后一个字母z来开头，所以sorted_set也被称为zset。
有序集合和集合有着必然的联系，保留了集合不能有重复成员的特性，区别是，有序集合中的元素是可以排序的，它给每个元素设置一个分数，作为排序的依据。
（有序集合中的元素不可以重复，但是score 分数可以重复，就和一个班里的同学学号不能重复，但考试成绩可以相同）。
Sortedset底层存储结构：
Sortedset同时会由两种数据结构支持,ziplist和skiplist
只有同时满足如下条件时，使用的是ziplist，其他时候则是使用skiplist
1）有序集合保存的元素数量小于128个
2）有序集合保存的所有元素的长度小于64字节
当ziplist作为存储结构时候,每个集合元素使用两个紧挨在一起的压缩列表节点来保存,第一个节点保存元素的成员,第二个元素保存元素的分值.
当使用skiplist作为存储结构时,使用skiplist按序保存元素分值,使用dict来保存元素和分值的对应关系
关于skiplist
skiplist本质上是一个list, 它其实是由有序链表发展而来
我们先来看一个有序链表，如下图（最左侧的灰色节点表示一个空的头节点）：
在这样一个链表中，如果我们要查找某个数据，那么需要从头开始逐个进行比较，直到找到包含数据的那个节点，或者找到第一个比给定数据大的节点为止（没找到）。也就是说，时间复杂度为O(n)。同样，当我们要插入新数据的时候，也要经历同样的查找过程，从而确定插入位置
假如我们每相邻两个节点增加一个指针，让指针指向下下个节点，如下图：
这样所有新增加的指针连成了一个新的链表，但它包含的节点个数只有原来的一半（上图中是7, 19, 26）。现在当我们想查找数据的时候，可以先沿着这个新链表进行查找。当碰到比待查数据大的节点时，再回到原来的链表中进行查找。比如，我们想查找23，查找的路径是沿着下图中标红的指针所指向的方向进行的：
1）23首先和7比较，再和19比较，比它们都大，继续向后比较，当23和26比较的时候，比26要小，因此回到下面的链表（原链表），与22比较
2）23比22要大，沿下面的指针继续向后和26比较
3）23比26小，说明待查数据23在原链表中不存在，而且它的插入位置应该在22和26之间
在这个查找过程中，由于新增加的指针，我们不再需要与链表中每个节点逐个进行比较了。需要比较的节点数大概只有原来的一半。
利用同样的方式，我们可以在上层新产生的链表上，继续为每相邻的两个节点增加一个指针，从而产生第三层链表。如下图：
在这个新的三层链表结构上，如果我们还是查找23，那么沿着最上层链表首先要比较的是19，发现23比19大，接下来我们就知道只需要到19的后面去继续查找，从而一下子跳过了19前面的所有节点。可以想象，当链表足够长的时候，这种多层链表的查找方式能让我们跳过很多下层节点，大大加快查找的速度
skiplist正是受这种多层链表的想法的启发而设计出来的。实际上，按照上面生成链表的方式，上面每一层链表的节点个数，是下面一层的节点个数的一半，这样查找过程就非常类似于一个二分查找，使得查找的时间复杂度可以降低到O(log n)。但是，这种方法在插入数据的时候有很大的问题。新插入一个节点之后，就会打乱上下相邻两层链表上节点个数严格的2:1的对应关系。如果要维持这种对应关系，就必须把新插入的节点后面的所有节点（也包括新插入的节点）重新进行调整，这会让时间复杂度重新退化成O(n)，删除数据也有同样的问题。
skiplist为了避免这一问题，它不要求上下相邻两层链表之间的节点个数有严格的对应关系，而是为每个节点随机出一个层数(level)。比如，一个节点随机出的层数是3，那么就把它链入到第1层到第3层这三层链表中。为了表达清楚，下图展示了如何通过一步步地插入操作从而形成一个skiplist的过程：
从上面skiplist的创建和插入过程可以看出，每一个节点的层数（level）是随机出来的，而且新插入一个节点不会影响其它节点的层数。因此，插入操作只需要修改插入节点前后的指针，而不需要对很多节点都进行调整。这就降低了插入操作的复杂度。实际上，这是skiplist的一个很重要的特性，这让它在插入性能上明显优于平衡树的方案。
根据上图中的skiplist结构，我们很容易理解这种数据结构的名字的由来。skiplist，翻译成中文，可以翻译成“跳表”或“跳跃表”，指的就是除了最下面第1层链表之外，它会产生若干层稀疏的链表，这些链表里面的指针故意跳过了一些节点（而且越高层的链表跳过的节点越多）。这就使得我们在查找数据的时候能够先在高层的链表中进行查找，然后逐层降低，最终降到第1层链表来精确地确定数据位置。在这个过程中，我们跳过了一些节点，从而也就加快了查找速度。
刚刚创建的这个skiplist总共包含4层链表，现在假设我们在它里面依然查找23，下图给出了查找路径：
需要注意的是，前面演示的各个节点的插入过程，实际上在插入之前也要先经历一个类似的查找过程，在确定插入位置后，再完成插入操作。
至此，skiplist的查找和插入操作，我们已经很清楚了。而删除操作与插入操作类似，我们也很容易想象出来。这些操作我们也应该能很容易地用代码实现出来。
当然，实际应用中的skiplist每个节点应该包含key和value两部分。前面的描述中我们没有具体区分key和value，但实际上列表中是按照key进行排序的，查找过程也是根据key在比较。
zset数据类型应用：
1、排行榜：有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜，榜单可以按照用户关注数，更新时间，字数等打分，做排行
