大家好，我是三叔，很高兴这期又和大家见面了，一个奋斗在互联网的打工人。
这期给大家讲一下关于 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 类型的底层实现？
先说结果：
- C 语言的字符串不能保存二进制数据
- 时间复杂度
- 安全问题
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 的数据结构图：
- len，记录了字符串长度。这样获取字符串长度的时候，只需要返回这个成员变量值就行，时间复杂度只需要 O（1）；
- alloc，分配给字符数组的空间长度。这样在修改字符串的时候，可以通过 alloc - len 计算出剩余的空间大小，可以用来判断空间是否满足修改需求，如果不满足的话，就会自动将 SDS 的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用 SDS 既不需要手动修改 SDS 的空间大小，也不会出现前面所说的缓冲区溢出的问题；
- flags，用来表示不同类型的 SDS。能灵活保存不同大小的字符串，从而有效节省内存空间；
- 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 的成长历史就是一个不断地更新，解决性能问题的一个进步历史。
