Redis缓存的使用

迷茫的21世纪的新轻年

已于 2022-10-28 15:27:50 修改

阅读量874

点赞数

分类专栏：面试题文章标签： redis 缓存数据库

于 2022-10-28 15:27:23 首次发布

本文为博主：迷茫的21世纪的新轻年的原创文章，未经博主允许不得转载。

本文链接：https://blog.youkuaiyun.com/qq_36986510/article/details/127572603

版权

面试题专栏收录该内容

15 篇文章

订阅专栏

1、Redis有哪些类型

常用的五种数据类型：

String

String是最基本的数据类型，能够存储任何类型的字符串。单个字符串支持最大容量512M。
Hash

是有字符串类型的key/value组成的映射表，可以将它理解为包含多个键值对的集合。一般用来存储对象。
List

List中的元素是字符串类型，元素按照插入顺序进行排列，允许重复插入。
Set

Set的元素也是字符串类型，但是是无序集合。不允许重复插入。
Zset

Zset的元素也是字符串类型，是有序集合。集合中的元素具有唯一性，每一个元素还会关联一个double类型的分数（该分数允许重复）。根据该分数为集合中的成员排序。

2、Redis内部结构

2.1 Redis存储结构

外层依次往内：redisDb -> dict -> dictht -> dictEntry

redisDb默认16个。每一个redisDb包含一个dict。dict内部包含2个dictht的数组。dictht内部包含dictEntry数组。

2.2 Redis底层数据结构

String

Redis定义一个特殊结构SDS（Simple Dynamic String）：简单动态字符串；这是一个可以修改的内部结构，类似Java的ArrayList。

SDS结构定义如下：
```
struct sdshdr{
     //记录buf数组中已使用字符的数量，等于 SDS 保存字符串的长度
     int len;
     //记录 buf 数组中未使用的字符数量
     int free;
     //字符数组，用于保存字符串
     char buf[];
```
在 C语言中，字符串类型的结尾以空字符串 ‘\0’来标识的。但在某些情况下，字符串可能会包含具有实际意义的“空字符”，此时 C语言就无法正确的存取这个字符了，而 Redis 通过 len 来标识字符串的总长度，从而保证了数据的二进制安全特性。
Hash
- 存储的数据量较少时，使用zipList作为底层存储结构。要求：哈希对象保存的所有键值对（键和值）的字符串长度总和小于 64 个字节、哈希对象保存的键值对数量要小于 512 个
- 存储的数据量较大时，使用dict作为底层存储结构，类似Java中的HashMap。
List
- 存储的数据量较少时，使用zipList作为底层存储结构。要求：列表对象保存的所有字符串元素的长度小于64字节、列表对象保存的元素数量小于512个
- 存储的数据量较大时，使用linkedlist作为底层存储结构。
Set

两种存储结构相结合，intset和hashtable
- intset:集合内保存的所有成员都是整数值；集合内保存的成员数量不超过 512 个
- 不满足以上条件，则为hashtable
Zset
- zipList：成员的数量小于128 个、每个 member （成员）的字符串长度都小于 64 个字节
- 不满足以上条件，则为skipList

3、Redis使用场景

缓存
分布式环境下数据共享
分布式锁
全局ID
计数器

4、Redis持久化机制

4.1 RDB

又称快照（snapshot）模式，将数据库的快照保存在dump.rdb二进制文件中。

在Redis内部是一个定时器，定时判断数据改变是否达到触发持久化的条件。当满足触发条件时，通过操作系统调用fork()创建子进程，在子进程中遍历整个空间内存获取数据。

对Redis 中的数据执行周期性的持久化。

RDB更适合做冷备。

RDB持久化触发策略：

手动触发策略：通过SAVE、BGSAVE触发

自动触发策略：自动触发的条件包含在了 Redis 的配置文件中

#表示在 900 秒内，至少更新了 1 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
save 900 1
#表示在 300 秒内，至少更新了 10 条数据，Redis 自动触 BGSAVE 命令，将数据保存到硬盘。
save 300 10
#表示 60 秒内，至少更新了 10000 条数据，Redis 自动触发 BGSAVE 命令，将数据保存到硬盘。
save 60 10000

4.2 AOF

AOF 被称为追加模式，或日志模式，是 Redis 提供的另一种持久化策略，它能够存储 Redis 服务器已经执行过的的命令，并且只记录对内存有过修改的命令，这种数据记录方法，被叫做“增量复制”，其默认存储文件为appendonly.aof。

对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。

AOF更适合做热备。

Redis长期运行的过程中，aof文件会越来越长，可以通过BGREWRITEAOF进行aof文件重写，能够将aof进行一定的瘦身。

自动重写

#默认配置项 当 aof 文件的增量大于 100% 时才进行重写
auto-aof-rewrite-percentage 100
#表示触发AOF重写的最小文件体积,大于或等于64MB自动触发。
auto-aof-rewrite-min-size 64mb

AOF持久化策略配置：

appendfsync option

- Always：总是；每写入一个命令，就调用一次fsync（同步写入）函数。
- Everysec：每一秒（默认）；每一秒调用一次fsync函数。
- No：不主动调用，由操作系统进行决定。不确定。

5、Redis如何实现持久化

同4点

6、Redis集群方案与实现

6.1 主从模式

Redis 主机会一直将自己的数据复制给 Redis 从机，从而实现主从同步。

只有 master 主机可执行写命令，其他 salve 从机只能只能执行读命令，这种读写分离的模式可以大大减轻 Redis 主机的数据读取压力，从而提高了Redis 的效率，并同时提供了多个数据备份。主从模式是搭建 Redis Cluster 集群最简单的一种方式。

不足：

1) Redis 主从模式不具备自动容错和恢复功能，如果主节点宕机，Redis 集群将无法工作，此时需要人为干预，将从节点提升为主节点。
2) 如果主机宕机前有一部分数据未能及时同步到从机，即使切换主机后也会造成数据不一致的问题，从而降低了系统的可用性。
3) 因为只有一个主节点，所以其写入能力和存储能力都受到一定程度地限制。
4) 在进行数据全量同步时，若同步的数据量较大可能会造卡顿的现象。

6.2 哨兵模式（Sentinel）

哨兵模式弥补了主从模式的不足。Sentinel 通过监控的方式获取主机的工作状态是否正常，当主机发生故障时， Sentinel 会自动进行 Failover（即故障转移），并将其监控的从机提升主服务器（master），从而保证了系统的高可用性。

原理：

哨兵是一个独立的进程，能够独立运行。

哨兵节点以每秒一次的频率对每个Redis节点发送ping命令，通过Redis节点的回复来判断其运行状态。
哨兵监测到主服务器发送故障时，会自动从节点中选择一台机器升级为主服务器，然后使用PubSub发布订阅模式，通知其他的从节点，修改配置文件，跟随新的主服务器。

7、Redis为什么是单线程的

因为 Redis 是基于内存的操作，CPU不是 Redis的瓶颈。Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。

8、缓存崩溃

8.1 缓存穿透

指：当某个用户查询某个数据时，Redis不存在该数据，则会转向数据库进行查询，当数据库中也查询不到数据，则返回空对象。当该类请求过多时，会给数据库造成较大压力，甚至数据库奔溃。这就是缓存穿透。

8.2 缓存击穿

集中在某个数据，缓存过期时，所有请求都直接请求到数据库中，倍增的压力会导致数据库阻塞。

解决方案：

1、布隆过滤器

对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

2、缓存空对象

不论查询结果是否为空，都存入缓存中。但过期时间要设置短，避免影响占用。

8.3 缓存雪崩

缓存击穿是点的穿透，缓存雪崩是面的穿透。

同一时间内，大量缓存同时失效，导致数据库压力同一时间压力剧增。

解决方案：

1、加锁排队

在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

2、缓存时间增加随机值

不同失效时间，避免集体失效。

9、缓存降级

缓存降级对应用是有损的，对业务应用系统中不核心的缓存数据才能使用缓存降级。

当缓存系统挂掉后，会有大量的请求访问数据库，我们可以使用缓存降级不去访问数据库，直接返回默认值或者服务内的缓存数据。

10、使用缓存的合理性问题

通过几方面判断使用缓存的合理性：

是否热点数据：读取频率高的数据，有必要使用缓存。
是否频繁修改：频繁修改的数据，就没有必要使用缓存。