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可以根据元素的权重来排序,可以用来做一些排序类的操作
BitMapBitmap 类型非常适合二值状态统计的场景,这里的二值状态就是指集合元素的取值就只有 0 和 1 两种,比如上班打开,0未打卡,1 已打卡,类似这样的操作
HyperLogLogHyperLogLog 优势在于只需要花费 12 KB 内存,就可以计算接近 2^64 个元素的基数,和元素越多就越耗费内存的 Set 和 Hash 类型相比,HyperLogLog 就非常节省空间。非常适合统计百万级以上的网页 UV 的场景。
GEO主要用于存储地理位置信息,并对存储的信息进行操作,例如:滴滴打车、高德导航附近的位置等
Stream实现消息队列,相比于list,它支持消息的持久化、支持自动生成全局唯一 ID、支持 ack 确认消息的模式、支持消费组模式等,让消息队列更加的稳定和可靠

Redis数据结构

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

数据类型底层数据结构
StringSDS(simple dynamic string),单词翻译过来就是简单动态字符串
list双向链表或压缩列表,在 Redis 3.2 版本之后,List 数据类型底层数据结构就只由 quicklist 实现了,替代了双向链表和压缩列表。
hash压缩列表或哈希表(哈希表的底层其实就是类似数组之类的k-v数据结构),在 Redis 7.0 中,压缩列表数据结构已经废弃了,交由 listpack 数据结构来实现了。
SetSet 类型的底层数据结构是由哈希表或整数集合实现的
zsetZset 类型的底层数据结构是由压缩列表或跳表实现的,在 Redis 7.0 中,压缩列表数据结构已经废弃了,交由 listpack 数据结构来实现了
BitMapString 类型
HyperLogLog数据集合类型
GEOSorted 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 的成长历史就是一个不断地更新,解决性能问题的一个进步历史。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

我是三叔

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值