一、Redis持久化那些事儿
Redis这个内存数据库速度快是快，但数据安全也是个绕不开的话题。就像你把贵重物品放在家里，总得考虑装个保险柜吧？Redis的持久化就是它的"保险柜"，主要有两种方式：RDB和AOF。
先说说RDB，它就像给数据库拍快照。你可以设置每隔多久拍一次，比如5分钟内有100次写操作就触发。配置起来特别简单：
# redis.conf RDB配置示例
save 900 1 # 15分钟内至少有1个key被修改
save 300 10 # 5分钟内至少有10个key被修改
save 60 10000 # 1分钟内至少有10000个key被修改
dbfilename dump.rdb # 快照文件名
dir /var/lib/redis # 存储目录
这种方式的优点是恢复速度快，文件体积小。但缺点也很明显 - 如果服务器突然宕机，最近几分钟的数据可能就没了。
二、AOF持久化的精妙之处
AOF(Append Only File)就像记日记，把每个写操作都记录下来。Redis提供了三种同步策略：
# redis.conf AOF配置示例
appendonly yes # 开启AOF
appendfilename "appendonly.aof" # 文件名
appendfsync everysec # 同步策略：每秒同步
# appendfsync always # 每次写都同步，最安全但性能差
# appendfsync no # 由操作系统决定，性能最好但最不安全
auto-aof-rewrite-percentage 100 # 当前AOF文件比上次重写后体积增加100%时触发重写
auto-aof-rewrite-min-size 64mb # AOF文件至少64MB才会触发重写
AOF的优点是数据安全性高，你可以精确到秒级恢复。缺点是文件体积会不断增大，不过Redis很聪明，会定期重写AOF文件，去掉冗余命令。
三、混合持久化的最佳实践
聪明的你可能已经想到了 - 为什么不把RDB和AOF结合起来用呢？这就是Redis 4.0引入的混合持久化：
# redis.conf 混合持久化配置
aof-use-rdb-preamble yes # 开启混合模式
这种模式下，AOF文件前半部分是RDB格式的快照，后半部分是AOF格式的增量命令。既保证了恢复速度，又能最大限度减少数据丢失。
四、性能调优实战指南
持久化虽好，但配置不当会影响性能。下面分享几个实战经验：
- RDB调优：
stop-writes-on-bgsave-error yes # 后台保存出错时停止写入
rdbcompression yes # 压缩RDB文件
rdbchecksum yes # 校验RDB文件
- AOF调优：
no-appendfsync-on-rewrite yes # 重写期间不进行fsync操作
aof-load-truncated yes # 加载被截断的AOF文件
- 系统层面优化：
# 调整Linux内核参数
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
echo 'net.core.somaxconn = 1024' >> /etc/sysctl.conf
sysctl -p
五、应用场景与选型建议
不同业务场景需要不同的持久化策略：
缓存场景：可以只用RDB，甚至完全禁用持久化。数据丢了重新加载就是，毕竟缓存不是唯一数据源。
会话存储：建议AOF+每秒同步。用户会话数据比较重要，但又不至于需要每次写入都同步。
金融交易：必须AOF+always同步。每一笔交易都不能丢，性能差点也得认。
六、避坑指南
磁盘IO瓶颈：持久化很吃IO，建议用SSD。如果服务器负载很高，考虑适当放宽同步策略。
内存不足：bgsave时会fork子进程，如果内存太大，fork可能阻塞。可以设置
repl-backlog-size。监控报警：一定要监控持久化状态：
redis-cli info persistence # 查看持久化状态
七、总结与展望
Redis持久化就像给快车装刹车，既要保证安全，又不能影响速度。经过多年发展，Redis的持久化机制已经相当成熟：
- RDB适合做定期备份
- AOF适合保证数据安全
- 混合模式是当前最佳实践
未来随着硬件发展，特别是持久内存(PMEM)的普及，Redis持久化可能会有更大突破。但无论如何，理解这些基本原理，才能在各种场景下做出最佳选择。
评论