Redis数据结构_redis常用数据结构-优快云博客

本文链接：https://blog.youkuaiyun.com/ZERO141239/article/details/143104818

经典面试题-redis缓存穿透、缓存击穿、缓存雪崩

缓存穿透

缓存击穿

缓存雪崩

动态字符串（SDS）

Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String），简称SDS。例如，我们执行命令：

那么Redis将在底层创建两个SDS，其中一个是包含“name”的SDS，另一个是包含“虎哥”的SDS。

Redis是C语言实现的，其中SDS是一个结构体，源码如下：

例如，一个包含字符串“name”的sds结构如下：

SDS之所以叫做动态字符串，是因为它具备动态扩容的能力，例如一个内容为“hi”的SDS：

假如我们要给SDS追加一段字符串“,Amy”，这里首先会申请新内存空间：

如果新字符串小于1M，则新空间为扩展后字符串长度的两倍+1；

如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1。称为内存预分配。

Dict

我们知道Redis是一个键值型（Key-Value Pair）的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的。 Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

当我们向Dict添加键值对时，Redis首先根据key计算出hash值（h），然后利用 h & sizemask来计算元素应该存储到数组中的哪个索引位置。我们存储k1=v1，假设k1的哈希值h =1，则1&3 =1，因此k1=v1要存储到数组角标1位置。

Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

Dict的扩容

Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。 Dict在每次新增键值对时都会检查负载因子（LoadFactor = used/size），满足以下两种情况时会触发哈希表扩容：哈希表的 LoadFactor >= 1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程；哈希表的 LoadFactor > 5 ；

Dict的rehash

不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程称为rehash。过程是这样的：

计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩：
- 如果是扩容，则新size为第一个大于等于dict.ht[0].used + 1的2^n
- 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n （不得小于4）
按照新的realeSize申请内存空间，创建dictht，并赋值给dict.ht[1]
设置dict.rehashidx = 0，标示开始rehash
将dict.ht[0]中的每一个dictEntry都rehash到dict.ht[1]
将dict.ht[1]赋值给dict.ht[0]，给dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存
将rehashidx赋值为-1，代表rehash结束
在rehash过程中，新增操作，则直接写入ht[1]，查询、修改和删除则会在dict.ht[0]和dict.ht[1]依次查找并执行。这样可以确保ht[0]的数据只减不增，随着rehash最终为空

整个过程可以描述成：

小总结：

Dict的结构：

类似java的HashTable，底层是数组加链表来解决哈希冲突
Dict包含两个哈希表，ht[0]平常用，ht[1]用来rehash

Dict的伸缩：

当LoadFactor大于5或者LoadFactor大于1并且没有子进程任务时，Dict扩容
当LoadFactor小于0.1时，Dict收缩
扩容大小为第一个大于等于used + 1的2^n
收缩大小为第一个大于等于used 的2^n
Dict采用渐进式rehash，每次访问Dict时执行一次rehash
rehash时ht[0]只减不增，新增操作只在ht[1]执行，其它操作在两个哈希表

ZipList

ZipList 是一种特殊的“双端链表” ，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)。

属性	类型	长度	用途
zlbytes	uint32_t	4 字节	记录整个压缩列表占用的内存字节数
zltail	uint32_t	4 字节	记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址。
zllen	uint16_t	2 字节	记录了压缩列表包含的节点数量。最大值为UINT16_MAX （65534），如果超过这个值，此处会记录为65535，但节点的真实数量需要遍历整个压缩列表才能计算得出。
entry	列表节点	不定	压缩列表包含的各个节点，节点的长度由节点保存的内容决定。
zlend	uint8_t	1 字节	特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端。

ZipListEntry

ZipList 中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16个字节，浪费内存。而是采用了下面的结构：

previous_entry_length：前一节点的长度，占1个或5个字节。
- 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1个、2个或5个字节
contents：负责保存节点的数据，可以是字符串或整数

ZipList中所有存储长度的数值均采用小端字节序，即低位字节在前，高位字节在后。例如：数值0x1234，采用小端字节序后实际存储值为：0x3412

Encoding编码

ZipListEntry中的encoding编码分为字符串和整数两种：字符串：如果encoding是以“00”、“01”或者“10”开头，则证明content是字符串

编码	编码长度	字符串大小
\|00pppppp\|	1 bytes	<= 63 bytes
\|01pppppp\|qqqqqqqq\|	2 bytes	<= 16383 bytes
\|10000000\|qqqqqqqq\|rrrrrrrr\|ssssssss\|tttttttt\|	5 bytes	<= 4294967295 bytes

例如，我们要保存字符串：“ab”和 “bc”

ZipListEntry中的encoding编码分为字符串和整数两种：

整数：如果encoding是以“11”开始，则证明content是整数，且encoding固定只占用1个字节

编码	编码长度	整数类型
11000000	1	int16_t（2 bytes）
11010000	1	int32_t（4 bytes）
11100000	1	int64_t（8 bytes）
11110000	1	24位有符整数(3 bytes)
11111110	1	8位有符整数(1 bytes)
1111xxxx	1	直接在xxxx位置保存数值，范围从0001~1101，减1后结果为实际值

Redis五种基本数据结构

redis存储的是：key,value格式的数据，其中key都是字符串，value有5种不同的数据结构
其中value的五种基本数据结构：
字符串类型 string
哈希类型 hash ： map格式
列表类型 list ： linkedlist格式。支持重复元素
集合类型 set ：不允许重复元素
有序集合类型 sortedset：不允许重复元素，且元素有顺序

字符串类型 string

String是Redis中最常见的数据存储类型：

其基本编码方式是RAW，基于简单动态字符串（SDS）实现，存储上限为512mb。

如果存储的SDS长度小于44字节，则会采用EMBSTR编码，此时object head与SDS是一段连续空间。申请内存时

只需要调用一次内存分配函数，效率更高。

（1）底层实现⽅式：动态字符串sds 或者 long
String的内部存储结构⼀般是sds（Simple Dynamic String，可以动态扩展内存），但是如果⼀个String类型的value的值是数字，那么Redis内部会把它转成long类型来存储，从⽽减少内存的使用。

如果存储的字符串是整数值，并且大小在LONG_MAX范围内，则会采用INT编码：直接将数据保存在RedisObject的ptr指针位置（刚好8字节），不再需要SDS了。

常用指令：

命令	介绍
SET key value	设置指定 key 的值
SETNX key value	只有在 key 不存在时设置 key 的值
GET key	获取指定 key 的值
MSET key1 value1 key2 value2 …	设置一个或多个指定 key 的值
MGET key1 key2 ...	获取一个或多个指定 key 的值
STRLEN key	返回 key 所储存的字符串值的长度
INCR key	将 key 中储存的数字值增一
DECR key	将 key 中储存的数字值减一
EXISTS key	判断指定 key 是否存在
DEL key（通用）	删除指定的 key
EXPIRE key seconds（通用）	给指定 key 设置过期时间

哈希类型 hash

Redis 中的 Hash 是一个 String 类型的 field-value（键值对）的映射表，特别适合用于存储对象，后续操作的时候，可以直接修改这个对象中的某些字段的值。

Hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多(数组 + 链表)。不过，Redis 的 Hash 做了更多优化。

Hash 类型的底层数据结构是由压缩列表或哈希表实现的：

如果哈希类型元素个数小于 512 个（默认值，可由 hash-max-ziplist-entries 配置），所有值小于 64 字节（默认值，可由 hash-max-ziplist-value 配置）的话，Redis 会使用压缩列表作为 Hash 类型的底层数据结构；
如果哈希类型元素不满足上面条件，Redis 会使用哈希表作为 Hash 类型的底层数据结构。

在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

常用命令

命令	介绍
HSET key field value	设置指定哈希表中指定字段的值
HSETNX key field value	只有指定字段不存在时设置指定字段的值
HMSET key field1 value1 field2 value2 ...	同时将一个或多个 field-value (域-值)对设置到指定哈希表中
HGET key field	获取指定哈希表中指定字段的值
HMGET key field1 field2 ...	获取指定哈希表中一个或者多个指定字段的值
HGETALL key	获取指定哈希表中所有的键值对
HEXISTS key field	查看指定哈希表中指定的字段是否存在
HDEL key field1 field2 ...	删除一个或多个哈希表字段
HLEN key	获取指定哈希表中字段的数量

（1）底层实现方式：压缩列表ziplist 或者字典dict 当Hash中数据项比较少的情况下，Hash底层才⽤压缩列表ziplist进⾏存储数据，随着数据的增加，底层的ziplist就可能会转成dict，具体配置如下：

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

当满足上面两个条件其中之⼀的时候，Redis就使⽤dict字典来实现hash。 Redis的hash之所以这样设计，是因为当ziplist变得很⼤的时候，它有如下几个缺点：

每次插⼊或修改引发的realloc操作会有更⼤的概率造成内存拷贝，从而降低性能。
⼀旦发生内存拷贝，内存拷贝的成本也相应增加，因为要拷贝更⼤的⼀块数据。
当ziplist数据项过多的时候，在它上⾯查找指定的数据项就会性能变得很低，因为ziplist上的查找需要进行遍历。

总之，ziplist本来就设计为各个数据项挨在⼀起组成连续的内存空间，这种结构并不擅长做修改操作。⼀旦数据发⽣改动，就会引发内存realloc，可能导致内存拷贝。

hash结构如下：

列表类型 list

List 列表是简单的字符串列表，按照插入顺序排序，可以从头部或尾部向 List 列表添加元素。

列表的最大长度为 2^32 - 1，也即每个列表支持超过 40 亿个元素。

List 类型的底层数据结构是由双向链表或压缩列表实现的：

如果列表的元素个数小于 512 个（默认值，可由 list-max-ziplist-entries 配置），列表每个元素的值都小于 64 字节（默认值，可由 list-max-ziplist-value 配置），Redis 会使用压缩列表作为 List 类型的底层数据结构；
如果列表的元素不满足上面的条件，Redis 会使用双向链表作为 List 类型的底层数据结构；

但是在 Redis 3.2 版本之后，List 数据类型底层数据结构就只由 quicklist 实现了，替代了双向链表和压缩列表。

常用命令

命令	介绍
RPUSH key value1 value2 ...	在指定列表的尾部（右边）添加一个或多个元素
LPUSH key value1 value2 ...	在指定列表的头部（左边）添加一个或多个元素
LSET key index value	将指定列表索引 index 位置的值设置为 value
LPOP key	移除并获取指定列表的第一个元素(最左边)
RPOP key	移除并获取指定列表的最后一个元素(最右边)
LLEN key	获取列表元素数量
LRANGE key start end	获取列表 start 和 end 之间的元素

集合类型 set

Set是Redis中的单列集合，满足下列特点：

* 不保证有序性
* 保证元素唯一
* 求交集、并集、差集

Set 类型和 List 类型的区别如下：

List 可以存储重复元素，Set 只能存储非重复元素；
List 是按照元素的先后顺序存储元素的，而 Set 则是无序方式存储元素的。

Set 类型的底层数据结构是由哈希表或整数集合实现的：

如果集合中的元素都是整数且元素个数小于 512 （默认值，set-maxintset-entries配置）个，Redis 会使用整数集合作为 Set 类型的底层数据结构；
如果集合中的元素不满足上面条件，则 Redis 使用哈希表作为 Set 类型的底层数据结构。

常用命令

命令	介绍
SADD key member1 member2 ...	向指定集合添加一个或多个元素
SMEMBERS key	获取指定集合中的所有元素
SCARD key	获取指定集合的元素数量
SISMEMBER key member	判断指定元素是否在指定集合中
SINTER key1 key2 ...	获取给定所有集合的交集
SINTERSTORE destination key1 key2 ...	将给定所有集合的交集存储在 destination 中
SUNION key1 key2 ...	获取给定所有集合的并集
SUNIONSTORE destination key1 key2 ...	将给定所有集合的并集存储在 destination 中
SDIFF key1 key2 ...	获取给定所有集合的差集
SDIFFSTORE destination key1 key2 ...	将给定所有集合的差集存储在 destination 中
SPOP key count	随机移除并获取指定集合中一个或多个元素
SRANDMEMBER key count	随机获取指定集合中指定数量的元素

有序集合类型 sortedset

ZSet也就是SortedSet，其中每一个元素都需要指定一个score值和member值：

* 可以根据score值排序后
* member必须唯一
* 可以根据member查询分数

Zset 类型（有序集合类型）相比于 Set 类型多了一个排序属性 score（分值），对于有序集合 ZSet 来说，每个存储元素相当于有两个值组成的，一个是有序结合的元素值，一个是排序值。

有序集合保留了集合不能有重复成员的特性（分值可以重复），但不同的是，有序集合中的元素可以排序。

Zset 类型的底层数据结构是由压缩列表或跳表实现的：

如果有序集合的元素个数小于 128 个，并且每个元素的值小于 64 字节时，Redis 会使用压缩列表作为 Zset 类型的底层数据结构；
如果有序集合的元素不满足上面的条件，Redis 会使用跳表作为 Zset 类型的底层数据结构；

在 Redis 7.0 中，压缩列表数据结构已经废弃了，交由 listpack 数据结构来实现了。

常用命令

命令	介绍
ZADD key score1 member1 score2 member2 ...	向指定有序集合添加一个或多个元素
ZCARD KEY	获取指定有序集合的元素数量
ZSCORE key member	获取指定有序集合中指定元素的 score 值
ZINTERSTORE destination numkeys key1 key2 ...	将给定所有有序集合的交集存储在 destination 中，对相同元素对应的 score 值进行 SUM 聚合操作，numkeys 为集合数量
ZUNIONSTORE destination numkeys key1 key2 ...	求并集，其它和 ZINTERSTORE 类似
ZDIFF destination numkeys key1 key2 ...	求差集，其它和 ZINTERSTORE 类似
ZRANGE key start end	获取指定有序集合 start 和 end 之间的元素（score 从低到高）
ZREVRANGE key start end	获取指定有序集合 start 和 end 之间的元素（score 从高到底）
ZREVRANK key member	获取指定有序集合中指定元素的排名(score 从大到小排序)