时间：2021-07-01 10:21:17 帮助过：34人阅读
然后对于我们需要讨论的一点就是，以什么频率来进行rdb快照，如果频率过高的话，那么对于redis来说，每次创建子进程的过程会阻塞主线程，所以频率过高的话，也会影响redis性能。同时大量的写磁盘操作，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。
在redis 4.0之后采用了aof与rdb互相使用的方式，即在第一次时使用rdb进行全量恢复，之后到下一次进行全量快照的时间，在这段期间内，对于数据库的修改，采用aof日志的形式，记录对于数据库的操作，所以如果服务器宕机，因为aof日志记录了之前的操作，虽然没有来得及更新rdb文件，但是恢复数据库时，可以结合上一次的rdb快照和aof日志进行完整恢复。所以rdb与aof的结合使用可以不用频繁进行rdb操作，同时如果服务器在下一次rdb之前宕掉了，也会通过上一次rdb与aof日志的结合进行恢复
关于 AOF 和 RDB 的选择问题，：数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；
如果允许分钟级别的数据丢失，可以只使用 RDB（因为每次rdb之间有是时间设定）；
如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。
在这里还有一点需要介绍，用户可以主动设置save参数来决定bgsave，例如save 900 1 save 300 10 服务器在900秒内，对数据库至少进行1次修改，在300秒内，对数据库至少进行10次修改，两个条件任意满足一个，服务器都会执行bgsave命令。
rdb文件在磁盘上是经过压缩的
redis之RDB快照 1.0
标签：过程 之间 pairs 技术 记录 时间 压缩 标识 对比