Redis生产持久化RDB+AOF
Redis 服务器一旦宕机或重启，默认情况下内存中的数据会全部丢失。
生产环境要保证数据不丢失，最常用的方案是同时开启 RDB 快照和 AOF 日志两种持久化方式。
本文面向零基础运维用户，从原理、配置、重启、故障模拟到验证，完整演示一遍 RDB+AOF 配置过程。
为什么生产环境要采用 RDB+AOF 组合
RDB 是把内存数据定期生成快照文件，恢复速度快，但两次快照之间的数据可能丢；
AOF 是记录每次写操作命令，通过重放日志恢复，最多丢失 1 秒数据（取决于配置）。
单独用 RDB 容易丢数据，单独用 AOF 恢复速度慢且文件大。
生产环境通常两种都开，利用 AOF 保证数据完整性，利用 RDB 做快速冷备和恢复。
配置前的准备
先确认 Redis 版本和安装方式。
不同发行版配置文件路径有差异，常见位置是 /etc/redis/redis.conf 或编译安装目录下的 redis.conf。
验证 Redis 是否正常运行：
redis-cli ping返回 PONG 说明可用。
建议提前备份原配置：
cp redis.conf redis.conf.bak开启 RDB 和 AOF 持久化
编辑 Redis 配置文件，找到或添加以下内容：
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysecsave 行是 RDB 触发规则，
满足任一条件就生成快照；appendonly yes 表示开启 AOF；appendfsync everysec 让 AOF 每秒刷盘一次，
这是性能和安全的均衡选择。
修改后需要重启 Redis 或执行动态加载：
redis-cli CONFIG REWRITECONFIG REWRITE 会把当前运行配置写入文件，但 save 和 appendonly 这类参数建议直接重启确认：
systemctl restart redis重启后检查持久化状态：
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET save确认 appendonly 为 yes，save 配置已生效。
模拟宕机验证数据不丢失
写入测试数据：
redis-cli SET user:name zhangsan然后模拟断电或直接强制 kill 进程：
redis-cli DEBUG sleep 1
kill -9 $(pidof redis-server)再正常启动 Redis：
systemctl start redis读取数据：
redis-cli GET user:name能返回 zhangsan 说明 RDB 和 AOF 已正确恢复。
这时目录下会同时出现 dump.rdb 和 appendonly.aof 两个文件，可用 ls 查看。
避坑和常见疑问
- 开了 AOF 后，Redis 启动优先用 AOF 恢复，因为 AOF 数据更完整；RDB 用于冷备和快速装载。
appendfsync always最安全但写入性能下降明显，普通业务建议使用everysec。- 修改配置后必须确认进程没有静默失败，重启后执行
redis-cli ROLE或查看日志确认角色正常。 - 数据量大的实例，RDB 快照会让主线程阻塞，建议在从节点或业务低峰期执行。
还有一种常见情况：为什么设置了 AOF 重启数据还是丢？
常见原因是配置没生效，或者写入操作发生在 AOF 开启之前。
开启 AOF 后需要先使用 BGREWRITEAOF 生成当前数据集的日志，避免老数据缺失。
如果你正在配置生产 Redis 持久化，建议先完整测试一遍宕机恢复流程，再接入真实业务流量，确认无异常后持续观察。
