在《对线面试官》| 高频 Redis 面试题（上）一文中，给大家分享了一些在校招面试中常见的 Redis 面试题
闲话少说，接着给大家分享干货！
13、你知道 Redis 哨兵架构吗？
哨兵架构是在 Redis 主从复制基础上构建的一套高可用解决方案
在 Redis 主从复制里，需要对故障切换进行人为操作，但在哨兵架构里，哨兵可以对 master 和 slave的运行状态进行监控，一旦 master 出现故障，就可以自动实现故障转移及主从切换，无需人工干预
这大大提高了 Redis 的高可用性
Redis 哨兵具备的功能：
- 监控：监控 Redis 节点的运行状态
- 自动故障切换：一旦监控到 master 出现故障，自动进行故障切换，选举出一个新的 master
- 节点自动发现：通过对 master 执行 info 命令，就能够获取到 master 下的 slave 节点列表；通过发布/订阅通道发送 hello 信息来发现其他哨兵节点
14、你知道 Redis cluster 架构吗？
Redis 集群是一种分布式数据库方案，集群通过分片（sharding）来进行数据管理，并提供复制和故障转移功能
一方面，它具有哨兵架构的自我故障检测以及故障切换的功能，另一方面，它将写操作分摊到了多个 master 上，提高了写的并发能力，解决了 master 单点故障问题
cluster 架构将数据划分为 16384 的 slots，每个 master 负责一部分槽位。槽位的信息存储于每个 master 中
当往 redis 里写入数据时，会根据哈希算法（CRC16(KEY)%16384）算出这个数的哈希槽来决定它放到哪一个主节点上，然后这个 master 的 slave 节点去自动同步
15、cluster 架构中 Redis 实例是如何进行通信的
在 Redis cluster 中，节点之间通过建立 TCP 连接，使用 gossip 协议来传播信息，最终实现所有节点都会知道整个集群完整的信息
gossip 协议有四种常用的消息类型：PING、PONG、MEET、FAIL
- MEET：当需要向集群中加入新节点时，需要集群中的某个节点发送MEET消息到新节点，通知新节点加入集群。新节点收到MEET消息后，会回复PONG命令给发送者（redis5.0后 用add-node命令来添加节点）
- PING：集群内每个节点每秒会向其他节点发送PING消息，用来检测其他节点是否正常工作，并交换彼此的状态信息。PING消息中会包括自身节点的状态数据和其他部分节点的状态数据
- PONG：当接收到PING消息和MEET消息时，会向发送发回复PONG消息，PONG消息中包括自身节点的状态数据。节点也可以通过广播的方式发送自身的PONG消息来通知整个集群对自身状态的更新
- FAIL：当一个节点判定另一个节点下线时，会向集群内广播一个FAIL消息，其他节点接收到FAIL消息之后，把对应节点更新为下线状态
16、哈希槽是如何映射到 Redis 上的，客户端是如何知道数据分配在哪个节点上的
- 哈希槽是如何映射到 Redis 上的?
在cluster中，一个切片集群共有16384个哈希槽（2^14），这些哈希槽类似于数据分区，每个键值对都会根据它的key，被映射到一个hash槽中
然后该槽位再被映射到 Redis 实例上
- 客户端如何定位数据在哪个节点上？
客户端和集群实例建立连接后，Redis 实例就会把哈希槽的分配信息发给客户端（Redis 实例还会把自己的哈希槽信息发给和它相连的其他实例，来完成分配信息的扩散）
客户端收到哈希槽信息之后，会将其缓存到本地，当请求数据时，客户端先计算 key 所对应的哈希槽，再根据哈希槽信息去找到对应的 Redis 实例
17、可以在生产环境上使用 KEYS * 命令吗
要慎用，KEYS *命令会一次性读取所有键，如果生产环境上存储了大量的数据，可能会导致阻塞，线上服务会停顿，直到指令执行完毕，服务才能恢复
18、Reids 4.0 增加了混合持久化，什么是混合持久化？
在执行 Redis 重启操作时，如果采用 RDB ，有可能会丢失大量数据，如果使用 AOF，但 AOF 的性能要比 RDB 慢得多
Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化
混合持久化：
- 将 RDB 文件的内容和增量的 AOF 日志文件存在一起
- 这里的 AOF 文件不再是全量日志文件，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小
- 在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升
19、redis 内存用完了会发生什么
如果设置了最大可用内存限制，会触发 Redis 的内存回收策略，而且Redis 的写命令会返回错误信息（但能够进行读操作）
如果没有设置最大可用内存限制，会触发系统 OOM 将进程杀死
20、聊聊 redis 分布式锁
Redis 添加分布式锁即先拿 setnx 来争抢锁，抢到之后，再用 expire 给锁加一个过期时间防止锁忘记了释放
如果在 setnx 之后执行 expire 之前进程意外 crash 或者要重启维护，那么这个锁就永远得不到释放了
解决方法：同时把 setnx 和expire 合成一条指令来用，防止后续释放不了锁
21、Redis cluster 如何实现高可用
- 故障检测
集群中每个节点都会定期向集群中的其他节点发送 ping 消息，以此检测对方是否在线
如果接受 ping 消息的节点没有在规定时间内返回pong消息，那么发送 PING 消息的节点就会将 PONG消息节点标记为疑似下线（possible fail，PFAIL）
如果集群中超过半数以上的主节点都将某个主节点 X 标记为 PFAIL，则就会将这个主节点 X 标记为下线（FAIL），并广播这条消息
- 故障转移
当一个从节点发现自己所主节点下线时，就会开始进行故障转移
- 在该下线主节点的所有从节点中，选择一个做主节点
- 被选中的从节点会执行 SLAVE OF no one 命令，成为新的主节点
- 新的主节点会撤销对所有对下线主节点的槽指派，并将这些槽全部派给自己
- 新的主节点向集群广播一条 pong 消息，告诉其他节点自己变成了主节点
- 新主节点开始提供服务，故障转移完成
22、什么情况下会导致 Redis cluster 不可用了
cluster 架构下一般建议至少有三个主节点，便于哈希槽的分配
有R1、R2、R3 三个 master，三台 master 都没有 slave，如果 R2 失败了，那么整个集群就会认为缺少 5501-11000 这个范围的槽位而导致不可用
23、Redis 常见性能优化
- 为了主从复制的速度和连接的稳定性，master 和 Slave 最好在同一个局域网中
- 尽量避免在压力很大的 master 上增加 slave
- 尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的 web 系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面
- 好好利用 Hash, list, sorted set, set 等集合类型数据，因为通常情况下很多小的 Key-Value 可以用更紧凑的方式存放到一起
