目的：
我正在尝试每X次备份dump.rdb，每Y次备份appendonly.aof，这样，如果文件因任何原因损坏(甚至只是aof的appendonly.aof文件(，我可以从dump.rdb备份快照中恢复我的数据，然后用我拥有的appendonly.aof.backup的最新副本恢复此后发生的任何其他更改。
情况：
我每5分钟备份一次dump.rdb，每1秒只备份一次append.aof。
问题：
1( 由于dump.rdb是由子进程在后台写入临时文件的，那么在子进程创建新映像时发生的关键更改会发生什么？我知道无论后台写入如何，AOF文件都会继续追加，但新的dump.rdb文件也包含关键更改吗？
2( 如果dump.rdb不包含关键更改，是否有某种方法可以确定子进程被分叉的确切位置？这样，我就可以跟踪AOF文件拥有最新信息的时间点。
谢谢！
通常，人们使用RDB或AOF作为持久性策略。同时拥有这两个是相当昂贵的。每5分钟运行一次转储，每秒复制一次aof文件，听起来非常频繁。除非Redis实例只存储少量数据，否则很可能会杀死盒子的I/O子系统。
现在，关于您的问题：
1(RDB机制的语义
转储机制利用现代操作系统内核在克隆/分叉处理时实现的写时复制机制。当fork完成时，系统只是通过复制页面表来创建后台进程。页面本身在两个进程之间共享。如果Redis进程对页面进行写操作，操作系统将透明地复制页面(这样Redis实例就有了自己的版本，后台处理以前的版本(。因此，后台处理可以保证存储器结构保持不变(因此保持一致(。
其结果是，在fork之后启动的任何写入操作都不会在转储中执行。转储是在分叉时间拍摄的一致快照。
2(跟踪分叉点
您可以通过运行INFO persistence命令并计算rdb_lastrongave_time-rdb_list_bgsave_time_sec来估计fork时间戳，但它不是很准确(仅次(。
为了更准确(毫秒(，您可以解析Redis日志文件以提取以下行：
[3813] 11 Apr 10:59:23.132 * Background saving started by pid 3816
您至少需要"通知"日志级别才能看到这些行。
据我所知，没有办法将AOF中的特定条目与RDB的分叉操作关联起来(即，不可能100%准确(。