Redis面试题总结

1.Redis发布订阅

Redis 发布订阅 (pub/sub) 是一种消息通信模式：发送者 (pub) 发送消息，订阅者 (sub) 接收消息。
**1.订阅命令

subscribe 主题名字

**2.发布命令

publish 主题名称 消息内容

注意： 返回的是订阅者数量。发布的消息没有持久化。

2.Redis慢查询

慢查询，顾名思义就是比较慢的查询，但是究竟是哪里慢呢？
说明：
1. 慢查询发生在第3阶段
2. 客户端超时不一定慢查询，但慢查询是客户端超时的一个可能因素
3. 慢查询日志是存放在Redis内存列表中

什么是慢查询日志？

慢查询日志是Redis服务端在命令执行前后计算每条命令的执行时长，当超过某个阈值是记录下来的日志。日志中记录了慢查询发生的时间，还有执行时长、具体什么命令等信息，它可以用来帮助开发和运维人员定位系统中存在的慢查询。

怎么配置慢查询参数？

配置慢查询参数如下：

• 命令执行时长的指定阈值 slowlog-log-slower-than：

  slowlog-log-slower-than的作用是指定命令执行时长的阈值，执行命令的时长超过这个阈值时就会被记录下来。

• 存放慢查询日志的条数 slowlog-max-len。

  slowlog-max-len的作用是指定慢查询日志最多存储的条数。实际上，Redis使用了一个列表存放慢查询日志，slowlog-max-len就是这个列表的最大长度。

  查看慢日志配置

  查看redis慢日志配置，登陆redis服务器，使用redis-cli客户端连接redis server

127.0.0.1:6379> config get slow*
1) "slowlog-max-len"
2) "128"
3) "slowlog-log-slower-than"
4) "10000"

修改Redis配置文件

比如，把slowlog-log-slower-than设置为1000，slowlog-max-len 设置为1200

slowlog-log-slower-than 1000
slowlog-max-len 1200

如何解决慢查询问题？
通过慢查询日志解决，slowlog len获取慢查询记录数，在通过slowlog get n获取具体信息去排查

3.流水线操作

多次发送：经历了 n次时间 = n次网络时间 + n次命令时间
流水线发送:一次网络连接 执行n条redis指令。

4.Redis持久化操作

Redis支持两种持久化机制：RDB和AOF.。
1.RDB是快照持久化，占用磁盘空间小。但有丢失数据的风险，同时他有三种触发机制，flushall命令，手动触发redis持久化的save和报告save。他的优势是：

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快
  RDB适合做冷备份，如一天一备份的常规备份。

2.AOF是通过记录命令日志持久化，不易丢失数据，但是磁盘占用空间大，读写速度慢。AOF适合做REDIS正常重启前的数据备份，不会丢失数据。

综合使用AOF和RDB两种持久化机制
用AOF来保证数据不丢失，作为数据恢复的第一选择，用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

5.Redis事务

Redis事务三大特性

• 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断；
• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”。
• 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚；

redis事务命令

• multi 开启事务
• exec 执行事务
• discard 取消事务

6.Redis主从复制模式

redis集群模式有三种

• 主从模式
• 哨兵模式
• 集群模

主从模式从一定程度上解决单机Redis的并发问题和可用性问题。但是主从模式问题很大，主节点挂了，需要手动将从节点切换为主节点，所以实际开发很少用到。然后Redis主从复制是哨兵机制和集群机制的根本，所以理解主从模式很重要。
主从模式原理如下：
1.从节点保存主节点信息。
2.从节点每秒复制运行到的相关逻辑，当定时任务发现存在新的主节点时，会尝试和该节点进行网络连接。
3.从节点和主节点建立网络连接
4.发送ping命令，连接建立成功后，从节点发送ping请求进行通信。
5.权限验证：如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证；如果验证失败复制将终止，从节点重新发起复制流程。
6.主从复制连接成功后，主节点会把所以数据传输给从节点。
7.第一次连接成功后进行全量复制，后续进行增量复制。

7.Redis的哨兵模式

哨兵模式主要解决主从复制master节点挂掉之后的，切换从节点为主节点问题，哨兵模式通过监控主从复制主节点和从节点完成自动切换主节点功能。
1. 集群监控：负责监控redis master和slave进程是否正常工作
2. 消息通知：如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
3. 故障转移：如果master node挂掉了，会自动转移到slave node上 ， 至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移。
4. 配置中心：如果故障转移发生了，通知client客户端新的master地址

8.Redis集群模式

集群模式至少要6个redis服务器，集群模式就是n个主从复制模式，但是需要根据插槽机制分配每个节点存储数据范围，来解决单个redis不能读取数据过大问题。

9.Redis脑裂问题

Redis主从模式下，由于主节点挂了，从节点新选出主节点，由于网络情况，挂掉主节点没有降级为从节点，导致有两个主节点可以写数据。导致挂掉的主节点的数据无法同步而丢失问题。
解决办法

min-replicas-to-write 1
min-replicas-max-lag 5

10.Redis冷启动问题

redis冷启动就是服务器中没有数据，直接启动，访问量很大，导致mysql直接裸机运行，可以提前将数据注入，通过缓存预热解决，通过storm实时计算出热点数据，然后定时将热点数据写入缓存。

11.Redis缓存穿透问题

多次查询一个缓存和数据库都不存在的数据，多半为恶意攻击，解决方案，去数据库查不存在在redis存null,并且设置过期时间5分钟。
或者用布隆过器解决：布隆过滤器是一个bitMap数组，它说不存在的元素一定不存在，他说存在的未必存在。

12.Redis缓存击穿问题

某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。从造成问题的原因去解决，当热点Key失效的一刹那，大并发裸奔访问数据库，数据库被打垮。我们只需要在热点Key失效的一刹那保证只有一个请求过来就可以了。这种需求肯定用锁解决，理论上可以用同步锁解决，但这个不靠谱，锁只能锁一个进程，但是微服务是多个服务是多个进程，根本不起作用。所以用分布式锁解决。

13.Redis缓存雪崩

大量缓存同时失效，数据库被击垮问题。解决思路不让缓存同时失效，比如加给缓存过期时间加随机数，但是当缓存数据足够大时，这个效果不那么明显了，可以通过二级缓存技术实现。

以上就是全部内容，如果你有任何问题、意见或建议，都欢迎在评论中分享。让我们继续分享知识，共同成长，一起走向更加美好的未来。感谢你们的阅读，祝愿你们在未来的道路上一帆风顺！