持久化之RDB快照

RDB 快照

RDB快照和aof持节化文件内容差别

• AOF 文件的内容是操作命令；
• RDB 文件的内容是二进制数据。

在redis中RDB快照如何用

save ： 就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
bgsave：创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；

save 900 1
save 300 10
save 60 10000

这里save一般指的式bgsave，意思指的是

• 900 秒之内，对数据库进行了至少 1 次修改；
• 300 秒之内，对数据库进行了至少 10 次修改；
• 60 秒之内，对数据库进行了至少 10000 次修改。
  只要满足以上三条中的一个条件就和触发快照持久化，快照指的是全量持久化，指的式每一次持久化就会把redis中的所有数据都持久化一遍。所以快照是一个非常繁重的任务，如果触发快照太过频繁，就会导致redis的限制性效率降低，如果触发快照频率过低导致容易丢失数据。

在执行快照时，在主进程中数据能否被修改?

答案时可以的，这里用到的技术依然是写时复制技术
果主线程要修改共享数据里的某一块数据（比如键值对 A）时，就会发生写时复制，于是这块数据的物理内存就会被复制一份（键值对 A’），然后主线程在这个数据副本（键值对 A’）进行修改操作。与此同时，bgsave 子进程可以继续把原来的数据（键值对 A）写入到 RDB 文件。

那么极端情况下，如果所有的共享内存都被修改，则此时的内存占用是原先的 2 倍。

AOF与RDB的结合体

尽管 RDB 比 AOF 的数据恢复速度快，但是快照的频率不好把握：

• 如果频率太低，两次快照间一旦服务器发生宕机，就可能会比较多的数据丢失；
• 如果频率太高，频繁写入磁盘和创建子进程会带来额外的性能开销。

这个时候进引入了混合持久化，该方法是混合使用AOF日志和内存快照。

开启设置：aof-use-rdb-preamble yes

混合持久化的过程

当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。

这样的好处在于，重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。

加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失。