一、总览类
Q1：Redis 有哪几种持久化方式？
RDB：快照，二进制存某个时间点的全量数据。
AOF：追加日志，记录每条写命令。
混合持久化：RDB 全量 + AOF 增量，Redis 4.0+。
无持久化：纯缓存场景可关闭。
Q2：RDB 和 AOF 的区别？
Q3：怎么选择持久化方式？
只做缓存：可关闭持久化。
能容忍少量丢失：RDB。
数据安全要求高：AOF 或混合持久化。
生产推荐：混合持久化 + 合理刷盘策略。
二、RDB 类
Q4：RDB 是什么？
Redis DataBase，把内存数据以二进制快照写入
.rdb文件。文件紧凑，恢复快。
是某个时间点的全量数据。
Q5：RDB 的触发方式？
手动：
SAVE（阻塞）、BGSAVE（fork 子进程）。自动：配置
save <seconds> <changes>，如save 900 1。其他：主从全量同步、
SHUTDOWN、FLUSHALL后。
Q6：SAVE 和 BGSAVE 的区别？
SAVE：主线程执行，阻塞所有请求。BGSAVE：fork 子进程执行，主线程继续处理请求。生产用
BGSAVE。
Q7：BGSAVE 的原理？
主线程 fork 子进程。
子进程遍历内存，写入临时 RDB 文件。
写完替换旧文件。
fork 用 COW（Copy-On-Write），主线程写时才复制页。
Q8：什么是 COW？
fork 后父子进程共享内存页，只读。
主线程写某页时，才复制该页给子进程。
减少 fork 时的内存复制。
但写入多时，复制页多，内存可能翻倍。
Q9：fork 有什么代价？
fork 本身阻塞主线程，数据量大时明显。
COW 期间内存可能增长，甚至 OOM。
子进程写 RDB 占用 CPU 和磁盘 IO。
大实例建议控制 fork 频率。
Q10：RDB 的优缺点？
优点：文件小、恢复快、适合备份。
缺点：可能丢数据（两次快照之间）、fork 有开销、大实例卡顿。
三、AOF 类
Q11：AOF 是什么？
Append Only File，记录每条写命令。
恢复时重放命令重建数据。
默认关闭，
appendonly yes开启。
Q12：AOF 的写入流程？
命令写入 AOF 缓冲区（aof_buf）。
按刷盘策略写入 AOF 文件。
按策略 fsync 刷盘。
AOF 重写压缩文件。
Q13：AOF 的刷盘策略？
生产推荐
everysec，兼顾安全和性能。
Q14：AOF 重写是什么？为什么需要？
AOF 文件会越来越大，恢复慢。
重写：根据当前数据生成最小命令集，替换旧 AOF。
例：100 次
INCR重写为一次SET key 100。触发：
BGREWRITEAOF或配置auto-aof-rewrite-percentage。
Q15：AOF 重写的原理？
主线程 fork 子进程。
子进程遍历内存，写新 AOF 文件。
主线程继续处理命令，同时写入 AOF 重写缓冲区。
子进程写完，主线程把重写缓冲区追加到新文件。
替换旧 AOF。
Q16：AOF 重写期间数据会丢吗？
不会。重写缓冲区记录期间的写命令。
重写完成后追加，保证不丢。
但重写期间内存和 CPU 有开销。
Q17：AOF 的优缺点？
优点：实时性好，可每秒刷，丢数据少。
缺点：文件大、恢复慢、重写有开销。
四、混合持久化类
Q18：什么是混合持久化？
Redis 4.0+ 引入。
AOF 重写时，前半部分用 RDB 格式存全量，后半部分用 AOF 格式存增量。
兼顾 RDB 恢复快和 AOF 丢数据少。
Q19：混合持久化怎么开启？
aof-use-rdb-preamble yes（默认 yes）。需先开启 AOF：
appendonly yes。
Q20：混合持久化的恢复流程？
加载 RDB 部分，快速恢复大部分数据。
重放 AOF 部分，补齐增量。
恢复速度快于纯 AOF。
Q21：混合持久化的优缺点？
优点：恢复快、丢数据少、文件相对小。
缺点：AOF 文件可读性差（含二进制）、兼容性要求 4.0+。
五、数据恢复类
Q22：Redis 启动时怎么恢复数据？
如果开启 AOF，优先加载 AOF。
否则加载 RDB。
AOF 恢复慢但数据新；RDB 恢复快但可能旧。
Q23：RDB 和 AOF 同时存在，加载哪个？
优先 AOF，因为 AOF 数据更完整。
前提是 AOF 开启且文件存在。
Redis 4.0+ 混合持久化时，AOF 文件含 RDB 头。
Q24：AOF 文件损坏怎么办？
redis-check-aof --fix appendonly.aof修复。会丢弃损坏部分之后的数据。
修复后重启加载。
Q25：RDB 文件损坏怎么办？
redis-check-rdb dump.rdb检查。损坏严重可能无法恢复。
依赖备份。
六、性能与运维类
Q26：持久化对性能有什么影响？
BGSAVEfork 阻塞主线程，COW 增加内存。AOF
always每次 fsync，性能差。everysec折中，最多丢 1 秒。重写期间 CPU、内存、磁盘压力大。
Q27：怎么优化持久化性能？
用
everysec而非always。控制 fork 频率，避免频繁
BGSAVE。大实例用主从，从库持久化。
用 SSD，提升磁盘 IO。
合理设置
auto-aof-rewrite-percentage。
Q28：主从架构下持久化怎么配？
主库可关闭持久化，提升性能。
从库开启 AOF/RDB，保证数据安全。
但主库关闭持久化有风险，重启可能丢数据。
常见：主库 RDB + 从库 AOF。
Q29：appendfsync everysec 会丢多少数据？
最多丢 1 秒的写命令。
如果 fsync 时磁盘慢，可能更多。
要求不丢用
always，但性能差。
Q30：BGSAVE 和 BGREWRITEAOF 能同时执行吗？
不能同时执行，会排队。
如果
BGSAVE在执行，BGREWRITEAOF会延迟。反之亦然。避免频繁触发。
七、高频陷阱题
Q31：RDB 一定丢数据吗？
是。两次快照之间的写会丢。
除非配合 AOF。
所以 RDB 不适合高数据安全场景。
Q32：AOF 一定不丢吗？
不一定。
everysec最多丢 1 秒。always理论上不丢，但性能差。还有磁盘故障等极端情况。
Q33：fork 会复制所有内存吗？
不会。COW 只复制被修改的页。
但写入多时，复制页多，内存可能接近翻倍。
所以大实例要注意内存余量。
Q34：AOF 重写会阻塞吗？
fork 瞬间阻塞，之后子进程执行。
主线程继续处理命令。
但重写缓冲区追加时有短暂阻塞。
Q35：混合持久化还是纯 AOF 吗？
是 AOF 的一种形式，文件仍是 AOF。
只是内容前半是 RDB 格式。
加载时按 AOF 流程，先读 RDB 头再重放。
Q36：Redis 能同时用 RDB 和 AOF 吗？
能。两者可同时开启。
恢复优先 AOF。
生产常用混合持久化替代纯 AOF。
评论