Redis常见面试题（附答案）

最新推荐文章于 2024-04-18 20:39:42 发布

qq_44802827

最新推荐文章于 2024-04-18 20:39:42 发布

阅读量721

点赞数 1

文章标签： redis java 微服务

本文链接：https://blog.csdn.net/qq_44802827/article/details/129055527

版权

Redis

redis是一个基于内存的key-value数据库，主要可以用于数据库存储数据，数据持久化，缓存，集群。

Redis4.0之前是单线程，所以没有线程安全问题；

Redis4.0之后提供了多线程，仅针对于后台一些功能【主从复制、持久化.......】；

Redis6.0之后提供了多线程，仅针对于网络传输

Redis的多线程默认是关闭的，除非达到瓶颈，否则不用开

1.Redis的五种数据类型及应用场景

值的五种类型：

String：key，value

Hash：key；key1，value1；key2，value2...

list：key，list 有序

set：key，list 无序，不重复

zset：key，score，list 。 Set是无序的集合，Zset是有序的集合。

应用场景：

String --- 验证码、分布式session、计数器incr（文章阅读数、点赞数，将值 + 1）、缓存热点数据
hash --- 购物车
list --- 队列
set --- 微信朋友圈
zset --- 排行榜

2.Redis持久化机制

redis中的数据全部保存在内存中,如果突然宕机,数据就会全部丢失.为了防止这种事情发生,我们需要一种机制保证在宕机发生之后,我们重启服务,内存中的数据还可以恢复,这就是redis的持久化机制. 对应产生的数据文件为dump.rdb

　 redis提供了三种持久化机制分别为RDB(Redis DataBase)方式,AOF(Append Only File)方式和混合模式.

持久化机制：

1.RDB（默认持久化模式）：

会根据配置的规则进行定时快照备份；优点：

快照数据以二进制存储、文件小、恢复速度快；

缺点：

耗费时间，耗费性能，会丢失一定的数据，不可控

原理：

Redis 会在某一时刻触发并将内存中所有的数据以二进制的方式保存在一个 dump.rdb 文件里，这也是 Redis 默认的持久化方式。

持久化策略：

redis持久化需要条件触发：可以修改conf文件中配置save的参数 “ save <seconds><changes>” 如果我配置成了 save 60 10000 ，那就是代表如果在 60s 内执行了 10000 条修改命令，就会触发RDB持久化 .

手动触发：客户端执行save命令

besave命令： Redis 是单线程的，因此 save 命令在做持久化的时候时候会阻塞其他命令的执行，属于同步执行。bgsave 则会从主线程中另外 fork 出一个子线程进行持久化操作，从而不会阻塞其他命令的执行，属于异步执行

上面讲的自动触发持久化也是通过 bgsave 的方式来进行的

2.AOF（默认关闭）：

AOF持久化就是Redis在持久化数据的时候会把修改数据的命令通过追加的方式保存到 aof 文件中，在宕机恢复的时候通过执行 aof 文件中的命令来恢复数据以日志的形式记录key发送变化的指令；

优点：

数据以命令的形式存储，数据不容易丢失。文件会重写，去除无用指令，优化数据最终得到的结果即可。

缺点：

AOF文件可能会被篡改，文件大、恢复速度慢

持久化策略：

appendfsync always: 每次有新命令追加到 AOF 文件时就执行一次 fsync，数据持久化非常慢，也非常安全

appendfsync everysec: 每秒 fsync 一次，足够快，并且在故障时也只会丢失 1 秒钟的数据，这个是redis默认的持久化策略

appendfsync no: 从不 fsync ，将数据交给操作系统来处理。更快，也更不安全的选择

如果在持久化的时候要想要在持久化的速度和数据安全之间来权衡的话，可以选择第二种

RDB+AOF：

AOF + aof文件在压缩时以RDB去存储（二进制存储）

不持久化

持久化：把数据保存在磁盘上

数据恢复：先恢复AOF，再补充RDB

3.混合模式（RDB+AOF 推荐使用）

3.Redis淘汰策略

Redis数据存储在内存，如果内存满了会触发淘汰策略。

淘汰策略

volatile-lru: 在内存不足时，Redis会在设置过了生存时间**的key**中干掉一个最近最少使用的key.key1:10m 只用1次 key2:10m只用了2次(建议使用这种)
allkeys-lru:在内存不足时，Redis会在全部的key中干掉一个最近最少使用的key。
volatile-lfu: 在内存不足时，Redis会在设置过了生存时间的key中于掉一个最少频次使用的key。使用10个key，key1用了2次 key2 用了1次
allkeys-lfu:在内存不足时，Redis会在全部的key中干掉一个最少频次使用的key
volatile-random: 在内存不足时，Redis会在设置过了生存时间的key中随机干掉一个。
allkeys-random:在内存不是时，Redis会在全部的key中随机干掉一个。
volatile-ttl:在内存不是时，Redis会在设置过了生存时间的Key中干掉一个剩余生存时间最少的key。
noeviction:在内存不足时，Reids对写操作进行报错，对读操作可以执行

4.Redis 过期键的删除策略

定时删除：在设置键的过期时间的同时，创建一个定时器 timer。让定时器在键的过期时间来临时，立即执行对键的删除操作。
惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键;如果没有过期，就返回该键。
定期删除：每隔一段时间程序就对数据库进行一次检查，删除里面的过期键。至于要删除多少过期键，以及要检查多少个数据库，则由算法决定。

5.Redis的高可用性

主从模式：

从节点设置了主节点后，slave通过master节点建立socket连接，每隔1秒执行一次。连接成功后从节点会创建一个专门处理复制工作的事件处理器，用于命令传播以及接收RDB文件等。

职责：主节点负责写，从节点负责读

数据同步：

全量复制
增量辅助：通过offset 来定位需要复制后数据的位置

哨兵模式：

职责：

为了提升主从架构的可用性，用来监控主从架构是否可用

选举：

哨兵监控主节点宕机，通知其他哨兵，确认主节点宕机了，通知从节点选举

谁的数据多，谁当主节点；如果一样多，谁的数据新，谁当主节点

集群模式（cluster）：

主节点负责写，从节点只负责数据的同步，会根据key进行hash运行，得到对应的槽位，把数据放进去

6.分布式锁

传统锁：

Synchronized 是 Jvm 中的关键字，没办法手动释放锁
Lock 是 Java 类库中的api，可以手动释放锁

分布式锁：

分布式锁的实际应用 --- 热点数据重建问题：

为什么要加锁？

热点数据因为其高访问量的缘故，为了提升性能，应该尽量减少对数据库的访问，不必每一次都直接查询数据库，可以使用redis作为缓存机制。当redis中没有热点数据时就访问数据库，若redis中存在热点数据，则直接从redis中获取即可。但存在特殊情况，如果在访问数据库之后，将数据存入redis之前，这时另一个进程抢走了cpu的执行权，此时redis中任然没有数据。那么此进程又将直接对数据库进行访问，这时就应该就整个进程加上一个锁。