Redis消息怎么定时持久化保存，设置时间有啥讲究和注意点

Redis为了保证数据安全,提供了两种主要的持久化方式，你可以把它们想象成给数据做备份的两种不同策略，这两种策略不是二选一，而是可以同时开启，互为补充，设置备份的时间点非常有讲究，设置不好可能会导致数据丢失或者影响服务器性能。

第一种方式叫RDB，可以理解为“拍快照”（来源：Redis官方文档对RDB的描述），这种方式是在特定的时间点，把当前内存中完整的数据集生成一个压缩过的二进制文件（默认叫dump.rdb）保存到硬盘上，这个过程就像是给整个数据库拍了一张全景照片。

“拍快照”的时间点怎么设置呢？这其中的讲究最大。 设置是通过Redis的配置文件redis.conf中的save指令来完成的，默认的配置通常是这样的：

save 900 1
save 300 10
save 60 10000

这三行配置的意思是（来源：redis.conf配置文件内的注释说明）：

• save 900 1：在900秒（15分钟）内，如果至少有1个键的值发生了变化，那么就触发一次快照。
• save 300 10：在300秒（5分钟）内，如果至少有10个键发生了变化，那么就触发一次快照。
• save 60 10000：在60秒（1分钟）内，如果至少有10000个键发生了变化，那么就触发一次快照。

这里面的注意点在于如何权衡数据安全性和性能：

1. 追求更高数据安全性：如果你的应用对数据丢失的容忍度很低，比如金融类应用，那么你应该设置更频繁的快照，你可以增加一条 save 30 5 的规则，意思是30秒内有5次写操作就备份，这样即使服务器故障，你最多也只丢失30秒的数据。但要注意，过于频繁地拍快照会带来性能开销，因为生成RDB文件是一个比较耗资源的操作，Redis需要fork出一个子进程来负责写入硬盘，如果数据量很大，fork过程可能会瞬间占用较多CPU和内存，并且频繁的磁盘写入也会带来I/O压力，可能会影响主进程处理正常请求的速度。
2. 追求更高性能：如果你的应用可以容忍丢失几分钟的数据，比如一些缓存场景，丢失了可以从数据库重新加载，那么你可以把快照间隔设长一些，甚至只保留 save 900 1 这一条规则，或者完全关闭RDB持久化，这样可以减少因为持久化带来的性能抖动。
3. 关注数据变化频率：规则里的两个数字（时间和变更键数）要结合你的业务特点，如果你的系统是写操作非常密集的，可能很快就能达到10000次键变更，那么即使你设置了save 60 10000，实际快照频率也会很高，你需要观察实际情况来调整这两个阈值。

第二种方式叫AOF，可以理解为“写日记”（来源：Redis官方文档对AOF的描述），这种方式不像RDB记录数据本身，而是记录每一次会改变数据的写操作命令（比如SET、LPUSH等），服务器启动的时候，重新执行一遍这个“日记”里的所有命令，就能恢复数据。

AOF的定时保存其实指的是“日记”从内存写到硬盘的频率，由配置项appendfsync控制，这里面的讲究同样关乎安全和性能的平衡：

• appendfsync always：最安全，但最慢，每次有写命令都立即同步到硬盘的AOF文件，这样即使服务器断电，也最多只丢失一个命令的数据，但因为每次都要写盘，会严重拖慢Redis的性能，一般不建议使用。
• appendfsync everysec：推荐折中方案，每秒同步一次，这意味着即使服务器故障，最多丢失1秒钟的数据，在数据安全和性能之间取得了很好的平衡，是默认的推荐设置。
• appendfsync no：由操作系统决定，Redis不主动同步，由操作系统自身的缓存刷新机制来决定何时把数据写入硬盘，这种方式性能最好，但一旦系统宕机，可能会丢失很多数据（比如操作系统缓存中积压的很多秒的数据）。

重要的注意点：

1. 混合使用：在实际生产环境中，通常会同时开启RDB和AOF（appendfsync everysec），这样既可以利用RDB做快速的完整备份和灾难恢复（RDB文件加载速度比AOF重放快），又可以利用AOF保证极高的数据安全性，两者优势互补。
2. AOF文件会膨胀：由于AOF记录的是命令，随着时间推移文件会越来越大，Redis提供了AOF重写机制来压缩文件，它会根据当前数据库状态生成一个等效的、命令最简化的新AOF文件，你需要关注重写的触发条件（auto-aof-rewrite-percentage和auto-aof-rewrite-min-size），避免文件过大。
3. 灾难恢复顺序：当Redis重启时，如果同时开启了AOF和RDB，Redis会优先使用AOF文件来恢复数据（来源：Redis持久化工作机制），因为AOF通常能保证更完整的数据。

设置时间的核心讲究就是根据你的业务对数据丢失的容忍度（RPO）和服务器所能承受的性能压力，在“数据安全”和“服务性能”之间找到一个平衡点。 没有放之四海而皆准的最佳配置，需要你深入了解自己的业务需求，并通过监控工具观察Redis的运行状态，进行不断的测试和调整，对于非常重要的系统，定期手动执行BGSAVE命令创建RDB备份，并将备份文件传输到其他物理服务器做容灾，也是非常有必要的安全措施。