8.2.5 持久化配置与性能权衡

持久化用于在内存与磁盘之间建立安全边界，核心在于RDB与AOF两种机制的选择与组合。RDB以快照方式周期性落盘，适合对恢复点要求不极端、追求较低运行开销的场景；AOF以命令追加记录，数据完整性更高但写放大与磁盘压力更大。可根据业务对RPO与性能的优先级决定启用策略：性能优先可仅启用RDB，数据安全优先可启用AOF，兼顾可启用RDB+AOF并设置合理的压缩与重写策略。

文章图片

RDB配置要点在于快照频率与阻塞时间的权衡。save规则越频繁，恢复点越接近但IO与fork开销增大。建议根据写入规模设置分层触发条件，例如高写入业务减少频率并配合AOF，低写入业务可采用更密集快照。开启rdbcompression可降低磁盘占用，但在CPU敏感场景需评估压缩成本。大内存实例建议开启rdbsave-incremental-fsync以降低峰值IO，但需结合磁盘性能验证落盘稳定性。

AOF配置重点是fsync策略与重写条件。appendfsync always提供最高安全性但性能开销大，everysec是常用平衡方案，no则依赖操作系统刷盘可能导致更多数据丢失。建议在写入高峰期避免频繁重写，设置合理的auto-aof-rewrite-percentage与auto-aof-rewrite-min-size，确保重写只在文件增长明显时触发。aof-use-rdb-preamble可在重写时以RDB作为前置加速恢复，适合大数据量场景。

以下示例展示一套“RDB+ AOF”兼顾方案，文件路径与关键参数可直接落地。示例中包含命令解释与预期效果。

# /etc/redis/redis.conf
# --- RDB ---
save 900 1          # 15分钟内至少1次写入触发快照
save 300 100        # 5分钟内100次写入触发快照
save 60 10000       # 1分钟内10000次写入触发快照
rdbcompression yes  # 开启RDB压缩，降低磁盘占用
rdbchecksum yes     # 校验和，提升可靠性
rdbsave-incremental-fsync yes

# --- AOF ---
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec       # 性能与安全平衡
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 256mb
aof-use-rdb-preamble yes   # 重写时以RDB作为前置，加快恢复

# 重载配置并验证
redis-cli -h 127.0.0.1 -p 6379 CONFIG REWRITE
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET save
redis-cli -h 127.0.0.1 -p 6379 CONFIG GET appendonly
# 预期效果：配置写回 redis.conf，返回值包含 save 与 appendonly yes

持久化对性能的影响主要来自fork开销、磁盘写入与后台重写。大内存实例在快照或重写期间可能出现短暂停顿，建议通过控制内存峰值、拆分实例或启用主从架构分担持久化压力。磁盘层面优先使用低延迟SSD，并确保AOF与RDB位于独立磁盘或分区以降低竞争。监控aof_current_size、aof_base_size、rdb_last_bgsave_time_sec等指标可及时发现持久化异常。

# 关键监控与解释
redis-cli INFO persistence | egrep "rdb_last_bgsave_status|rdb_last_bgsave_time_sec|aof_current_size|aof_base_size"
# rdb_last_bgsave_status: last bgsave是否成功
# rdb_last_bgsave_time_sec: 最近一次bgsave耗时
# aof_current_size: AOF当前大小
# aof_base_size: 上次重写后的基准大小

排错示例：当AOF重写失败或RDB快照失败时，通常与磁盘空间、权限、fork失败有关。

# 1) 查看日志定位错误
tail -n 200 /var/log/redis/redis-server.log

# 2) 检查磁盘空间与权限
df -h /var/lib/redis
ls -ld /var/lib/redis

# 3) 手动触发重写与快照
redis-cli BGREWRITEAOF   # 手动触发AOF重写
redis-cli BGSAVE         # 手动触发RDB快照
# 预期效果：日志出现 Background append only file rewriting started / DB saved on disk

在数据安全与性能之间，可采用分层策略：主节点以everysec+AOF为主、RDB为辅，保障快速恢复；从节点可仅保留RDB或延迟AOF，以降低写放大并作为备份恢复点。对关键业务可引入定期异地备份与冷存储，保证极端故障下的数据可回溯。总体原则是以业务RPO/RTO为基准，结合硬件与写入特征进行参数调优，并通过压测验证持久化策略对吞吐与延迟的实际影响。

练习：在测试环境对比RDB与AOF策略对写入性能的影响，并输出结果。

# 1) 初始化测试数据
redis-cli FLUSHALL
redis-benchmark -h 127.0.0.1 -p 6379 -t set -n 100000 -d 256

# 2) 切换AOF策略为always（高安全低性能）
redis-cli CONFIG SET appendfsync always
redis-benchmark -h 127.0.0.1 -p 6379 -t set -n 100000 -d 256

# 3) 切回everysec，观察吞吐提升
redis-cli CONFIG SET appendfsync everysec
redis-benchmark -h 127.0.0.1 -p 6379 -t set -n 100000 -d 256

# 4) 记录吞吐差异与延迟变化
# 预期效果：always显著降低吞吐，everysec恢复到可接受水平

以上示例与命令可直接用于持久化策略落地、验证与排错，确保在性能与数据安全之间取得可控平衡。