主节点必须开启RDB且save规则需匹配业务写入节奏，否则宕机后无法快速恢复；默认save 900 1在低频场景下易致数小时数据丢失，应据INFO stats指标调优阈值，禁用stop-writes-on-bgsave-error，RDB路径须挂载持久化存储卷。
主节点必须开启 RDB，且 save 规则要匹配业务写入节奏
主节点宕机后能否快速恢复，取决于 RDB 是否及时生成有效快照。默认的 save 900 1 在低频写入场景下可能几小时才触发一次，一旦崩溃就丢数严重。
- 观察业务真实写入频率：用
INFO stats查看instantaneous_ops_per_sec和total_commands_processed，再结合evicted_keys、expired_keys判断键变更活跃度 - 调低触发阈值：比如高频写入服务可设为
save 60 100（60 秒内 100 次修改），避免单次故障丢失超 1 分钟数据 - 禁用
stop-writes-on-bgsave-error yes：否则磁盘满或权限问题导致bgsave失败时，主节点直接拒绝写入，高可用架构瞬间降级为只读 - RDB 文件路径
dir必须挂载为持久化存储卷（如 Kubernetes 的PersistentVolume），不能用容器临时目录
AOF 不是“开就完事”，everysec 是生产环境唯一合理选项
很多人以为 appendonly yes 开启 AOF 就万事大吉，但实际中 appendfsync always 会让 QPS 掉 50% 以上，而 no 等于没开——操作系统 flush 周期不可控，断电即丢数。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 强制使用
appendfsync everysec：这是吞吐与安全的唯一平衡点，最多丢失 1 秒数据，且后台线程 fsync 不阻塞主线程 - 务必关闭
auto-aof-rewrite-percentage的默认值（100）：在主从+哨兵架构下，AOF 重写期间子进程 fork + 写文件会加剧主节点 CPU 和 I/O 压力，建议设为0并人工定时执行BGREWRITEAOF - 从节点无需开启 AOF：它只做数据同步和读负载，RDB + 主节点 AOF 日志已足够支撑故障转移后的数据重建
混合持久化（aof-use-rdb-preamble yes）不是可选功能，而是主节点标配
纯 AOF 恢复慢、体积大；纯 RDB 丢数多。Redis 4.0+ 的混合模式把 RDB 快照头 + 增量 AOF 合并在一个文件里，既压缩体积又加速启动——但在高可用场景下，它还有个关键作用：避免哨兵 failover 后从节点加载 AOF 时卡住。
- 必须显式启用：
aof-use-rdb-preamble yes，否则哨兵切换新主后，新主加载纯 AOF 可能因日志过长耗时数十秒，期间无法响应客户端 - 注意
bgrewriteaof行为变化：开启后重写生成的是混合格式文件，文件开头是 RDB 二进制块，后面是文本命令；用redis-check-aof --fix无法修复混合文件，只能用redis-check-rdb配合人工截断 - 备份脚本要适配：传统只备份
dump.rdb的逻辑失效，现在必须备份appendonly.aof（已是混合格式），且不能用cp直接覆盖——需先redis-cli BGREWRITEAOF触发重写再拷贝
哨兵或集群模式下，持久化配置必须在所有节点保持一致
看似无关的配置差异，会在故障转移时引发静默数据不一致。比如主节点开了混合 AOF，从节点没开，哨兵选它当新主后，它会以纯 AOF 方式启动，丢失 RDB 部分数据。
- 所有 Redis 实例（含哨兵监控的每个节点）的
save、appendonly、appendfsync、aof-use-rdb-preamble必须完全相同 - 使用配置中心（如 Consul 或 ConfigMap）统一下发 redis.conf，禁止手工改某台从节点的配置
- 验证方式：连接任一节点执行
CONFIG GET save、CONFIG GET appendonly，结果应全集群一致；不一致时哨兵不会报错，但数据恢复行为不可预测
down-after-milliseconds、failover-timeout 参数存在隐式耦合。比如 RDB 生成耗时 800ms，但哨兵判定主节点失联的阈值设为 500ms，就会在快照写入中途触发误切主——这种问题不会报错，只会表现为切换后部分 key 缺失。 
