【每日八股】复习 Redis Day7：应知应会的 33 条 Redis 基础八股文

应知应会的 33 条 Redis 基础八股文

今天对 Redis 八股文进行收官总结，共收录了 33 条基础八股文。
在这里插入图片描述

文章目录

应知应会的 33 条 Redis 基础八股文
Redis 持久化
- 简述 Redis 持久化的两种策略？
- AOF 的三种持久化策略？
- AOF 磁盘重写机制？
- 为什么先执行一个 Redis 写命令，再将该命令写入到 AOF 缓冲区？
- AOF 重写的具体过程？
- AOF 子进程内存跟主进程内存不一致怎么办？
- RDB 执行快照时，数据可以修改吗？
- Redis 过期机制？
- Redis 内存淘汰策略？
- Redis 持久化过程中如何处理过期的键？
- Redis 主从集群中，如何处理过期的键？
Redis 应用
- 缓存雪崩、缓存击穿、缓存穿透的现象解释及解决办法？
- 如何保证数据库和缓存的一致性？
- 如何保证缓存删除一定成功？
- 针对业务一致性要求高的场景，如何确保缓存与数据库的一致性？
- 如何避免缓存失效？
- 如何实现延迟队列？
- 如何设计一个缓存策略，以动态缓存热点数据？
- Redis 实现分布式锁？
- Redis 分布式锁的优缺点？
- Redis 如何解决集群模式下分布式锁的可靠性？
- Redis 管道有什么作用？与事务的区别？
Redis 的线程模型
- 简述 Redis 的线程模型
Redis 集群
- Redis 集群模式有哪些？
- Redis 切片集群的工作原理
- 主从模式的同步过程？
- 主服务器如何知道要将哪些数据发送给从服务器？
- 如何避免主从复制的不一致？
- 主从结构中过期的 key 如何处理？
- 主从复制是同步复制还是异步复制？
- 什么是哨兵机制？
- 什么是集群的脑裂？
- 如何避免 Sentinel 集群当中主从切换导致的数据不一致？

Redis 持久化

简述 Redis 持久化的两种策略？

RDB：Redis 自动或手动 fork() 一个子进程，对 fork() 时刻的数据生成一个全量的数据快照，RDB 持久化期间 Redis 服务器仍然可以接收客户端的请求，使用 COW 写时复制来接收新的写请求修改数据页。RDB 文件较小，通常用于 Redis 备份或容灾恢复，存在的问题是不够安全，如果 Redis 服务宕机，那么 RDB 快照生成期间的数据都会丢失。
AOF：Redis 每接收到一个写请求，就先执行这个请求，再根据 AOF 写会策略将该语句持久化到 AOF 文件当中。AOF 的文件体积通常较大，但是它的优点是可以确保 Redis 的数据安全性，在 everysec 写回策略下至多丢失一秒的数据。
混合持久化：即同时使用 RDB 和 AOF，RDB 直接写入 AOF 文件当中。具体来说，Redis 服务仍然开启一个子进程来复制全量快照，在此期间新增的 Redis 写请求先写入到 AOF 文件当中。混合持久化兼顾了 RDB 的紧凑性以及 AOF 的安全性。

AOF 的三种持久化策略？

always：每条 Redis 写操作执行后都先写入 AOF 缓冲区，再直接持久化到磁盘，安全性最好，但是性能开销较大；
everysec：每秒将 AOF 缓冲区当中的数据持久化到磁盘，最多丢失一秒的数据；
no：由 OS 择机将缓冲区中的数据持久化到磁盘，安全性欠佳，但是性能开销最小。

AOF 磁盘重写机制？

当 Redis 写请求过多后，AOF 文件中可能存在重复的命令以及失效的命令，导致 Redis AOF 文件较大。

AOF 磁盘重写机制就是开启一个子进程将当前 Redis 缓存中的状态逐条转换写操作，并写入新的 AOF 文件来替换旧的 AOF 文件。

具体来说，AOF 重写触发后，Redis 会 fork() 一个子进程，负责将 fork() 时刻的快照数据转为 Redis 写命令，在此期间新的客户端写请求会写入到 AOF 缓冲区和 AOF 重写缓冲区，通过 COW 写时复制技术来处理新的写命令产生的修改。AOF 重写完成后，AOF 重写缓冲区当中的命令会追加到新的 AOF 文件，之后替换旧的 AOF 文件，完成写时复制。

为什么先执行一个 Redis 写命令，再将该命令写入到 AOF 缓冲区？

如果先将命令写入到 AOF 缓冲区再执行 Redis 写命令，不能保证写入缓冲区的命令一定正确，后续通过 AOF 加载 Redis 缓存时还需要逐条检查命令的正确性，时间开销较大。

先执行 Redis 写命令，再写入缓冲区可以保证写入到 AOF 文件当中的写命令一定是正确的。

AOF 重写的具体过程？

详见方才所说的 AOF 磁盘重写机制，此处不再重复。

AOF 子进程内存跟主进程内存不一致怎么办？

指的是 AOF 重写开启后的情况。

AOF 重写开始时，Redis fork() 一个子进程，并与主进程共享该时刻的数据页，当主进程接收到新的来自客户端的写命令后会通过 COW 写时复制，对要修改的数据页进行复制，并在复制的数据页上执行实际的修改，子进程看到的仍然是 fork() 时刻的旧数据页。

RDB 执行快照时，数据可以修改吗？

可以修改，和上一个问题的回答同理。

Redis 过期机制？

Redis 可以为 Key 设置 TTL，基于惰性删除 + 定期删除来删除过期键。

惰性删除

Redis 读请求到来时，会先检查 Key 是否过期，如果过期则直接删除，并返回 nil；
存在的问题时，有一些过期的数据可能永远不会被访问到，导致空间浪费，所以需要结合定期删除。

定期删除

Redis 每隔一段时间就会随机抽取部分 Key 进行过期检查，如果发现抽取的 Key 当中有超过 25% 的 Key 都过期了，则重新抽取一次直到抽取的 Key 中过期比例小于 25% 或超时；
优点是降低了内存泄露的风险，存在的问题是无法删除所有过期键。

Redis 内存淘汰策略？

不淘汰
Redis 内存满时，只读不可写，新的写请求到来后会直接返回操作失败。

淘汰过期键
分为随机淘汰、优先淘汰过期时间较早的键，以及淘汰最近最久未使用和最近最少使用的键。

淘汰任意键
分为随机淘汰，淘汰最近最久未使用和最近最少使用。

Redis 持久化过程中如何处理过期的键？

RDB

生成 RDB 快照时：跳过过期的键；
加载 RDB 快照时：如果 Redis 以主节点启动，会检查键的过期时间，加载后立即删除。如果以从节点启动，由于从节点只读，因此不会删除过期键，依赖主节点同步 DEL 命令删除。

AOF

AOF 文件记录：写入 AOF 的过期键以 DEL 命令形式记录；
AOF 重写：跳过过期键。如果键在重启期间过期，主进程会追加 DEL 到缓冲区，缓冲区当中的命令会追加到新的 AOF 文件中。

Redis 主从集群中，如何处理过期的键？

从节点不具备写的能力，因此如果客户端访问从节点当中的过期键仍然可以得到值。从库中键的过期依赖主节点的同步。

Redis 应用

缓存雪崩、缓存击穿、缓存穿透的现象解释及解决办法？

缓存雪崩：大量键同时过期，或是 Redis 宕机，此时恰有大量请求到来，由于在缓存中得不到回复，会进一步查数据库，导致数据库压力骤增，严重时会导致服务崩溃。解决办法是均匀设置键的过期时间，或是在 Redis 宕机时触发熔断降级停止服务，或是在请求到数据库中重新构建缓存时加锁。

缓存击穿：热点数据在缓存中过期，请求击穿缓存到数据库查数据。解决办法是不为热点数据设置过期时间，以及请求查数据库重放缓存时加锁。

缓存穿透：不断有恶意请求访问缓存中不存在的数据，导致系统先查缓存再查数据库，增加系统开销。解决办法是在缓存中设置一个默认值或零值，或是将频繁恶意请求的客户端拉黑。

如何保证数据库和缓存的一致性？

Cache-Aside（旁路缓存）：写请求到来时，先修改数据库，修改数据库后删除缓存。

Read/Write Through：依赖于缓存自身的组件，比如 Redis 企业版。当读请求到来时，如果能在缓存中查到则直接返回，否则依赖于缓存组件到数据库中查数据并放回到缓存，返回响应。当写请求到来时，直接写缓存，由缓存组件将修改重放到数据库。

Write Behind：所有写请求都先写缓存，依赖于异步线程将缓存中的修改批量同步到数据库。

延迟双删：写请求到来时，先删除缓存并向 MQ 发送一个延迟消息。然后到数据库中修改数据。MQ 中消息到期后再次删除缓存，避免写时的并发读将脏数据重放到缓存。

基于 binlog 的最终一致性：所有写请求都修改数据库，数据库的修改会记录到 binlog，通过 Canal 这类中间件伪装成 MySQL 从库拉取 binlog 中的修改并将修改内容打包为消息事件发送到 MQ，作为主题订阅方的缓存拉取消息得到 binlog 并消费，修改缓存当中的内容，确保缓存与数据库的最终一致性。

如何保证缓存删除一定成功？

引入 MQ
将缓存删除的消息打包为事件放入 MQ 当中，即使缓存宕机，消息事件没有被消费就不会丢失，将缓存删除交由消费者来做，可以确保缓存一定被删除。

基于 binlog 的最终一致性
所有删除操作都会记录到 bin log，基于 Canal + MQ 可以确保缓存作为订阅方消费删除事件，保证缓存被删除。

针对业务一致性要求高的场景，如何确保缓存与数据库的一致性？

旁路缓存、Read/Write Through、延迟双删、基于 binlog 的最终一致性。

如何避免缓存失效？

有两种方式。

最简单的方式是业务上线之后开启一个后台线程持续检查缓存是否有效，如果失效立马查数据库重放缓存。

进阶的方式是缓存失效后，业务线程将重放缓存的操作打包为消息事件发送到 MQ。后台缓存重放线程从 MQ 消费消息之后再次查缓存，如果缓存失效就去数据库重放缓存。

如何实现延迟队列？

通过 Redis 的 ZSET 数据结构可以实现延迟队列。具体来说，设置 ZSET 中 value 的 score 为到期时间，它的值可以设置为当前时间 + 延迟时间。要处理延迟消息时，通过 zrangebyscore 查找出所有 score 小于当前时间的消息，就是已经到期的消息，处理这些消息即可。

如何设计一个缓存策略，以动态缓存热点数据？

仍然可以通过 ZSET 数据结构来完成。比如针对一件商品，它的浏览量可以作为商品热点的评价依据，每被浏览一次，就通过 zadd 为该商品添加相应的分数。可以使用时间来对分数进行初始化，使得商品的热度随时间下降。

Redis 实现分布式锁？

Redis 分布式锁的原理是：通过一个全局可见的共享内存空间实现跨节点的分布式锁。通过命令 SET key unique_value NX PX time_out 来加锁。NX 可以确保只有 key 不存在时加锁成功，PX 是设置锁的过期时间为 time_out。unique_value 是 key 的唯一标识，在释放锁的时候，可以通过 lua 脚本确保锁校验和锁释放的原子性。

Watchdog 锁续期机制
Redis 分布式锁有 Watchdog 锁续期机制，客户端获取锁之后，会开启一个后台线程，如果锁要到期但是业务执行尚未结束，会延长锁的时间。业务执行结束后由后台线程释放锁。

Redis 分布式锁单点故障
通过 RedLock 算法可以避免单点故障。具体来说，客户端想要获取 Redis 分布式锁时，需要向若干个 Redis 集群或 Redis 单例发送加锁请求，多数 Redis 主节点同意之后才算加锁成功。锁释放时，同样需要向这些 Redis 主节点发送锁释放请求。

Redis 分布式锁的优缺点？

优点：性能高效，实现方便，可以通过 RedLock 避免单点故障。
缺点：分布式锁的过期时间不好把控（但是可以通过 Watchdog 续期）。此外，Redis 主从复制是异步的，这可能会导致分布式锁的不一致，例如 Redis Sentinel 集群中，Redis 主节点获取锁之后还没来得及同步到从节点就宕机了，此时主持 Sentinel 选取从节点成为新的主节点，这个主节点仍然可以接收加锁请求，导致锁冲突。解决单点故障（一个 Sentinel 集群只有一个主节点，所以 Redis 集群也是单点，多个主节点才构成多点以避免单点故障）的方法是通过 RedLock 向多个 Redis 主节点请求加锁，多数同意才视为加锁成功。

Redis 如何解决集群模式下分布式锁的可靠性？

RedLock 算法。

其具体步骤为：

客户端请求加锁，记录当前时刻 $t_1$ ；
多数 Redis 主节点收到加锁请求并响应给客户端，客户端才认为加锁成功，此时记录时刻 $t_2$ ；
计算获取锁的时间 $t_2 - t_1$ ，如果大于锁的过期时间则认为加锁失败，向所有节点发送锁释放请求；
否则认为加锁成功，锁的过期时间为 $timeout - (t_2 - t_1)$ 。

Redis 管道有什么作用？与事务的区别？

Redis 的 Pipeline 指的是在客户端累积若干个 Redis 请求一并发送到 Redis 服务器，Redis 服务器处理这些请求后将返回结果打包发回给客户端。Pipeline 的核心作用是降低 Redis 请求与相应的 RTT，即减少网络 I/O。Pipeline 中即使有请求失败，也不会影响其他请求的执行。

事务通过 MULTI 和 EXEC 命令执行，如果这两条命令之间存在语法错误，则认为事务失败，否则即使有一条命令执行失败，也不会导致事务中其他命令执行失败。故 Redis 的事务不具备回滚能力，但由于 Redis 采用单线程模型，每一条命令天然具有原子性。

在实际使用中，推荐使用 lua 脚本来实现 Redis 事务，因为 lua 脚本具备事务回滚的能力，并且 lua 脚本当中可以引入复杂的逻辑判断。

Redis 的线程模型

简述 Redis 的线程模型

Redis 在底层有一个文件事件处理器，它是单线程的，因此 Redis 是单线程的。文件事件处理器分为两个部分，分别是事件分派器和事件处理器。具体来说，文件事件处理器会通过多路 I/O 复用技术监听多个 socket，将产生的事件压入事件分派器当中，事件分派器将具体的事件发送给特定的事件处理器处理事件，比如连接应答处理器、命令请求处理器、命令回复处理器等。

Redis 6.0 之前和之后，处理具体命令都是通过单线程来完成的，只不过 6.0 之前，网络 I/O 等请求也是通过单线程来完成的，6.0 之后引入多线程辅助网络 I/O。

Redis 集群

Redis 集群模式有哪些？

主从：集群当中有且仅有一个主节点，以及若干个从节点。主节点可读可写，从节点只读。
哨兵：主从集群的升级版，集群中仍然有且只有一个主节点，至少 3 个（一定是奇数个）哨兵节点，以及若干个从节点。哨兵的引入为 Redis 集群提供了故障恢复和故障转移功能，并可以持续向客户端同步 Redis 服务的状态。
切片：针对缓存较大的情况，切片集群将数据划分到若干个节点当中，这些节点都是主节点，它们都是可读可写的，每个主节点有自己的若干个只读的从节点。通过 CRC 算法实现 Key 到哈希槽的映射，哈希槽在集群上线时自动或手动地分配到具体的物理节点。

Redis 切片集群的工作原理

切片集群有 16384 个哈希槽，通过 CRC 算法将 Key 映射为 0～65536 之间的一个整型，在取模映射到各个哈希槽。哈希槽在集群上线时自动或手动分配到具体的切片集群节点。

主从模式的同步过程？

从节点与主节点建立 socket 连接之后，维护主节点的 run_id 以及一个 offset。

之后，从节点向主节点发送同步请求，主节点会生成一个 RDB 文件发送给从节点，并将 RDB 快照生成期间的数据记录到缓冲区中，RDB 发送之后将缓冲区中的命令一并发送到从节点。

从节点加载 RDB 以及缓冲区命令完成同步。

在增量同步阶段，通过主从节点各自维护的 offset 确定数据同步进度。如果差距过大，则重新进行全量同步。需要补充的一点是，在增量同步阶段，主节点向从节点同步的是具体的 Redis 命令。

主服务器如何知道要将哪些数据发送给从服务器？

主从集群当中，主从节点各自维护一个 offset。增量同步阶段，主从之间比对 offset 确定进度。如果从节点下线后再次上线，要读取的数据在 repl_backlog_buffer 中，则采用增量同步，否则重新进行全量同步。

如何避免主从复制的不一致？

无法完全避免。可行的方法包括：将主从节点在物理上放置在同一个机房降低网络传输延迟；或者由外部进程监控同步进度，差距过大时下线从节点，让客户端直接访问主节点。

主从结构中过期的 key 如何处理？

依赖于主节点同步过期键删除的命令。从节点不会主动删除过期键，即使有客户端请求到来，也不会惰性删除过期键，而是返回值。

主从复制是同步复制还是异步复制？

异步复制。主节点接收到写命令先写入缓冲区，再择机同步给从节点，确保高可用低时延。

什么是哨兵机制？

Sentinel 机制的引入是对主从集群的升级，进一步为主从集群引入了故障恢复和故障转移功能，并可以持续同步给客户端集群的状态。

具体来说，当主节点因故障宕机时：

主观下线：单个 Sentinel 节点检测到主节点宕机；
客观下线：多个 Sentinel 之间达成主节点宕机的共识；

客观下线后，Sentinel 之间选举出一个领导人，领导者 Sentinel 会选出一个最优的从节点作为新的主节点，重新上线服务并将 Redis 服务的状态同步给客户端。

多个 Sentinel 之间通过 Raft 算法确保达成共识。

什么是集群的脑裂？

存在于可能的网络分区故障当中。比如 Redis 主节点和少部分 Sentinel 处于分区 A，大量从节点和大量 Sentinel 处于分区 B。当分区 A 和 B 之间因故断联后，B 区多数 Sentinel 认为 Redis 主节点宕机而客观下线，选举出一个新的 Redis 主节点，此时分区故障恢复，会短暂地存在两个 Redis 主节点，旧的主节点发现已经有了新的主节点会自动降级，但是分区断联时 A 区的主节点处理的写请求会丢失，造成数据不一致，这就是集群的脑裂。