持久化与过期淘汰
041 RDB 持久化的本质是？
难度： 基础
- A. 按策略生成内存数据的二进制快照文件（dump.rdb）
- B. 记录每条写命令的追加日志
- C. 只保存热 key，不保存全部数据
- D. 保存 SQL 语句用于恢复
查看答案与解析
正确答案A
正确原因： RDB 是某个时间点的数据快照，恢复速度快。
关键边界： 可能丢失最后一次快照之后的写入，需结合 AOF 或定期快照。
错误选项辨析： 逐条记录写命令是 AOF，RDB 保存全部键值而非 SQL。
042 AOF 持久化的本质是？
难度： 基础
- A. 以追加方式记录每个写命令，重启时重放恢复
- B. 只记录读命令
- C. 定期全量覆盖数据
- D. 与 RDB 完全相同
查看答案与解析
正确答案A
正确原因： AOF 记录写命令（RESP 协议格式），重启时按序重放。
关键边界： 文件随写入增长，可通过重写压缩。
错误选项辨析： AOF 只记录写命令，不是全量覆盖，机制与 RDB 完全不同。
043 AOF 的三种 fsync 策略是？
难度： 基础
- A. 快速、普通、慢速
- B. always、everysec、no
- C. 同步、半同步、异步
- D. 立即、延迟、永不
查看答案与解析
正确答案B
正确原因： always 每条命令刷盘最安全最慢，everysec 每秒刷盘是默认权衡，no 交给操作系统。
关键边界： everysec 在极端情况下仍可能丢失约 1 秒数据。
错误选项辨析： 官方策略只有 always、everysec、no 三种命名。
044 混合持久化（aof-use-rdb-preamble）是？
难度： 基础
- A. 同时写两份 AOF 文件
- B. AOF 文件头部用 RDB 快照，后续追加增量命令，兼顾恢复速度与数据完整性
- C. 完全放弃 AOF，只用 RDB
- D. 混合模式禁止恢复
查看答案与解析
正确答案B
正确原因： Redis 4.0 起支持，加载时先读 RDB 部分再重放增量，恢复更快。
关键边界： 需要同时开启 AOF 并启用该配置。
错误选项辨析： 它只写一份 AOF，不放弃 AOF，恢复流程正常。
045 BGREWRITEAOF 的作用是？
难度： 基础
- A. 立即删除 AOF 文件
- B. 把 AOF 转成 RDB
- C. 后台重写 AOF，去除冗余命令，生成紧凑文件
- D. 加速 AOF 文件的读取
查看答案与解析
正确答案C
正确原因： 重写由子进程完成，父进程继续服务，期间新写命令进入重写缓冲。
关键边界： 可通过配置自动触发，也可手动执行。
错误选项辨析： 重写是压缩而非删除，不转换文件类型，也不改变读取方式。
046 Redis 删除过期 key 的两种机制是？
难度： 基础
- A. 只依赖惰性删除
- B. 只依赖定期删除
- C. 惰性删除（访问时）加定期删除（后台抽样）
- D. 由客户端负责删除
查看答案与解析
正确答案C
正确原因： 惰性删除在访问时清理，定期删除后台抽样，两者配合。
关键边界： 过期 key 不会立即消失，是渐进式清理。
错误选项辨析： 单靠一种机制会漏删或耗 CPU，删除完全由服务端负责。
047 设置 maxmemory 后，Redis 的淘汰策略包括？
难度： 基础
- A. 只有删除全部数据一种
- B. 只对持久化文件生效
- C. 淘汰策略与内存无关
- D. 多种 LRU、LFU、随机与 TTL 类策略（如 allkeys-lru、volatile-ttl）
查看答案与解析
正确答案D
正确原因： Redis 提供 8 种策略，按 allkeys 或 volatile 与 lru、lfu、random、ttl 组合。
关键边界： noeviction 策略下内存写满会拒绝写入。
错误选项辨析： 淘汰只作用于内存数据，策略种类丰富。
048 allkeys-lru 与 volatile-lru 的区别是？
难度： 基础
- A. 两者完全相同
- B. volatile-lru 会删除没有过期的 key
- C. allkeys-lru 只淘汰冷数据且永不删除热数据
- D. allkeys 从所有 key 中淘汰；volatile 只从设置了过期时间的 key 中淘汰
查看答案与解析
正确答案D
正确原因： 前缀决定候选集：allkeys 是全部 key，volatile 仅限有 TTL 的 key。
关键边界： volatile 系列在无过期 key 时退化为 noeviction 行为。
错误选项辨析： 候选集不同，volatile 不碰无过期 key，LRU 会淘汰最久未访问的数据。
049 LRU 与 LFU 的区别是？
难度： 进阶
- A. LRU 按最近访问淘汰；LFU 按访问频率淘汰，更能保留高频但偶发的热 key
- B. LFU 是 LRU 的随机版本
- C. LRU 记录所有访问次数
- D. 两者实现完全相同
查看答案与解析
正确答案A
正确原因： LFU 通过计数器统计访问频率，周期性热点数据比 LRU 更不容易被误淘汰。
关键边界： Redis 的 LRU/LFU 都是近似实现，基于抽样。
错误选项辨析： LFU 不是随机版本，LRU 不看次数，两者机制不同。
050 noeviction 策略下内存写满会怎样？
难度： 进阶
- A. 拒绝写命令并返回 OOM 错误，读命令仍可用
- B. 自动删除任意 key 继续写入
- C. 直接崩溃重启
- D. 暂停所有读请求
查看答案与解析
正确答案A
正确原因： noeviction 不淘汰任何 key，写命令返回错误，读不受影响。
关键边界： 适用于业务不希望数据被淘汰的场景，需监控内存。
错误选项辨析： 不自动删除、不崩溃、不影响读。
051 内存碎片产生的主要原因是？
难度： 进阶
- A. key 数量太少
- B. 频繁的分配与释放、不同大小对象交错，导致内存空洞
- C. CPU 主频太低
- D. 网络带宽不足
查看答案与解析
正确答案B
正确原因： 分配器无法完全复用释放的空间，形成碎片。
关键边界： 碎片率可用 MEMORY PURGE 或重启缓解，日常监控 used_memory_rss。
错误选项辨析： key 少、CPU、带宽都与碎片无直接关系。
052 Redis 小对象内存优化手段包括？
难度： 进阶
- A. 给所有 key 加超长前缀
- B. 使用紧凑编码、共享整数、控制字段数量
- C. 用大量空 List 占位
- D. 关闭内存统计
查看答案与解析
正确答案B
正确原因： listpack/ziplist 紧凑编码与整数共享可显著减少小对象内存。
关键边界： hash-max-listpack-entries 等阈值参数可调，需权衡转换成本。
错误选项辨析： 超长前缀与空占位只会浪费内存，关闭统计不能优化内存。
053 RDB 快照（BGSAVE）的 fork 子进程与 COW 关系是？
难度： 进阶
- A. 快照期间 Redis 完全停止服务
- B. 子进程与父进程共享全部内存页且不复制
- C. 子进程快照期间父进程继续写，靠写时复制（COW）保证快照一致性
- D. COW 只在 AOF 模式生效
查看答案与解析
正确答案C
正确原因： fork 后子进程读内存生成快照，父进程写页时复制该页，保证快照一致。
关键边界： 写密集时 COW 会放大内存占用。
错误选项辨析： 快照不停止服务，COW 需要复制被写的页，RDB 与 AOF 都可能涉及。
054 RDB 与 AOF 选型的一般建议是？
难度： 进阶
- A. 只能二选一，不能共存
- B. AOF 恢复速度总是快于 RDB
- C. 追求恢复速度用 RDB，追求少丢数据用 AOF，两者可同时开启
- D. RDB 一定比 AOF 更安全
查看答案与解析
正确答案C
正确原因： RDB 恢复快，AOF 丢失窗口小，生产常用 AOF 加定期 RDB 组合。
关键边界： 8.0 起支持 RDB 增量持久化，需按业务权衡。
错误选项辨析： 两者可共存，AOF 恢复通常更慢，RDB 的安全性取决于快照频率。
055 持久化文件损坏时怎么办？
难度： 基础
- A. 数据库会自动从备份云恢复
- B. 文件损坏不影响任何数据
- C. 必须重装系统才能恢复
- D. 用 redis-check-rdb 或 redis-check-aof 工具检查修复，坏数据可能被丢弃
查看答案与解析
正确答案D
正确原因： 官方工具可诊断并尽力修复，损坏尾部可能被截断丢弃。
关键边界： 定期演练备份恢复流程比临时修文件更重要。
错误选项辨析： 不会自动云端恢复，损坏会影响数据，也无需重装系统。
056 主从首次全量同步如何传输数据？
难度： 进阶
- A. 从库逐条执行所有历史命令
- B. 主库把整个数据目录复制给从库
- C. 从库只接收 binlog 文件
- D. 主库生成 RDB 快照发给从库，从库加载后继续接收增量
查看答案与解析
正确答案D
正确原因： 全量阶段传输 RDB 加期间新增命令缓冲，从库加载后追增量。
关键边界： 数据量大或网络差时全量耗时明显，可优化 backlog 避免频繁全量。
错误选项辨析： 历史命令回放不现实，复制的是 RDB 而非目录或 binlog。
057 大 key 对持久化的影响是？
难度： 实战
- A. RDB 快照与 AOF 重写时大 key 序列化耗时，可能造成阻塞与写放大
- B. 大 key 只影响读命令
- C. 持久化自动跳过所有大 key
- D. 大 key 对内存没有任何占用
查看答案与解析
正确答案A
正确原因： 大 key 的序列化、传输与删除都可能阻塞主线程并放大 I/O。
关键边界： 应拆分或控制单 key 大小，定期扫描大 key。
错误选项辨析： 大 key 影响读写与持久化，不会自动跳过，占用大量内存。
058 AOF 使用 everysec 时出现主线程阻塞的可能原因是？
难度： 实战
- A. everysec 永远不会阻塞
- B. 磁盘 I/O 慢导致 fsync 队列积压，write 系统调用阻塞主线程
- C. 阻塞只发生在 always 且与磁盘无关
- D. 阻塞会由从库自动接管
查看答案与解析
正确答案B
正确原因： everysec 由后台线程 fsync，但磁盘极慢时积累的写请求仍可能阻塞主线程。
关键边界： 需监控 aof_pending 等指标，必要时换磁盘或调参。
错误选项辨析： everysec 也可能阻塞，阻塞与磁盘性能相关，从库不接管。
059 数据安全与性能的权衡中？
难度： 基础
- A. 关闭持久化后数据也绝对安全
- B. 刷盘频率与性能无关
- C. 刷盘越频繁数据越安全但性能越差，需按业务丢失容忍度选择
- D. 所有业务都必须用 always
查看答案与解析
正确答案C
正确原因： always 最安全但吞吐低，不持久化性能最好但重启全丢。
关键边界： everysec 是常见折中，可按业务重要性分级配置。
错误选项辨析： 关闭持久化不安全，刷盘影响性能，并非所有业务都适合 always。
060 实例故障恢复时，Redis 的加载顺序是？
难度： 进阶
- A. 同时加载两份并合并
- B. 只加载 RDB，忽略 AOF
- C. 恢复由客户端决定
- D. 优先加载 AOF（若开启），否则加载 RDB
查看答案与解析
正确答案D
正确原因： AOF 数据更完整，开启时优先加载，无 AOF 才用 RDB。
关键边界： 加载大文件期间实例不可服务，需预留时间。
错误选项辨析： 不会合并加载，AOF 优先于 RDB，恢复由服务端决定。