Redis持久化需权衡数据安全、恢复速度与资源开销，RDB适合快恢复且容忍分钟级丢失的场景（如缓存），AOF适合强一致性业务（如订单），混合模式兼顾RPO与RTO，关键在明确RPO、RTO、资源约束及恢复验证。
Redis 持久化不是“开或不开”的选择题，而是围绕业务对数据安全、恢复速度、资源开销的权衡。RDB 和 AOF 各有明确适用边界，实际中常组合使用，关键在于回答清楚四个问题：最多能接受丢多少数据（RPO）、恢复要多快（RTO）、磁盘和 CPU 能承受多少压力、是否定期验证恢复流程。
RDB 配置要点与适用场景
RDB 是默认开启的快照机制，适合对恢复速度敏感、能容忍短时间数据丢失的场景，比如缓存层、会话存储、实时特征中间态。
- 通过 save 指令配置自动触发时机，例如 save 60 1000 表示 60 秒内至少 1000 个 key 变更就生成一次快照；生产环境建议关闭过于频繁的 save（如 save 1 1），避免 fork 压力过大
- 禁用 RDB 只需注释掉所有 save 行，并设置 rdbcompression yes（默认开启）和 rdbchecksum yes 提高文件可靠性
- 手动触发用 BGSAVE（推荐），绝不用 SAVE——后者会阻塞主线程，导致请求堆积
- 注意 fork 开销：内存越大，fork 瞬间主进程阻塞越明显；若 Redis 占用 20GB 内存，fork 可能卡住毫秒级，需预留足够内存防 OOM
AOF 配置要点与适用场景
AOF 更适合要求强一致性的业务，比如用户积分、订单状态、风控规则等，核心是控制日志同步频率和重写策略。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 启用 AOF 需设置 appendonly yes，日志默认写入 appendonly.aof
- 同步策略选 appendfsync everysec（推荐）：兼顾安全性与性能，最多丢失 1 秒数据；always 过于保守，吞吐量下降明显；no 交由系统调度，风险不可控
- 开启 AOF 重写（auto-aof-rewrite-percentage 100 + auto-aof-rewrite-min-size 64mb），避免日志无限膨胀；重写由子进程完成，不影响主进程服务
- AOF 文件体积通常远大于 RDB，需监控磁盘空间，尤其在高频写入场景下
混合持久化：兼顾快照与增量
Redis 4.0+ 支持混合模式，启动时先加载 RDB 快照，再重放 AOF 尾部增量命令，兼顾恢复速度与数据完整性。
- 只需开启 AOF 并设置 aof-use-rdb-preamble yes（默认开启），无需额外配置
- 生成的 AOF 文件前半段是 RDB 格式二进制快照，后半段是 RESP 协议格式的增量命令，文件比纯 AOF 小、加载比纯 AOF 快
- 注意：混合模式下 AOF 文件不可直接人工编辑，可读性降低，调试难度略增
怎么选：按业务需求做判断
没有通用最优解，只看你的数据价值和系统约束：
- 只要求快速恢复、允许分钟级丢失 → 单独 RDB 即可，比如推荐系统临时缓存
- 不能丢任何写操作、能接受稍慢恢复 → 单独 AOF + everysec，比如支付流水记录
- 既要秒级 RPO 又要秒级 RTO → 混合持久化，配合从节点异步复制，形成完整容灾链路
- 磁盘 IO 已是瓶颈 → 调低 RDB 触发频次、AOF 关闭重写或调大重写阈值，必要时考虑外部备份替代本地持久化
