Redis日志篇：快速恢复的绝招

“

65 哥：AOF 重写也有一个重写日志，为什么它不共享使用 AOF 本身的日志呢？

”

这个问题问得好，有以下两个原因：

1. 一个原因是父子进程写同一个文件必然会产生竞争问题，控制竞争就意味着会影响父进程的性能。

2. 如果 AOF 重写过程中失败了，那么原本的 AOF 文件相当于被污染了，无法做恢复使用。所以 Redis AOF 重写一个新文件，重写失败的话，直接删除这个文件就好了，不会对原先的 AOF 文件产生影响。等重写完成之后，直接替换旧文件即可。

Redis 4.0 混合日志模型

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。

于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

所以 RDB 内存快照以稍微慢一点的频率执行，在两次 RDB 快照期间使用 AOF 日志记录期间发生的所有「写」操作。

这样快照就不用频繁的执行，同时由于 AOF 只需要记录两次快照之间发生的「写」指令，不需要记录所有的操作，避免出现文件过大的情况。

总结

Redis 设计了 bgsave 和写时复制，尽可能避免执行快照期间对读写指令的影响，频繁快照会给磁盘带来压力以及 fork 阻塞主线程。

Redis 设计了两大杀手锏实现了宕机快速恢复，数据不丢失。

避免日志过大，提供了 AOF 重写机制，根据数据库的数据最新状态，生成数据的写操作作为新日志，并且通过后台完成不阻塞主线程。

综合 AOF 和 RDB 在 Redis 4.0 提供了新的持久化策略，混合日志模型。在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

最后，关于 AOF 和 RDB 的选择问题，「码 哥 字 节」有三点建议：

• 数据不能丢失时，内存快照和 AOF 的混合使用是一个很好的选择；

• 如果允许分钟级别的数据丢失，可以只使用 RDB；

• 如果只用 AOF，优先使用 everysec 的配置选项，因为它在可靠性和性能之间取了一个平衡。

经过两篇 Redis 系列文章，读者朋友们对 Redis 应该有一个全局认识。

以上就是Redis日志篇：快速恢复的绝招的详细内容，更多请关注其它相关文章！