当前位置：首页 > news >正文

针对面试-redis篇

news 来源：原创 2025/8/21 7:45:40

1. 缓存穿透

什么是缓存穿透？

缓存穿透就是有人查询一个不存在的数据，数据库查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库。

解决方案一：缓存空数据

当数据库中不存在该数据时，直接把查到的空数据给缓存起来，这样就防止了缓存穿透。

优点：简单；

缺点：消耗内存，数据可能会不一致（比如说查询id=1的数据，刚开始是没有该数据的，然后也缓存了空数据，但是现在突然增加了id=1的数据，这样数据库与redis中的数据就不一致了）

解决方案二：布隆过滤器

布隆过滤器是加在查询数据操作与redis之间的，当我们查询数据时，会首先经过布隆过滤器，在布隆过滤器来查询是否有该数据，如果没有直接返回，再不会进行查询操作，如果布隆过滤器中存在，则查redis，redis中不存在，再查数据库。

优点：（当缓存预热时也会预热布隆过滤器像布隆过滤器中添加数据）在之后的使用中内存占用过少，没有多余的key；

缺点：实现复杂，会出现误判；

布隆过滤器是什么？

通过bitmap（位图）来实现存储数据的，它会将数据通过多个hash函数来进行计算，然后将bitmap上的二进制0变为1，当查询数据时，只需要查看数据经过hash函数计算的值是否存在即可。

2. 缓存击穿

什么是缓存击穿？

缓存击穿就是当我们查询一个热点数据时，但是这个热点数据的key过期了，这时正好有并发请求一起针对这个热点数据发起请求，这些并发请求可能会把数据库压垮。

解决方案一：互斥锁（分布式锁）

所谓的互斥锁就是在线程一来执行查询缓存操作未命中时，会获取一个互斥锁，这个互斥锁的作用是只允许一个线程来操作数据，在查询数据库重建缓存数据的时候，其他的线程只能等待释放锁才能进行操作。

优点：强一致

缺点：性能差

解决方案二：逻辑过期

在redis缓存数据时，设置一个逻辑过期时间，在查询缓存的时候发现逻辑时间已经过期了，这时获取互斥锁，然后同时它会开启一个新的线程，这个新线程会执行缓存重建操作，但是同时，线程一也会返回一个过期的数据，这时如果来了一个线程三，线程三查询缓存时，发现逻辑过期时间已经过期了，它获取互斥锁失败，但是也会返回过期数据，这时又来了一个线程四，这个线程四命中了缓存，并且没有过期。

优点：高可用，性能优

缺点：一致性差

3.缓存雪崩

什么是缓存雪崩？

缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。

解决方案一：给过期时间设置随机值

针对大量的缓存key同时失效的情况，我们可以给不同的数据添加不同的随机过期时间来解决该问题

解决方案二：设置集群模式，哨兵模式

针对Redis服务宕机，我们可以采用redis集群来提高服务的可用性

解决方案三：给缓存添加降级限流策略

使用ngxin或者gateway来进行操作

解决方案四：给业务添加多级缓存

使用Guava或Caffeine作为一级缓存，使用redis作为二级缓存

4. 双写一致性

什么是双写一致性？

所谓的双写一致性就是，当数据库中的数据被修改的同时也要对缓存进行更新，保证缓存和数据库中的数据要一致。

读操作

先查redis，redis有数据则直接返回，没有数据则去查数据库，查到以后再写入缓存

写操作

1. 延时双删操作（删除缓存--修改数据库--删除缓存）也会有脏数据

强制一致

通过加锁的方式 1.分布式锁 2.排他锁（写操作时使用，其他线程不能读和写操作） 3.共享锁（读操作时使用，其他线程只允许读）

怎么确保双写一致性？

1.异步处理的方案来同步数据

在允许延时一致的业务中，可以使用mq中间件，更新数据以后，通知缓存删除；利用canal中间件，不需要修改业务代码，伪装为mysql的一个从节点，canal通过读取binlog数据更新缓存

2.读写锁来保证数据的同步

在需要强一致的业务中，使用redisson的提供的读写锁，共享锁:读锁readLock，加锁之后，其他线程可以共享读操作；排他锁:独占锁writeLock，加锁之后，阻塞其他线程读写操作

5,redis持久化

redis是怎么进行持久化？

redis提供了两种数据持久化的方式：

1.RDB :叫做Redis数据快照。简单来说就是把内存中的沂有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据；

RDB的执行原理?
bgsave开始时会fork（复制）主进程得到子进程，子进程共享主进程的内存数据。完成fork（复制）后读取内存数据并写入 RDB 文件。fork采用的是copy-on-write技术:
当主进程执行读操作时，访问共享内存;
执行写操作。当主进程执行写操作时，则会拷贝一份数据

2.AOF：AOF全称为Append Only File(追加文件)。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

这两种方式，哪种恢复的比较快呢?
RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，我们当时设置的就是每秒批量写入一次命令。

6. redis数据过期策略

redis数据过期策略有哪些？

解决方案一：惰性删除

设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key

优点: 对CPU友好，只会在使用该key时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查

缺点: 对内存不友好，如果一个key已经过期，但是一直没有使用，那么该key就会一直存在内存中，内存永远不会释放

解决方案二：定期删除

定期删除:每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的过期key)。

定期清理有两种模式:
SLOW模式：是定时任务，执行频率默认为10hz，每次不超过25ms，以通过修改配置文件redis.conf 的hz 选项来调.整这个次数
FAST模式：执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms

优点:可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点:难以确定删除操作执行的时长和频率。

Redis的过期删除策略:惰性删除 +定期删除两种策略进行配合使用

7. 数据的淘汰策略

什么是数据的淘汰策略？

当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。

Redis支持8种不同策略来选择要删除的key：（LRU是最近最少使用原则，LFU是最少频率使用原则）

noeviction:不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略
volatile-ttl: 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰

allkeys-random:对全体key，随机进行淘汰。

volatile-random:对设置了TTL的key，随机进行淘汰。

allkeys-lru:对全体key，基于LRU算法进行淘汰

volatile-lru:对设置了TTL的key，基于LRU算法进行淘汰

allkeys-lfu:对全体key，基于LFU算法进行淘汰

volatile-lfu:对设置了TTL的key，基于LFU算法进行淘汰

8. redis分布式锁

redis分布式锁是如何实现的？

首先在我的项目中，我是在一个抢券业务下使用的分布式锁，当时我们项目采用的是redisson实现的分布式锁，因为redisson的底层是使用了setnx以及lua脚本（可以保证是可以保证命令的原子性的）

Redisson实现分布式锁如何合理的控制锁的有效时长?

在redisson的分布式锁中，提供了一个WatchDog(看门狗)，一个线程获取锁成功以后WatchDog会给持有锁的线程续期(默认是每隔10秒续期一次)

Redisson的这个锁，可以重入吗?

可以重入，多个锁重入需要判断是否是当前线程，在redis中进行存储的时候使用的hash结构来存储线程信息和重入的次数

Redisson锁能解决主从数据一致的问题吗

不能解决，但是可以使用redisson提供的红锁来解决，但是这样的话，性能就太低了，如果业务中非要保证数据的强一致性，建议采用zookeeper实现的分布式锁

9. redis主从同步

介绍一下redis的主从同步

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。般都是一主多从，主节点负责写数据，从节点负责读数据

主从同步数据的流程？

全量同步:
1.从节点请求主节点同步数据(replicationid、offset )
2.主节点判断是否是第一次请求，是第一次就与从节点同步版本信息(replication'd和offset)

3.主节点执行bgsave，生成rdb文件后，发送给从节点去执行
4.在rdb生成执行期间，主节点会以命令的方式记录到缓冲区(一个日志文件)

5.把生成之后的命令日志文件发送给从节点进行同步

增量同步
1.从节点请求主节点同步数据，主节点判断不是第一次请求，不是第一次就获取从节点的offset值2.主节点从命令日志中获取offset值之后的数据，发送给从节点进行数据同步

10.哨兵模式

怎么保证Redis的高并发高可用

哨兵模式:实现主从集群的自动故障恢复(监控、自动故障恢复、通知)

你们使用redis是单点还是集群，哪种集群

主从(1主1从)+哨兵就可以了。单节点不超过10G内存，如果Redis内存不足则可以给不同服务分配独立的Redis主从节点

redis集群脑裂，该怎么解决呢?

集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样，这样会导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将老的主节点降为从节点，这时再从新master同步数据，就会导致数据丢失
解决:我们可以修改redis的配置，可以设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求就可以避免大量的数据丢失

11.redis分片集群

redis的分片集群有什么作用

集群中有多个master，每个master保存不同数据

每个master都可以有多个slave节点
master之间通过ping监测彼此健康状态
客户端请求可以访问集群任意节点，最终都会被转发到正确节点

Redis分片集群中数据是怎么存储和读取的?

分片集群引入了哈希槽的概念，Redis 将16384个插槽分配到不同的实例；读写数据:根据key的有效部分计算哈希值，对6384取余(有效部分，如果key前面有大括号，大括号的内容就是有效部分，如果没有，则以key本身做为有效部分)余数做为插槽，寻找插槽所在的实例

12. redis为什么那么快

Redis是单线程的，但是为什么还那么快
Redis是纯内存操作，执行速度非常快
采用单线程，避免不必要的上下文切换可竞争条件，多线程还要考虑线程安全问题

使用I/O多路复用模型，非阻塞I0

能解释一下I/O多路复用模型?

1.I/0多路复用
是指利用单个线程来同时监听多个Socket，并在某个Socket可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。目前的I/0多路复用都是采用的epoll模式实现，它会在通知用户进程Socket就绪的同时，把已就绪的Socket写入用户空间，不需要挨个遍历Socket来判断是否就绪，提升了性能。
2.Redis网络模型
就是使用I/O多路复用结合事件的处理器来应对多个Socket请求
连接应答处理器
命令回复处理器，在Redis6.0之后，为了提升更好的性能，使用了多线程来处理回复事件

命令请求处理器，在Redis6.0之后，将命令的转换使用了多线程，增加命令转换速度，在命令执行的时候，依然是单线程