RDB 持久化

RDB持久化是把当前进程生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或等于内存中的值。

bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

具体流程如下：

• redis客户端执行bgsave命令或者自动触发bgsave命令；
• 主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；如果不存在正在执行的子进程，那么就fork一个新的子进程进行持久化数据，fork过程是阻塞的，fork操作完成后主进程即可执行其他操作；
• 子进程先将数据写入到临时的rdb文件中，待快照数据写入完成后再原子替换旧的rdb文件；
• 同时发送信号给主进程，通知主进程rdb持久化完成，主进程更新相关的统计信息（info Persitence下的rdb_*相关选项）

在以下4种情况会自动触发bgsave 命令：

• redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；
• 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；
• 执行debug reload命令重新加载redis时也会触发bgsave操作；
• 默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作。

如果频繁地进行全量快照，会带来两方面的开销：

• 一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。
• 另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了。

RDB优缺点优点

• RDB文件是某个时间节点的快照，默认使用LZF算法进行压缩，压缩后的文件体积远远小于内存大小，适用于备份、全量复制等场景；
• Redis加载RDB文件恢复数据要远远快于AOF方式；缺点RDB方式实时性不够，无法做到秒级的持久化；
• 每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本较高；
• RDB文件是二进制的，没有可读性，AOF文件在了解其结构的情况下可以手动修改或者补全。

AOF 持久化

Redis 先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令以文本形式保存。而AOF日志采用的是先写内存，后写日志。

如何实现AOF

AOF日志记录Redis的每个写命令，步骤分为：命令追加，文件写入，文件同步。 命令追加 当AOF持久化功能打开了，服务器在执行完一个写入命令后，会以协议格式将被执行的写命令追加到服务器的aof_buf缓冲区。 文件写入和同步 关于何时将aof_buf缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：

• Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
• Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
• No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。