Redis的常见面试题

缓存：用来保存常见的热点数据，减少数据库的压力

计数器：统计点击次数、收藏、点赞次数等

排行榜：可以基于Zset简单实现

分布式会话：使用Redis存储会话信息，可以让用户访问到系统的不同模块的时候都使用同一个公共会话

分布式锁：对于分布式的一种并发控制手段，可以基于Redis来实现，上篇文章有详细展开

消息队列：Redis自身支持Stream数据类型，可以作为简单的消息队列使用

如何检测Redis的连通性？

给服务端发送一个 "ping" ，通顺的话就会收到 "pong"

如何设置key的过期时间？

可以在set key的时候通过EX选项指定过期时间，也可以再使用expire对已存在的key设置过期时间

Redis为什么是单线程模型？

Redis内部逻辑较为简单，大部分的性能瓶颈都是出现在IO或内存上，很少是CPU。因此使用多线程还没多大收益，还容易引入线程安全问题

从Redis6.0开始，Redis引入多线程，此时它也只是使用多线程去处理网络请求+协议解析，真正执行Redis命令的仍然是单线程完成，这样可以提高IO处理效率

Redis里的IO多路复用是什么？

Redis主要是基于Linux提供的epoll机制来完成IO多路复用（之前文章详细讲述过）

所谓IO多路复用，其实就是一个线程来管理多个 socket ，并按需激活线程

| 假如在同一个单位时间内，有多个Redis客户端的请求到来了.....

| 使用传统的方式是给每一个客户端连接开一个线程，但是大部分的客户端不会频繁的给你传输，即多数是空闲线程（不活跃），所以搞一堆线程不如就用一个线程来处理，反正并发量不会太高而且处理速度又飞快

上述的操作被Linux封装好了，就是IO多路复用

在Linux中有三种实现方式：

select
poll
epoll

epoll是最新，也是最高效的版本（之前文章有详细讲述）这里浅浅谈一下

epoll在内核维护了一个红黑树，来管理这些socket，并且每一个节点都关联了一个事件回调，当系统内核感知到网卡收到数据，进一步判定这个数据是给哪一个socket的，随之调用对应的回调函数，进一步唤醒用户线程，来处理这个数据

RDB的持久化机制有哪些？

RDB和AOF两种

RDB：

RDB是一个紧凑的二进制文件，代表Redis某个时间的数据快照。适合备份，全量复制的场景。

Redis加载RDB文件来恢复数据远快于AOF

但是RDB也没办法做到实时持久化。因为每次的bgsave都需要fork，全量复制对于cpu和硬盘的负荷大

此外，RDB文件使用特定的二进制格式保存，Redis版本演进过程中有多个RDB版本，兼容性可能有冲突

AOF：

AOF记录所有写入Redis的命令（文本方式），因此AOF的实时性高，适合在Redis宕机的时候恢复

AOF提供了重写功能，可以定期对AOF文件进行重写，取出冗余命令，减小AOF大小

由于每次的命令都要同步到AOF文件中，所以会有一定的写入延迟

AOF文件是文本类型的数据比较大

如果AOF的文件过大就会导致恢复速度比较慢了

AOF的重写机制是怎么样的？

Redis在后台启动一个AOF重写进程

在AOF重写过程中，Redis继续处理客户端请求，并将这份数据同时保存到旧AOF文件以及一个缓冲区

新的AOF文件会遍历内存中的数据状态，只保留数据的最后状态。并与缓冲区共同生成一份完整的AOF文件

用新的AOF文件来代替旧的AOF文件

Redis的过期删除策略是怎么样的？

惰性过期

只有当访问一个key的时候才能判断他是否过期，过期就清除。

这种策略方式可以节省CPU资源，但是会有可能出现大量过期的key未被再次访问，导致占用大量内存

定期过期

每个一段时间，会扫描一定数量的数据库expires字典中一定数量的key，并清除已过期的key。

expire字典中会保存所有设置了过期时间的key的过期时间数据，其中key是指向某个键的指针，value是该键的毫秒精度的UNIX时间戳表示过期时间

Redis中则是同时使用了这两种策略：

每隔100ms就随机抽取一定数量的key来检查和删除

在获取key的时候检查一下是否过期，过期就删除

Redis处理缓存雪崩的问题：

首先对于定期删除来说，Redis会注册一个定时器，每个一定时间就触发一次

在删除的时候会根据事先统计好的过期key的个数来决定后续策略

如果过期key的个数超过总key的25%，就会让Redis持续删除过期key直到最大删除时间（默认25ms），但即使如此，有些对性能要求高的常见仍然会因为阻塞25ms导致性能下降

解决方案：可以在过期时间上加上随机值，使过期时间分散一点，降低触发这个25%阈值

Redis的主从复制是怎么回事？

其实就是为了保证咱redis的高可用，减少单个节点的负载（具体流程之前文章讲述过）

Redis主从复制https://blog.csdn.net/Obto_/article/details/135946296

介绍一下Redis哨兵

之前文章有详细讲述，感兴趣的可以看看这篇文章
Redis哨兵https://blog.csdn.net/Obto_/article/details/135964383

Redis Sentinel是Redis的高可用的实现方案，在实际的生产环境中，对整个系统的高可用提升是非常有帮助的，当主从复制结构中某个节点宕机之后，哨兵能够自动发现故障并完成故障转移

如果是主节点故障，哨兵之中会互相协商（哨兵不只一个），当大多数哨兵节点达成主节点宕机的结果后，就会在哨兵之中推举出一个领导节点来自动完成故障转转移的工作，同时将这个变化通知给Redis客户端，这个过程是全自动的不需要人工介入

Redis集群是干什么用的？

之前的文章有详细讲述，感兴趣的可以看看这篇文章

Redis集群https://blog.csdn.net/Obto_/article/details/136176895

Redis集群引入多组Master/Slave，每一组Master/Slave存储数据全集的一部分，从而构成更大的整体，解决单个Master/Slave能够达到的性能上限，能够存储更多的数据

好比一个30T的资源放在一个硬盘放不下，就可以放在3个10T的硬盘上

Redis的哈希槽是怎么回事？

在Redis集群中要合理的分配各个主节点的资源，所以就有了不同的hash方式将数据映射到对应的分片中

第一种就是直接hash 一个 N ，N为分片的总数，这样能够保证数据随机分配，但是一旦出现数据扩容的情况，N发生了变化，此时之前的映射关系全部作废，扩容的代价很大

第二种就是一致性hash，统一hash一个数，这样能解决上述因扩容而导致的映射关系被破坏，但是会导致数据的不均匀

因此哈希槽分区算法就出来了

哈希槽分区算法：

将所有的key都映射到16284(2^14) 个槽位上，再把这些槽均匀的分配给每个分片，每个分片只需要记录自己拥有哪些槽位即可 （详细的连接在上面Redis集群链接中）

Redis集群会有操作丢失吗？

Redis并不能保证数据的强一致性，实际中集群在特定的条件下可能会丢失写操作

比如在成功写入一个key之后，正好主节点宕机，那么此时由于这个数据还未来得及同步到从节点，也没来得及写入AOF日志，就会丢失

如何理解Redis的事务？和MySQL的事务有什么区别？

区别：

弱原子性

不保证一致性

不需要隔离性

不需要持久化

Redis事务的本质就是在服务器搞了一个“事务队列”，每次客户端进行操作的时候，就先把命令保存在事务队列中，收到EXEC命令后才会一起执行

Redis事务和MySQL事务的概念上是一样的，都是把一系列的操作捆绑成一组，让一组批量执行

什么是缓存穿透、缓存雪崩、缓存击穿

缓存穿透

访问的key不存在客户端也不存在服务端，此时这样的key就不被缓存起来，而高频的访问这个不存在的key就会导致Redis失去他“保护盾”的作用

解决办法:

1.布隆过滤器

2.将不存在的key也存在redis并随便设置value为'.'

3.对需要查询的key进行严格的合法性校验，不合规的不让查

缓存雪崩

短时间内大量的key 在缓存上失效，导致数据库压力暴增

解决方法：

1.部署高可用的Redis集群

2.不给key设置时间，或设置时间的时候添加随机时间因子

缓存击穿

相当于缓存血崩的特殊情况，就是针对热点key过期了，导致大量的请求访问到了MySQL上

解决方法：

1.基于统计的方式发现热点key，并设置永不过期

2.进行必要的服务降级，访问数据的时候使用分布式锁，限制并发数

Redis和MySQL如何保证双写一致性？

什么是“双写一致性” ？？

当用户修改数据的时候，需要修改数据库，同时也要更新缓存中的数据

如果直接写数据库并写Redis，此时万一有一方写入失败，就容易出现数据不一致情况

解决方法：

方案一：延迟双删

1.删除缓存数据

2.更新数据库

3.再删除缓存数据

方案二：删除缓存重试

1.先删除缓存数据，如果失败，就把失败的key放到一个mq中，稍后进行重试