rdb配置需按业务写入频率与容忍丢失窗口调优：高频场景用save 60 10000，中低频用save 300 10，金融类须配aof；stop-writes-on-bgsave-error应设为yes并监控redis_rdb_last_bgsave_status；rdbcompression和rdbchecksum均建议开启以平衡空间、安全与完整性。
RDB配置不能只靠默认值，必须根据写入频率和容忍丢失窗口手动调优。 默认的 save 900 1 在大多数业务中形同虚设——用户登录、订单创建、实时计数等场景下，每秒都有成百上千次写入，但可能连续几小时都没人改某个冷 key，结果 RDB 根本不触发。不改配置，等于没开持久化。
如何设置合理的 save 规则？
核心是匹配「业务能接受的最大数据丢失时间」和「实际写入节奏」：
- 高频写入（如会话、埋点）：用
save 60 10000或更激进的save 30 5000，确保 30–60 秒内有足够变更就落盘 - 中低频写入（如配置、用户资料）：保留
save 300 10，兼顾 CPU 和安全性 - 绝对不允许丢失的场景（如金融类操作日志）：单靠 RDB 不够，必须搭配 AOF 或混合模式
- 注意：多个
save行是「或」关系，满足任一即触发BGSAVE；不要堆砌几十条，反而增加 fork 频率
为什么 stop-writes-on-bgsave-error 要设为 yes？
这个配置控制当 BGSAVE 失败（比如磁盘满、权限不足、OOM kill 子进程）时，Redis 是否继续接受写命令。设为 no 看似“服务不中断”，实则埋雷：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 后续所有写入都只存在内存里，没人知道 RDB 已经停摆
- 运维巡检很难及时发现，直到某次重启，发现 dump.rdb 是 3 天前的旧文件
- 设为
yes后，Redis 会返回错误ERR background save is running或直接拒绝写入，强制你立刻处理磁盘问题 - 配套动作：必须监控
redis_rdb_last_bgsave_status指标，告警失败事件
rdbcompression 和 rdbchecksum 开关怎么选？
这两个开关影响 RDB 文件生成时的行为，不是“开了就一定更好”：
-
rdbcompression yes：启用 LZF 压缩，对长字符串 value（>20 字节）生效。节省 30–50% 磁盘空间，但 fork 后子进程 CPU 使用率略升；生产环境建议开启，除非你明确压测发现压缩成为瓶颈 -
rdbchecksum yes：在 RDB 文件末尾写入 CRC64 校验和。加载时校验可避免静默损坏（比如磁盘坏道导致部分字节翻转），但增加约 1% 加载耗时；线上必须开启，禁用等于放弃数据完整性兜底 - 注意：
rdbcompression和rdbchecksum都只作用于新生成的 RDB 文件，不影响已存在的 dump.rdb
真正容易被忽略的是：RDB 文件本身不是“备份完成”的终点。它只是快照，不包含从上次快照到当前时刻的所有变更。如果你依赖 RDB 做分钟级恢复，必须确认业务能接受这个窗口的数据丢失——否则，得切到 AOF 或混合模式，而不是在 save 参数上反复调参。
