如果Redis中的数据量很大，RDB比AOF更可取吗？

Question

我正在运行一个Redis实例，其最大内存和使用量约为25GB。它在Kubernetes中作为状态集运行。因为redis吊舱可以被调度到任何盒子，并且可以在任何时候通过RDB进行AOF备份时重新启动。

但是，昨天redis吊舱重新启动，加载数据花了大约5分钟，这让我想到，如果数据很大，RDB备份是否更适合？

• 我知道，AOF文件大小可以超过，并自动重写以优化。
• 但是即使在100%优化的状态下，如果数据库必须重新启动，IMO也需要整个时间来调用所有命令，这些命令将把数据填满回25GB，这将是耗时的。（大约5分钟，我监控了）
• 我想减少这个时间并考虑返回RDB快照，虽然数据会丢失，但这是快速启动时间的权衡。将安排更短的BGSAVE时间，以避免或减少数据丢失。

我想知道，如果数据量很大，并且您希望避免启动时间较慢，是否最好使用RDB备份？如果每隔5或10分钟运行一次BGSAVE，那么数据大小是否很大（大于15GB）是一种好做法？

（此外，大数据量可能不够大，其他人可能无法使用，但这与启动时间有关，我担心，以及由此带来的停机时间）

Answer 1

我是OP。

不是答案，但我想分享一些实验后收集的数据

>

我用16.5GB的数据填充Redis DB，使用以下命令调试填充165000000 PHPREDIS_会话

然后我在-BGREWRITEAOF的帮助下重写/优化AOF文件，整个操作耗时209秒：
aof_last_rewrite_time_sec：209

就在重写之后，我重新启动了Redis实例，用了3分钟将整个数据恢复到16.5Gb的Redis内存中

在此之后，我关闭了AOF并启用了RDB备份，并调用BGSAVE开始备份。它花了202秒才完成：rdb\u last\u bgsave\u time\u sec:202

在RDB备份之后，我再次重新启动了Redis实例，整个数据集在Redis内存中恢复大约需要3分钟，与AOF差不多。

看起来RDB和100%优化的AOF文件将或多或少地花费相同的时间来恢复数据。

如果不优化或重写AOF，可能需要更多的时间，因为Redis将运行更多的命令来恢复数据。

我还测试了具有25GB数据的Redis实例的启动时间，并且启用了AOF，恢复数据需要4m30。

注：上述数据仅通过一次迭代获得，vanilla Redis没有任何调整。这些数字可能与其他情况或配置不匹配。我只是想分享我的发现。