Redis 是内存数据库,但是它为数据的持久化提供了两个技术,一个是AOF日志,另一个是RDB快照:
- AOF 文件的内容是操作命令;
- RDB 文件的内容是二进制数据。
RDB 快照就是记录某一个瞬间的内存数据,记录的是实际数据,而 AOF 文件记录的是命令操作的日志,而不是实际的数据。
因此在 Redis 恢复数据时, RDB 恢复数据的效率会比 AOF 高些,因为直接将 RDB 文件读入内存就可以,不需要像 AOF 那样还需要额外执行操作命令的步骤才能恢复数据
快照的使用
Redis 提供了两个命令来生成 RDB 文件,分别是 save
和 bgsave
,他们的区别就在于是否在「主线程」里执行:
- 执行了 save 命令,就会在主线程生成 RDB 文件,由于和 执行操作命令 在同一个线程,所以如果写入 RDB 文件的时间太长,会阻塞主线程;
- 执行了 bgsave 命令,会创建一个子进程来生成 RDB 文件,这样可以避免主线程的阻塞
Redis 可以 通过配置文件的选项来实现每隔一段时间 自动执行一次 bgsave 命令,默认会提供以下配置:
save 900 1 #900 秒之内,对数据库进行了至少 1 次修改;
save 300 10 #300 秒之内,对数据库进行了至少 10 次修改
save 60 10000 #60 秒之内,对数据库进行了至少 10000 次修改
只要满足上面任何一个条件,都会自动 执行一次 bgsave 命令 生成RDB文件
- Redis 的快照是全量快照,也就是说每次执行快照,都是把 内存中的「所有数据」都记录到磁盘中。所以 执行快照是一个比较重的操作。
- 如果 执行频率太频繁,可能会对 Redis 性能产生影响
- 通常 可能设置 至少 5 分钟才保存一次快照,这时如果 Redis 出现宕机等情况,则意味着最多可能丢失 5 分钟数据
因此redis服务器宕机,RDB快照损失的数据比AOF日志损失的数据要多。
执行快照时,数据能被修改吗?
执行 bgsave 过程中,由于是交给子进程来构建 RDB 文件,主线程还是可以继续工作的,关键的技术就在于写时复制技术(Copy-On-Write, COW)。
执行 bgsave 命令的时候,会通过 fork()
创建子进程,此时 子进程 和 父进程 是共享同一片内存数据的,因为创建子进程的时候,会复制父进程的页表,但是页表指向的相同的物理内存
只有在发生修改内存数据的情况时,物理内存才会被复制一份:
如果主线程(父进程)要修改共享数据里的某一块数据(比如键值对 A
)时,就会发生写时复制,于是这块数据的 物理内存就会被复制一份(键值对 A'
),然后主线程在这个数据副本(键值对 A'
)进行修改操作。与此同时,bgsave 子进程可以继续把原来的数据(键值对 A
)写入到 RDB 文件。
但是程刚修改的数据,子线程 是没办法在这一时间写入 RDB 文件的,只能交由下一次的 bgsave 快照。
所以 Redis 在使用 bgsave 快照过程中,如果主线程修改了内存数据,不管是否是共享的内存数据,RDB 快照都无法写入主线程刚修改的数据,因为此时主线程(父进程)的内存数据和子进程的内存数据已经分离了,子进程写入到 RDB 文件的内存数据只能是原本的内存数据
RDB 和 AOF 合体
即使 RDB 比 AOF 的数据恢复速度快,但是快照的频率不好把握:
- 如果频率太低,两次快照间一旦服务器发生宕机,就可能会比较多的数据丢失;
- 如果频率太高,频繁写入磁盘和创建子进程会带来额外的性能开销。
混合使用 AOF 日志和内存快照
它的作用是 既有 AOF 丢失数据少 和 又有 RDB 恢复速度快 的优点;
如果想要开启混合持久化功能,可以在 Redis 配置文件 将下面这个配置项设置成 yes:
aof-use-rdb-preamble yes
当开启了混合持久化后,在 AOF 重写日志时:
fork
出来的重写子进程会先将与主线程共享的 内存数据 以 RDB 方式写入到 AOF 文件。- 同时, 主线程处理的操作命令会被记录在重写缓冲区里,重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件
- 写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。
总结:AOF 文件的前半部分是 RDB 格式的全量数据,后半部分是 AOF 格式的增量数据。