持久化方案怎么定
选持久化方案的正确起点不是「用 RDB 还是 AOF」，而是先回答一个问题：这套 Redis 的数据丢了会怎样，业务最多能容忍丢多少。纯缓存可以接受全丢，追求速度而不开持久化；会话、队列、计数这类数据通常能接受秒级丢失，用 AOF everysec 加定期快照；账务、订单状态要求尽量不丢，则在 everysec 基础上叠加多副本与更严格的运维约束。方案是丢数据代价与资源成本之间的取舍。
基本信息
| 判断起点 | 可容忍丢失量（全丢 / 秒级 / 尽量不丢） |
|---|---|
| 常规组合 | AOF everysec 加定期 RDB，是覆盖多数业务的安全默认 |
| 成本项 | 磁盘容量与 IOPS、fork 带来的内存峰值、恢复耗时 |
| 配套要求 | 主从多副本、异地备份、可执行的恢复演练 |
| 反模式 | 只开 RDB 却要求零丢失，或只挂副本而不配任何持久化 |
按业务分档
- 纯缓存：关闭持久化或只留低频 RDB 做冷备，重建成本由回源承担
- 弱一致队列：AOF everysec 足够，失败重投与幂等设计比持久化更重要
- 会话与登录态：AOF everysec 加正常 TTL，丢秒级数据的后果是少量用户重新登录
- 计费类计数：AOF everysec 加多副本，并周期性把 Redis 计数对账落库形成持久事实
- 强一致账务：不要把 Redis 当唯一存储，持久化只作为加速层，真实依据落在关系数据库
核对现状
核对现状
redis-cli CONFIG GET appendonly # 是否开启 AOF
redis-cli CONFIG GET appendfsync # 刷盘策略
redis-cli CONFIG GET save # 快照条件
redis-cli INFO persistence # 一次性看全持久化状态
redis-cli INFO replication | grep -E 'role|connected_slaves' # 副本是否到位
df -h /var/lib/redis # 磁盘余量是否够两份文件场景对照表
| 业务要求 | 建议方案 | 剩余风险 |
|---|---|---|
| 纯缓存可重建 | 关闭持久化或仅 RDB 冷备 | 重启后缓存冷启动，需限流预热 |
| 可丢秒级数据 | AOF everysec 加定期 RDB | 断电可能丢约 1 秒写入 |
| 尽量不丢且性能优先 | AOF everysec 加多副本 | 主从切换窗口内仍可能丢失未同步写入 |
| 强持久化 | appendfsync always 并压测验证 | 吞吐下降，仍需异地备份防整机故障 |
持久化只解决单机重启问题，不解决机器彻底损毁：快照与 AOF 都在本机磁盘上，宿主机不可用时会一起消失。完整的方案必须包含副本与异地备份，并且定期做恢复演练，演练要覆盖真实加载来源。
恢复时间也要纳入选型：RDB 恢复是直接加载，几十 GB 数据可能几分钟；AOF 恢复需要重放命令，同样数据量可能慢数倍。对可用性要求高的业务，恢复时间目标会直接决定「AOF 还是 RDB 为主」。