redis数据类型和数据结构你了解吗 学习总结篇！

大家好，我是三叔，很高兴这期又和大家见面了，一个奋斗在互联网的打工人。

这期给大家讲一下关于 Redis 数据类型和数据结构的区别，很多读者包括笔者自己，早期也是傻傻分不清。备注：部分图片借鉴小林哥，懒得画图 ~

Redis数据类型

我们常说的 Redis 数据类型是指的 Redis 键值对中的值的类型，常见的 Redis 数据类型有：String、list、哈希表、set、zset；但是随着 Redis 版本的不断更新发展，又出现了一些新的数据类型，比如：BitMap、HyperLogLog、GEO、Stream等，这些数据类型在 Redis 官网中也有介绍。

数据类型的常用场景

数据类型	使用场景
String	缓存对象、缓存json数据、session共享、分布式锁等
list	消息队列（不太好用，List 不支持多个消费者消费同一条消息，后续的Stream类型可以支持）
哈希表	存储k-v类型的对象等
set	存储唯一，可以用来统计差集、交集等操作
Zset	可以根据元素的权重来排序，可以用来做一些排序类的操作
BitMap	Bitmap 类型非常适合二值状态统计的场景，这里的二值状态就是指集合元素的取值就只有 0 和 1 两种，比如上班打开，0未打卡，1 已打卡，类似这样的操作
HyperLogLog	HyperLogLog 优势在于只需要花费 12 KB 内存，就可以计算接近 2^64 个元素的基数，和元素越多就越耗费内存的 Set 和 Hash 类型相比，HyperLogLog 就非常节省空间。非常适合统计百万级以上的网页 UV 的场景。
GEO	主要用于存储地理位置信息，并对存储的信息进行操作，例如：滴滴打车、高德导航附近的位置等
Stream	实现消息队列，相比于list，它支持消息的持久化、支持自动生成全局唯一 ID、支持 ack 确认消息的模式、支持消费组模式等，让消息队列更加的稳定和可靠

Redis数据结构

Redis 的数据结构就是数据类型所对应的底层的数据结构，下面表展示的是不同数据类型所对应的数据结构：

数据类型	底层数据结构
String	SDS（simple dynamic string），单词翻译过来就是简单动态字符串
list	双向链表或压缩列表，在 Redis 3.2 版本之后，List 数据类型底层数据结构就只由 quicklist 实现了，替代了双向链表和压缩列表。
hash	压缩列表或哈希表（哈希表的底层其实就是类似数组之类的k-v数据结构），在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。
Set	Set 类型的底层数据结构是由哈希表或整数集合实现的
zset	Zset 类型的底层数据结构是由压缩列表或跳表实现的，在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了
BitMap	String 类型
HyperLogLog	数据集合类型
GEO	Sorted Set 集合类型
Stream	日志结构(append-only log)的数据结构，主要用于解决消息对了持久化

接下来我会针对具体的数据类型进行简单的分析。

String - SDS

Redis 是基于 C 语言来实现的，但是它没有直接使用 C 语言的 char* 来实现字符串，而是基于 C 语言进行封装的简单的动态字符串，也就是 SDS ，那么为什么不直接用 char* 来作为 String 类型的底层实现？

先说结果：

1. C 语言的字符串不能保存二进制数据
2. 时间复杂度
3. 安全问题

1. 存储类型

C 语言的 char* 字符串都会有一个 \0 特殊字符结尾，例如：char* name = “xiaolin”；实际上在 C 中，他是这样表示的：

在 C 语言里，对字符串操作时，char * 指针只是指向字符数组的起始位置，而字符数组的结尾位置就用“\0”表示，意思是指字符串的结束。

因此，在 C 语言中，字符串操作函数就通过判断字符是不是 “\0” 来决定要不要停止操作，如果当前字符不是 “\0” ，说明字符串还没结束，可以继续操作，如果当前字符是 “\0” 是则说明字符串结束了，就要停止操作。

所以问题来了，如果写入的字符串是：xiao\0lin，那么指针移动到 \0 的时候，你们说指针是继续移动还是结束移动？那必然是结束移动了。

2. 时间复杂度

C 语言获取字符串长度的函数 strlen，就是通过字符数组中的每一个字符，并进行计数，等遇到字符为 “\0” 后，就会停止遍历，然后返回已经统计到的字符个数，即为字符串长度。所以有多少长度字符串，它的指针就会从头到尾遍历下去，直到遇到 \0 结束遍历，所以时间复杂度是 O(n)。除了字符串的末尾之外，字符串里面不能含有 “\0” 字符，否则最先被程序读入的 “\0” 字符将被误认为是字符串结尾，这个限制使得 C 语言的字符串只能保存文本数据，不能保存像图片、音频、视频文化这样的二进制数据。

3. API安全性问题

C 语言的字符串是不会记录自身的缓冲区大小的，所以在进行函数拼接类操作的时候，如果不知道内存分配的大小，就会发生缓冲区溢出将可能会造成程序运行终止，这是一个很危险的操作，内存一旦分配好，不能再改变，很容易发生 OOM 。

所以针对这三点，SDS 优化了这些缺点，让它更好的兼容 Java 的使用环境，接下来让我们看看 SDS 是如何优化这些缺点的。

SDS 的优化

如下图所示，是 SDS 的数据结构图：

1. len，记录了字符串长度。这样获取字符串长度的时候，只需要返回这个成员变量值就行，时间复杂度只需要 O（1）；
2. alloc，分配给字符数组的空间长度。这样在修改字符串的时候，可以通过 alloc - len 计算出剩余的空间大小，可以用来判断空间是否满足修改需求，如果不满足的话，就会自动将 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现前面所说的缓冲区溢出的问题；
3. flags，用来表示不同类型的 SDS。能灵活保存不同大小的字符串，从而有效节省内存空间；
4. buf[]，字符数组，用来保存实际数据。SDS 的 API 都是以处理二进制的方式来处理 SDS 存放在 buf[] 里的数据，程序不会对其中的数据做任何限制，数据写入的时候时什么样的，它被读取时就是什么样的。

链表

Redis 的 List 对象的底层实现之一就是链表。C 语言本身没有链表这个数据结构的，所以 Redis 自己设计了一个链表数据结构。

笔者在算法专栏中，虚拟头节点一文中，有介绍过链表是什么，这篇博客就不再赘述。

链表每个节点之间的内存都是不连续的，意味着无法很好利用 CPU 缓存。保存一个链表节点的值都需要一个链表节点结构头的分配，内存开销较大。

List 对象在数据量比较少的情况下，会采用压缩列表作为底层数据结构的实现，它的优势是节省内存空间，并且是内存紧凑型的数据结构。

随着 Redis 的发展进步，在 3.2 版本设计了新的数据结构 quicklist，并将 List 对象的底层数据结构改由 quicklist 实现。然后在 Redis 5.0 设计了新的数据结构 listpack，在最新的 Redis 版本，将 Hash 对象和 Zset 对象的底层数据结构实现之一的压缩列表，替换成由 listpack 实现。

压缩列表

压缩列表的最大特点，就是它被设计成一种内存紧凑型的数据结构，占用一块连续的内存空间（这一点有点类似于数组的连续性特性），不仅可以利用 CPU 缓存，而且会针对不同长度的数据，进行相应编码，这种方法可以有效地节省内存开销。

压缩列表也有缺陷，数据一旦变多，就会导致压缩列表占用的内存空间要多次重新分配，这就会直接影响到压缩列表的访问性能。

压缩列表新增某个元素或修改某个元素时，如果空间不不够，压缩列表占用的内存空间就需要重新分配。而当新插入的元素较大时，可能会导致后续元素的 prevlen 占用空间都发生变化，从而引起连锁更新问题，导致每个元素的空间都要重新分配，造成访问压缩列表性能的下降。

prevlen，记录了「前一个节点」的长度；
encoding，记录了当前节点实际数据的类型以及长度；
data，记录了当前节点的实际数据；

哈希表

笔者在算法专栏什么是哈希表一文中有介绍过哈希表，这里也不再赘述。

quicklist

其实 quicklist 就是「双向链表 + 压缩列表」组合，因为一个 quicklist 就是一个链表，而链表中的每个元素又是一个压缩列表。quicklist 解决办法，通过控制每个链表节点中的压缩列表的大小或者元素个数，来规避连锁更新的问题。因为压缩列表元素越少或越小，连锁更新带来的影响就越小，从而提供了更好的访问性能。

quicklistNode 结构体里包含了前一个节点和下一个节点指针，这样每个 quicklistNode 形成了一个双向链表。但是链表节点的元素不再是单纯保存元素值，而是保存了一个压缩列表，所以 quicklistNode 结构体里有个指向压缩列表的指针。

如下图所示：可以看出，就是一个链表，在链表的基础上有个指针指向了压缩列表。

quicklist 添加一个元素的时候，不会像普通的链表那样，直接新建一个链表节点。而是会检查插入位置的压缩列表是否能容纳该元素，如果能容纳就直接保存到 quicklistNode 结构里的压缩列表，如果不能容纳，才会新建一个新的 quicklistNode 结构。

listpack

quicklistNode 还是用了压缩列表来保存元素，压缩列表连锁更新的问题，来源于它的结构设计，所以要想彻底解决这个问题，需要设计一个新的数据结构。listpack有点类似数组的味道了，如下图所示：

encoding，定义该元素的编码类型；
data，实际存放的数据；
len，encoding+data的总长度；

listpack 没有压缩列表中记录前一个节点长度的字段了，干掉了 prevlen ，listpack 只记录当前节点的长度，向 listpack 加入一个新元素的时候，不会影响其他节点的长度字段的变化，从而避免了压缩列表的连锁更新问题。

总结

可以看出 Redis 的成长历史就是一个不断地更新，解决性能问题的一个进步历史。