持久化、内存淘汰与数据安全

学习目标

根据可接受丢失窗口选择持久化与淘汰策略，在隔离副本验证恢复。

核心知识点

本篇采用 Redis 8 稳定主版本的基础语义；官方文档核对日期：2026-10-06，不声明未验证的补丁版本。需要更高小版本的选项单独标明。

RDB 保存快照，AOF 记录写入；内存淘汰是容量策略，持久化是重启数据来源，备份是独立恢复副本，三个机制不可互相代替。持久化成功也不能防止业务误删除被持久化。

实验只在本机独立可丢弃 Redis 8、数据库 0 中执行。先通过终端运行 redis-cli -h 127.0.0.1 -p 6379，在交互提示符输入 redis 代码块；有 ACL 时使用 --user lab_user --askpass，不在命令中写密码。输出数组的排版因客户端而异。每节独立重建输入，命名空间 lab:{reliability}: 专用于学习；开始和结束只清理本节明确列出的 key，不把通配符传给删除命令。运行前确认没有业务数据，配置与恢复步骤另按注明的受控前提执行。

常用用法

BGSAVE：RDB 快照与 fork 成本

用于在有资源余量的可丢弃实例创建快照并检查完成状态。

# 危险：只在已确认磁盘与内存余量的独立本机实例执行；生产先评估 fork 与 I/O 峰值。
SET lab:{reliability}:saved before
# 边界：BGSAVE 仅用于受控测试环境，先验证备份目录与资源余量。
BGSAVE
# 边界：INFO 在受控诊断连接读取状态，生产需限制频率和输出权限。
INFO persistence
# 初始：无后台持久化任务，目录可写，学习 key 保存 before。
# 关键变化：后台生成某一时点的 RDB 快照，命令返回不表示已落盘。
# 输出：OK、Background saving started；等待后 rdb_bgsave_in_progress:0、rdb_last_bgsave_status:ok。

BGSAVE fork 子进程，fork 本身暂停主线程，写入期间 copy-on-write 增加内存；快照成本随数据量和磁盘吞吐增长。RDB 恢复紧凑快，但崩溃会丢失最后成功快照以后的更新。SAVE 同步阻塞整个服务，不能作为随手生产备份。监控 latest_fork_usec、rdb_last_cow_size 与磁盘空间；错误时先保留旧备份。BGSAVE。

CONFIG GET：AOF 的 fsync 策略与丢失窗口

用于只读核对实例的追加日志配置并确定预期数据安全等级。

# 初始：本机实例由 redis.conf 配置启动，已记录 appendonly 与 appendfsync。
CONFIG GET appendonly appendfsync
# 边界：INFO 在受控诊断连接读取状态，生产需限制频率和输出权限。
INFO persistence
# 关键变化：读取配置与 aof_last_write_status 等状态形成安全检查结果。
# 输出：appendonly 的 yes/no 与 appendfsync 的 always/everysec/no；具体值取决于启动配置。

配置流程（在独立测试实例的 redis.conf 中预先设置后启动）：appendonly yes、appendfsync everysec；确认 aof_enabled:1 和 aof_last_write_status:ok。always 每次写入 fsync，更耐久但增加延迟，仍依赖硬件/OS 正确实现；everysec 后台约每秒 fsync，通常最多丢约一秒更新，I/O 阻塞等异常不能当严格上限；no 由 OS 决定刷盘，丢失窗口更大且无固定保障。评估 no-appendfsync-on-rewrite，开启可能放大重写期损失。复制成功不等于本地 fsync，也不是备份。持久化 fsync 策略、CONFIG GET。

BGREWRITEAOF：混合持久化与多文件 AOF

用于在已启用 AOF 的独立实例观察日志重写过程。

# 危险：只在已备份并验证资源余量的独立本机实例执行，不能随意在生产触发重写。
# 初始：appendonly yes、aof-use-rdb-preamble yes，由测试配置文件设置。
SET lab:{reliability}:saved after
BGREWRITEAOF
# 边界：INFO 在受控诊断连接读取状态，生产需限制频率和输出权限。
INFO persistence
# 关键变化：为当前数据构造新的 AOF 基础文件，增量写继续记录。
# 输出：OK、重写开始/计划中的状态；完成后 aof_rewrite_in_progress:0、aof_last_bgrewrite_status:ok。

混合持久化把 RDB 编码的基础数据和后续 AOF 增量结合，不是取消 fsync。Redis 7+ 多文件 AOF 使用 manifest 管理基础/增量文件，恢复与备份必须保留完整文件集合，不能只复制旧式 appendonly.aof。重写也有 fork、COW、I/O 和短暂切换成本；若后台任务冲突，命令可能安排后续重写而非马上完成。RDB+AOF 同启时启动通常选择 AOF，因此要验证实际加载来源。BGREWRITEAOF、Redis AOF 文件布局。

CONFIG GET：maxmemory 与淘汰策略选择

用于核对内存上限和淘汰规则并观察当前内存占用。

CONFIG GET maxmemory maxmemory-policy maxmemory-samples
# 边界：INFO 在受控诊断连接读取状态，生产需限制频率和输出权限。
INFO memory
# 边界：INFO 在受控诊断连接读取状态，生产需限制频率和输出权限。
INFO stats
# 初始：测试实例由 redis.conf 配置启动，已记录 maxmemory 字节上限。
# 关键变化：把策略配置与 used_memory、evicted_keys、keyspace_hits/misses 关联起来。
# 输出：maxmemory 字节数、maxmemory-policy 名称与 maxmemory-samples 数值；统计随负载变化。

受控配置流程：可重建纯缓存评估 allkeys-lru（近似近期访问）或 allkeys-lfu（近似频率），均用采样而非严格全局排序；均匀访问可用 allkeys-random。volatile-lru/lfu/random 只淘汰带 TTL 的 key，volatile-ttl 倾向剩余 TTL 最短；没有候选时可能拒写。noeviction 拒绝需要新增内存的写入，读通常仍可用，适合不能静默丢数据的用途但必须处理 OOM，不能替代容量规划。maxmemory 不是 RSS 硬上限；复制/AOF 缓冲、COW、碎片需留余量。数据不可重建时应与缓存隔离实例。危险：降低 maxmemory 或改策略会触发淘汰，生产变更需记录旧配置、验证命中率及回滚配置；被淘汰数据不会随回滚恢复。淘汰策略、Redis 8.0 配置选项。

INFO persistence：恢复检查与生产操作边界

用于在隔离恢复实例中核验持久化状态和关键数据。

# 初始：已在隔离本机端口 6380 用备份副本启动 Redis，禁止连接原生产地址。
# 本段交互命令应在 redis-cli -h 127.0.0.1 -p 6380 中执行。
# 边界：INFO 在受控诊断连接读取状态，生产需限制频率和输出权限。
INFO persistence
GET lab:{reliability}:saved
# 关键变化：恢复副本 loading 从 1 变为 0 后读回 saved 的备份值。
# 输出：loading:0；GET 应与备份时点记录一致，例如 "before"。

危险：生产恢复可能覆盖数据，属于受控运维流程，不直接复制备份到运行目录或执行 FLUSH*。先冻结变更、确认恢复点与 RPO/RTO、备份现状并计算校验和；在副本上按实际版本核查 RDB/AOF（多文件含 manifest），检查工具先只读，任何 --fix 只对副本并承认可能截断丢数据。隔离启动，核验 key 数、抽样值、TTL、ACL、持久化状态、业务不变量和读写测试。过期时间为绝对时刻，离线备份中的过期 key 可能在恢复时消失。经切换窗口批准后才能替换生产并验证；保留旧实例与旧文件作为回滚点，切换后的新写入需另规划回滚迁移。演练故障而非仅证明文件存在。持久化备份与恢复、INFO。

易混点

持久化文件不等于独立备份，maxmemory 不等于进程 RSS 上限；回滚配置不能复活淘汰数据。

课后小问

1. everysec 是否承诺任意故障最多丢一秒？

答案：它是正常运行下的常见窗口，磁盘阻塞、设置及硬件异常会改变实际结果，应结合演练和监控评估。

2. 怎样处理写命令响应丢失？

答案：响应丢失不能证明没有执行；先检查业务状态，对非幂等写入使用业务 ID、去重记录或有界恢复流程。

本节小结

选择策略时同时计算丢失窗口、fork/COW 峰值、磁盘容量和恢复验证成本。

快速回顾

按 H3 定位真实命令或操作流程，重建初始状态并读回结果，再检查超时、容量和数据安全边界。