高频出现的redis缓存面试题

redis有着出色的高性能与并发，是在大流量的网站中，需要我们用到的缓存技术，如果大家想要在面试官面前有很好的表现，那么redis的技术肯定是需要掌握的。今天小编就针对redis的面试题，整理出了比较常见的，希望可以帮助到大家：

一、Redis到底是单线程还是多线程

Redis 6.0版本之前的单线程指的是其网络I/O和键值对读写是由一个线程完成。

也就是只有网络请求模块和数据操作模块是单线程的，而其他的持久化、集群数据同步等，其实是由额外的线程执行的。

Redis6.0引入的多线程指的是网络请求过程采用了多线程，但键值对读写命令仍然是单线程处理的，所以Redis依然是并发安全的。

二、Redis单线程为什么还能这么快

命令执行是基于内存操作的，一天命令在内存里操作的时间是几十纳秒

命令执行是单线程操作，没有线程切换开销。

基于IO多路复用机制提升Redis的IO利用率。

高效的数据存储结构：全局hash表以及多种高效的数据结构，比如：跳表、压缩列表、链表等。

三、Redis底层数据是如何用跳表来存储的

四、Redis key 过期了为什么内存没释放

如果原本这个key是有过期时间的，再给这个key使用SET命令并且不设置过期时间，那么Redis会自动擦除这个key的过期时间。

Redis对于过期的key的处理一般有惰性删除和定时删除两种策略

惰性删除：当读/写一个已经过期的key时，会触发惰性删除策略，判断key是否过期，如果过期了直接删除这个key。这也是key过期了为什么没有立即释放内存。

定时删除：由于惰性删除无法保证冷数据被及时删掉，所以Redis会定期(默认每100ms)主动淘汰一批已过期的key，这里的一批只是部分过期的key，所以可能会出现key已经过期了但是还没有被清理掉的情况，导致内存没有释放。

五、Redis key没有设置过期时间为什么被Redis主动删除了

当Redis已用内存超过maxmemory限定时，厨房主动清理策略

主动清理策略在Redis4.0之前，实现了6种内存淘汰策略，在4.0之后，又增加了两种，总共8种：

六、Redis 淘汰key的算法LRU与LFU的区别

LRU算法(Least Recently Used，最近最少使用)：淘汰很久没被访问的数据，以最近一次访问时间作为参考。

LFU算法(Least Frequently Used，最不经常使用)：淘汰最近一段时间被访问次数最少的数据，以次数作为参考。

绝大多数情况我们可以用LRU策略，当存在大量的热点缓存数据时，LFU可能更好一点。

七、删除Key命令会阻塞Redis嘛

会阻塞的。DEL key[key...] 命令会根据key类型来删除，时间复杂度也是不一样的，O(N)，N为被删除的key数量

删除单个字符串类型的key，时间复杂度为O(1)

删除单个列表、集合、有序集合或哈希类型的key，时间复杂度为O(M)，M为以上数据结构内的元素数量。

八、谈谈Redis集群数据hash分片算法

Redis 集群将所有数据划分16384个slots，每个节点负责其中一部分槽位。当Redis 集群的客户端来连接集群时，它也会得到一份集群的槽位信息并将其缓存到客户端本地，这样当客户端要查找某个key时，可以根据槽位定位算法定位到目标节点。

槽位定位算法

集群默认会对key值使用crc16算法进行hash，得到一个整数值，然后这个整数值对16384进行取模运算来得到具体的槽位。

Hash_slot = CRC16(key)mod13684

再根据槽位和节点的对应关系就可以定位到key具体是在那个Redis节点上。

九、Redis执行命令竟然有死循环阻塞Bug

Redis有个RANDOMKEY命令可以从Redis中随机取出一个key，这个命令可能导致Redis死循环阻塞。

RANDOMKEY在随机拿出一个key之后，首先会检验这个key是否过期，如果该key过期，那么Redis会删除它，这个过程就是惰性删除，但是清理完了之后还不能结束，Redis会再找出一个没过期的key返回给客户端。

此时，Redis则会继续随机拿出一个key，然后再判断它是否过期，直到找到一个没过期的key返回给客户端。

这里就有一个问题，如果此时Redis中有大量的key过期，但还未来得及被清理掉，这个循环就会持续很久才能结束，这样就会导致RANDOMKEY命令执行耗时变长，影响Redis性能。

以上流程，其实是master上执行的。如果在slave上执行RANDOMKEY，那么问题更严重。

slave是不会自己清理过期的key，当一个key要过期时，master会先清理删除它，之后master向slave发送一个DEL命令，告知slave也删除这个key，以此达到主从一致。

假设Redis中存在大量已过期还未来得及清理的key，那么在slave上执行RANDOMKEY时，就会发生一下问题：

1、slave随机取出一个key，判断是否已经过期。

2、key已经过期，但是slave不会删除它，而是继续随机寻找不过期的key

3、由于大量key都已过期，那slave就会找不到符合条件的key，就会进入死循环。

这个Bug直到5.0才被修复，修复方法就是在slave中设置一个最大查找次数，无论找到与否，到了这个最大次数就退出循环。

十、一次线上事故，Redis主从切换导致了缓存雪崩

我们假设，slave的机器时钟比master走的快很多。

此时，Redis master 里设置了过期时间的key，从slave角度来看，可能会有很多在master里没过期，在slave里面已经过期了的数据。

如果此时操作主从切换，把slave提升为新的master，新的master就会开始大量清理过期的key，此时就会导致以下结果：

1、master大量清理过期key，主线程可能会发生阻塞，无法及时处理客户端请求。

2、Redis中数据大量过期，引发缓存雪崩。

所以，我们一定要保证主从库的机器时钟一致，避免发生这些问题。

以上就是“高频出现的redis缓存面试题”，你能回答上来吗?如果想要了解更多的Java面试题相关内容，可以关注动力节点Java官网。