标签：存储 基本原理 元素 Redis 链表 哈希 字符串 数据结构

一、Redis 简介

Redis 是一个开源，高级的键值存储和一个适用的解决方案，用于构建高性能，可扩展的 Web 应用程序。Redis 也被作者戏称为 数据结构服务器 ，这意味着使用者可以通过一些命令，基于带有 TCP 套接字的简单 服务器-客户端 协议来访问一组 可变数据结构 。(在 Redis 中都采用键值对的方式，只不过对应的数据结构不一样罢了)

Redis 的优点

以下是 Redis 的一些优点：

• 异常快 - Redis 非常快，每秒可执行大约 110000 次的设置(SET)操作，每秒大约可执行 81000 次的读取/获取(GET)操作。

• 支持丰富的数据类型 - Redis 支持开发人员常用的大多数数据类型，例如列表，集合，排序集和散列等等。这使得 Redis 很容易被用来解决各种问题，因为我们知道哪些问题可以更好使用地哪些数据类型来处理解决。

• 操作具有原子性 - 所有 Redis 操作都是原子操作，这确保如果两个客户端并发访问，Redis 服务器能接收更新的值。

• 多实用工具 - Redis 是一个多实用工具，可用于多种用例，如：缓存，消息队列(Redis 本地支持发布/订阅)，应用程序中的任何短期数据，例如，web应用程序中的会话，网页命中计数等。

Redis 五种基本数据结构

Redis 有 5 种基础数据结构，它们分别是：string(字符串)、list(列表)、hash(字典)、set(集合) 和 zset(有序集合)。这 5 种是 Redis 相关知识中最基础、最重要的部分，下面我们结合源码以及一些实践来给大家分别讲解一下。

二、String 字符串

Redis 中的字符串是一种 动态字符串，这意味着使用者可以修改，它的底层实现有点类似于 Java 中的 ArrayList，有一个字符数组。

2.1、存储类型

可以用来存储字符串、整数、浮点数

2.2、使用场景

缓存

在web服务中，使用MySQL作为数据库，Redis作为缓存。由于Redis具有支撑高并发的特性，通常能起到加速读写和降低后端压力的作用。web端的大多数请求都是从Redis中获取的数据，如果Redis中没有需要的数据，则会从MySQL中去获取，并将获取到的数据写入redis。

 计数

Redis中有一个字符串相关的命令incr key，incr命令对值做自增操作，返回结果分为以下三种情况：

• 值不是整数，返回错误

• 值是整数，返回自增后的结果

• key不存在，默认键为0，返回1

比如文章的阅读量，视频的播放量等等都会使用redis来计数，每播放一次，对应的播放量就会加1，同时将这些数据异步存储到数据库中达到持久化的目的。

共享Session

在分布式系统中，用户的每次请求会访问到不同的服务器，这就会导致session不同步的问题，假如一个用来获取用户信息的请求落在A服务器上，获取到用户信息后存入session。下一个请求落在B服务器上，想要从session中获取用户信息就不能正常获取了，因为用户信息的session在服务器A上，为了解决这个问题，使用redis集中管理这些session，将session存入redis，使用的时候直接从redis中获取就可以了。

 限速

为了安全考虑，有些网站会对IP进行限制，限制同一IP在一定时间内访问次数不能超过n次。

2.3、存储（实现）原理 外层的哈希

数据模型 set hello word 为例，因为 Redis 是 KV 的数据库，它是通过 hashtable 实现的（我 们把这个叫做外层的哈希）。所以每个键值对都会有一个 dictEntry（源码位置：dict.h）， 里面指向了 key 和 value 的指针。next 指向下一个 dictEntry。

key 是字符串，但是 Redis 没有直接使用 C 的字符数组，而是存储在自定义的 SDS 中。

value 既不是直接作为字符串存储，也不是直接存储在 SDS 中，而是存储在 redisObject 中。实际上五种常用的数据类型的任何一种，都是通过 redisObject 来存储 的。

      

2.4、redisObject value存储

redisObject 定义在 src/server.h 文件中。

2.5、内部编码有三种

1、int，存储 8 个字节的长整型（long，2^63-1）。

2、embstr, 代表 embstr 格式的 SDS（Simple Dynamic String 简单动态字符串）， 存储小于 44 个字节的字符串。

3、raw，存储大于 44 个字节的字符串（3.2 版本之前是 39 字节）。

问题 1、什么是 SDS？

Redis 中字符串的实现。 在 3.2 以后的版本中，SDS 又有多种结构（sds.h）：sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64，用于存储不同的长度的字符串，分别代表 2^5=32byte， 2^8=256byte，2^16=65536byte=64KB，2^32byte=4GB。

因为当字符串比较短的时候，len 和 alloc 可以使用 byte 和 short 来表示，Redis 为了对内存做极致的优化，不同长度的字符串使用不同的结构体来表示。

问题 2、为什么 Redis 要用 SDS 实现字符串？

为什么不考虑直接使用 C 语言的字符串呢？因为 C 语言这种简单的字符串表示方式 不符合 Redis 对字符串在安全性、效率以及功能方面的要求。我们知道，C 语言使用了一个长度为 N+1 的字符数组来表示长度为 N 的字符串，并且字符数组最后一个元素总是 '\0'。

这样简单的数据结构可能会造成以下一些问题：

• 获取字符串长度为 O(N) 级别的操作 → 因为 C 不保存数组的长度，每次都需要遍历一遍整个数组；

• 不能很好的杜绝 缓冲区溢出/内存泄漏 的问题 → 跟上述问题原因一样，如果执行拼接 or 缩短字符串的操作，如果操作不当就很容易造成上述问题；

• C 字符串 只能保存文本数据 → 通过从字符串开始到结尾碰到的第一个'\0'来标记字符串的结束，因此不能保 存图片、音频、视频、压缩文件等二进制(bytes)保存的内容，二进制不安全。

SDS 的特点：

•  1、不用担心内存溢出问题，如果需要会对 SDS 进行扩容。
• 2、获取字符串长度时间复杂度为 O(1)，因为定义了 len 属性。
• 3、通过“空间预分配”（ sdsMakeRoomFor）和“惰性空间释放”，防止多 次重分配内存。
• 4、判断是否结束的标志是 len 属性（它同样以'\0'结尾是因为这样就可以使用 C语言中函数库操作字符串的函数了），可以包含'\0'。

C 字符串	SDS
获取字符串长度的复杂度为 O(N)	获取字符串长度的复杂度为 O(1)
API 是不安全的，可能会造成缓冲区溢出	API 是安全的，不会造成个缓冲区溢出
修改字符串长度 N 次必然需要执行 N 次内存重分配	修改字符串长度 N 次最多需要执行 N 次内存重分配
只能保存文本数据	可以保存文本或者二进制数据
可以使用所有库中的函数	可以使用一部分库中的函数

问题 3、embstr 和 raw 的区别？

embstr 的使用只分配一次内存空间（因为 RedisObject 和 SDS 是连续的），而 raw 需要分配两次内存空间（分别为 RedisObject 和 SDS 分配空间）。

因此与 raw 相比，embstr 的好处在于创建时少分配一次空间，删除时少释放一次 空间，以及对象的所有数据连在一起，寻找方便。

而 embstr 的坏处也很明显，如果字符串的长度增加需要重新分配内存时，整个 RedisObject 和 SDS 都需要重新分配空间，因此 Redis 中的 embstr 实现为只读。

问题 4：int 和 embstr 什么时候转化为 raw？

当 int 数 据 不 再 是 整 数 ， 或 大 小 超 过 了 long 的 范 围 （2^63-1=9223372036854775807）时，自动转化为 embstr。

embstr 超过44个字节或者 value值被修改

问题 5：明明没有超过阈值，为什么变成 raw 了？

对于 embstr，由于其实现是只读的，因此在对 embstr 对象进行修改时，都会先 转化为 raw 再进行修改。

因此，只要是修改 embstr 对象，修改后的对象一定是 raw 的，无论是否达到了 44 个字节。

问题 6：当长度小于阈值时，会还原吗？

关于 Redis 内部编码的转换，都符合以下规律：编码转换在 Redis 写入数据时完 成，且转换过程不可逆，只能从小内存编码向大内存编码转换（但是不包括重新 set）。

问题 7：为什么要对底层的数据结构进行一层包装呢？

通过封装，可以根据对象的类型动态地选择存储结构和可以使用的命令，实现节省 空间和优化查询速度。

三、Hash 哈希

Redis 中的字典相当于 Java 中的 HashMap，内部实现也差不多类似，都是通过 "数组 + 链表" 的链地址法来解决部分 哈希冲突，同时这样的结构也吸收了两种不同数据结构的优点。

3.1、存储类型

 包含键值对的无序散列表。value 只能是字符串，不能嵌套其他类型。

同样是存储字符串，Hash 与 String 的主要区别？

• 1、把所有相关的值聚集到一个 key 中，节省内存空间
• 2、只使用一个 key，减少 key 冲突
• 3、当需要批量获取值的时候，只需要使用一个命令，减少内存/IO/CPU 的消耗

Hash 不适合的场景：

• 1、Field 不能单独设置过期时间
• 2、没有 bit 操作
• 3、需要考虑数据量分布的问题（value 值非常大的时候，无法分布到多个节点）

3.2、使用场景

由于hash类型存储的是一个键值对，比如数据库有以下一个用户表结构

将以上信息存入redis，用表明:id作为key，用户属性作为值：

hset user:1 name Java旅途 age 18

使用哈希存储会比字符串更加方便直观

3.3、存储（实现）原理

外层的哈希（Redis KV 的实现）只用到了 hashtable。当存储 hash 数据类型时， 我们把它叫做内层的哈希。

内层的哈希底层可以使用两种数据结构实现：

ziplist：OBJ_ENCODING_ZIPLIST（压缩列表）

hashtable：OBJ_ENCODING_HT（哈希表）

3.4.1、ziplist（压缩列表）

      ziplist 是一个经过特殊编码的双向链表，它不存储指向上一个链表节点和指向下一 个链表节点的指针，而是存储上一个节点长度和当前节点长度，通过牺牲部分读写性能， 来换取高效的内存空间利用率，是一种时间换空间的思想。只用在字段个数少，字段值 小的场景里面。

ziplist 的内部结构

其内存存储如下：

问题：什么时候使用 ziplist 存储？

当 hash 对象同时满足以下两个条件的时候，使用 ziplist 编码：

1）所有的键值对的健和值的字符串长度都小于等于 64byte（一个英文字母 一个字节）；

2）哈希对象保存的键值对数量小于 512 个。

3.4.2、hashtable（dict）

在 Redis 中，hashtable 被称为字典（dictionary），它是一个数组+链表的结构。 源码位置：dict.h

前面我们知道了，Redis 的 KV 结构是通过一个 dictEntry 来实现的。 Redis 又对 dictEntry 进行了多层的封装

dictEntry 放到了 dictht（hashtable 里面）：

ht 放到了 dict 里面：

从最底层到最高层 dictEntry——dictht——dict——OBJ_ENCODING_HT

总结：哈希的存储结构：

可以从上面的源码中看到，实际上字典结构的内部包含两个 hashtable，通常情况下只有一个 hashtable 是有值的，但是在字典扩容缩容时，需要分配新的 hashtable，然后进行 渐进式搬迁 (下面说原因)。

问题1：为什么要定义两个哈希表呢？ht[2]

redis 的 hash 默认使用的是 ht[0]，ht[1]不会初始化和分配空间。

哈希表 dictht 是用链地址法来解决碰撞问题的。在这种情况下，哈希表的性能取决于它的大小（size 属性）和它所保存的节点的数量（used 属性）之间的比率：

• 比率在 1:1 时（一个哈希表 ht 只存储一个节点 entry），哈希表的性能最好；
• 如果节点数量比哈希表的大小要大很多的话（这个比例用 ratio 表示，5 表示平均一个 ht 存储 5 个 entry），那么哈希表就会退化成多个链表，哈希表本身的性能 优势就不再存在。

问题2：扩容 (渐进式rehash)步骤

大字典的扩容是比较耗时间的，需要重新申请新的数组，然后将旧字典所有链表中的元素重新挂接到新的数组下面，这是一个 O(n) 级别的操作，作为单线程的 Redis 很难承受这样耗时的过程，所以 Redis 使用 渐进式 rehash 小步搬迁：

渐进式 rehash 会在 rehash 的同时，保留新旧两个 hash 结构，如上图所示，查询时会同时查询两个 hash 结构，然后在后续的定时任务以及 hash 操作指令中，循序渐进的把旧字典的内容迁移到新字典中。当搬迁完成了，就会使用新的 hash 结构取而代之。

rehash 的步骤：

• 1、为字符 ht[1]哈希表分配空间，这个哈希表的空间大小取决于要执行的操作，以 及 ht[0]当前包含的键值对的数量。 扩展：ht[1]的大小为第一个大于等于 ht[0].used*2。
• 2、将所有的 ht[0]上的节点 rehash 到 ht[1]上，重新计算 hash 值和索引，然后放 入指定的位置。
• 3、当 ht[0]全部迁移到了 ht[1]之后，释放 ht[0]的空间，将 ht[1]设置为 ht[0]表， 并创建新的 ht[1]，为下次 rehash 做准备

问题3：什么时候触发扩容？

正常情况下，当 hash 表中 元素的个数等于第一维数组的长度时，就会开始扩容，扩容的新数组是 原数组大小的 2 倍。不过如果 Redis 正在做 bgsave(持久化命令)，为了减少内存也得过多分离，Redis 尽量不去扩容，但是如果 hash 表非常满了，达到了第一维数组长度的 5 倍了，这个时候就会 强制扩容。

当 hash 表因为元素逐渐被删除变得越来越稀疏时，Redis 会对 hash 表进行缩容来减少 hash 表的第一维数组空间占用。所用的条件是 元素个数低于数组长度的 10%，缩容不会考虑 Redis 是否在做 bgsave。

四、List 列表

Redis 的列表相当于 Java 语言中的 LinkedList，注意它是链表而不是数组。这意味着 list 的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为 O(n)。

4.1、存储类型

存储有序的字符串（从左到右），元素可以重复。可以充当队列和栈的角色。

4.2、使用场景

消息队列

列表用来存储多个有序的字符串，既然是有序的，那么就满足消息队列的特点。使用lpush+rpop或者rpush+lpop实现消息队列。除此之外，redis支持阻塞操作，在弹出元素的时候使用阻塞命令来实现阻塞队列。

栈

由于列表存储的是有序字符串，满足队列的特点，也就能满足栈先进后出的特点，使用lpush+lpop或者rpush+rpop实现栈。

文章列表

因为列表的元素不但是有序的，而且还支持按照索引范围获取元素。因此我们可以使用命令lrange key 0 9分页获取文章列表

4.3、存储（实现）原理

在早期的版本中，数据量较小时用 ziplist 存储，达到临界值时转换为 linkedlist 进 行存储，分别对应 OBJ_ENCODING_ZIPLIST 和 OBJ_ENCODING_LINKEDLIST 。

3.2 版本之后，统一用 quicklist 来存储。quicklist 存储了一个双向链表，每个节点 都是一个 ziplist

4.3.1、quicklist

quicklist（快速列表）是 ziplist 和 linkedlist 的结合体。

quicklist.h，head 和 tail 指向双向列表的表头和表尾。

quicklistNode 中的*zl 指向一个 ziplist，一个 ziplist 可以存放多个元素。

整体实现图统一用 quicklist 来存储。quicklist 存储了一个双向链表，每个节点 都是一个 ziplist

4.4、链表的基本操作

• LPUSH 和 RPUSH 分别可以向 list 的左边（头部）和右边（尾部）添加一个新元素；

• LRANGE 命令可以从 list 中取出一定范围的元素；

• LINDEX 命令可以从 list 中取出指定下表的元素，相当于 Java 链表操作中的 get(int index) 操作；

五、集合SET

集合类型也可以保存多个字符串元素，与列表不同的是，集合中不允许有重复元素并且集合中的元素是无序的。一个集合最多可以存储2^32-1个元素。

5.1、存储类型

String 类型的无序集合，最大存储数量 2^32-1（40 亿左右）。

5.2、应用场景

 用户标签

例如一个用户对篮球、足球感兴趣，另一个用户对橄榄球、乒乓球感兴趣，这些兴趣点就是一个标签。有了这些数据就可以得到喜欢同一个标签的人，以及用户的共同感兴趣的标签。给用户打标签的时候需要①给用户打标签，②给标签加用户，需要给这两个操作增加事务。

• 给用户打标签

sadd user:1:tags tag1 tag2

• 给标签添加用户

sadd tag1:users user:1

sadd tag2:users user:1

使用交集（sinter）求两个user的共同标签

sinter user:1:tags user:2:tags

 抽奖功能

集合有两个命令支持获取随机数，分别是：

• 随机获取count个元素，集合元素个数不变

srandmember key [count]

• 随机弹出count个元素，元素从集合弹出，集合元素个数改变

spop key [count]

用户点击抽奖按钮，参数抽奖，将用户编号放入集合，然后抽奖，分别抽一等奖、二等奖，如果已经抽中一等奖的用户不能参数抽二等奖则使用spop，反之使用srandmember。

5.3、存储（实现）原理

Redis 用 intset 或 hashtable 存储 set。如果元素都是整数类型，就用 inset 存储。 如果不是整数类型，就用 hashtable（数组+链表的存来储结构）。

问题：KV 怎么存储 set 的元素？key 就是元素的值，value 为 null。 如果元素个数超过 512 个，也会用 hashtable 存储

六：有序列表 zset

有序集合和集合一样，不能有重复元素。但是可以排序，它给每个元素设置一个score作为排序的依据。最多可以存储2^32-1个元素。

这可能使 Redis 最具特色的一个数据结构了，它类似于 Java 中 SortedSet 和 HashMap 的结合体，一方面它是一个 set，保证了内部 value 的唯一性，另一方面它可以为每个 value 赋予一个 score 值，用来代表排序的权重。

6.1、使用场景

排行榜

用户发布了n篇文章，其他人看到文章后给喜欢的文章点赞，使用score来记录点赞数，有序集合会根据score排行。流程如下

用户发布一篇文章，初始点赞数为0，即score为0

zadd user:article 0 a

有人给文章a点赞，递增1

zincrby user:article 1 a

查询点赞前三篇文章

zrevrangebyscore user:article 0 2

查询点赞后三篇文章

zrangebyscore user:article 0 2

延迟消息队列

下单系统，下单后需要在15分钟内进行支付，如果15分钟未支付则自动取消订单。将下单后的十五分钟后时间作为score，订单作为value存入redis，消费者轮询去消费，如果消费的大于等于这笔记录的score，则将这笔记录移除队列，取消订单。

6.2、实现原理

有序集合类型的内部编码有两种：

• ziplist（压缩列表）：当有序集合的元素个数小于list-max-ziplist-entries配置（默认128个）同时所有值都小于list-max-ziplist-value配置（默认64字节）时使用。ziplist使用更加紧凑的结构实现多个元素的连续存储，更加节省内存。

• skiplist（跳跃表）：当不满足ziplist的要求时，会使用skiplist。

6.3.1、skiplist+dict 存储

skiplist编码的有序集合对象底层实现是跳跃表和字典两种：

• 1、每个跳跃表节点都保存一个集合元素，并按分值从小到大排列；节点的object属性保存了元素的成员，score属性保存分值；
• 2、字典的每个键值对保存一个集合元素，字典的键保存元素的成员，字典的值保存分值。

为何skiplist编码要同时使用跳跃表和字典实现？

• 跳跃表优点是有序，但是查询分值复杂度为O(logn)；
• 字典查询分值复杂度为O(1) ，但是无序，所以结合连个结构的有点进行实现。

虽然采用两个结构但是集合的元素成员和分值是共享的，两种结构通过指针指向同一地址，不会浪费内存。

问题：什么是 skiplist？

参考：https://mp.weixin.qq.com/s?__biz=MzAwNDA2OTM1Ng==&mid=2453141687&idx=2&sn=23936a54d263d56cf26972a00a287feb&scene=21#wechat_redirect

我们先来看一下有序链表：

在这样一个链表中，如果我们要查找某个数据，那么需要从头开始逐个进行比较， 直到找到包含数据的那个节点，或者找到第一个比给定数据大的节点为止（没找到）。 也就是说，时间复杂度为 O(n)。同样，当我们要插入新数据的时候，也要经历同样的查 找过程，从而确定插入位置。

而二分查找法只适用于有序数组，不适用于链表。

假如我们每相邻两个节点增加一个指针（或者理解为有三个元素进入了第二层），

让指针指向下下个节点。

这样所有新增加的指针连成了一个新的链表，但它包含的节点个数只有原来的一半 （上图中是 7, 19, 26）。在插入一个数据的时候，决定要放到那一层，取决于一个算法 （在 redis 中 t_zset.c 有一个 zslRandomLevel 这个方法）。

现在当我们想查找数据的时候，可以先沿着这个新链表进行查找。当碰到比待查数 据大的节点时，再回到原来的链表中的下一层进行查找。比如，我们想查找 23，查找的路径是沿着下图中标红的指针所指向的方向进行的：

• 1. 23 首先和 7 比较，再和 19 比较，比它们都大，继续向后比较。
• 2. 但 23 和 26 比较的时候，比 26 要小，因此回到下面的链表（原链表），与 22 比较。
• 3. 23 比 22 要大，沿下面的指针继续向后和 26 比较。23 比 26 小，说明待查数 据 23 在原链表中不存在 在这个查找过程中，由于新增加的指针，我们不再需要与链表中每个节点逐个进行 比较了。需要比较的节点数大概只有原来的一半。这是跳跃表。

为什么不用 AVL 树或者红黑树？因为 skiplist 更加简洁。

编码转换总结

 

参考：咕泡学院架构视频

 

 

标签：存储,基本原理,元素,Redis,链表,哈希,字符串,数据结构
来源： https://blog.csdn.net/qq_36697880/article/details/110631341

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。