Redis——持久化策略

Redis持久化

Redis的读写操作都是在内存上，所以Redis性能高。 但是当重启的时候，或者因为特殊情况导致Redis崩了，就可能导致数据的丢失。 所以Redis采取了持久化的机制，重启的时候利用之间持久化的文件实现数据的恢复。

Redis提供了三种持久化的机制：

• RDB：将某一段时间的内存数据，以二进制的方式写到磁盘中
• AOF：每次执行写操作，都将命令以追加的方式写到文件中
• 混合持久化方式：结合了RDB和AOF的优势

RDB机制

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。 ps： 执行快照是一种比较重的操作，如果频率太低，那么当服务器崩了，那么丢失的数据就多，如果频率高，那么就会对性能造成影响。

手动触发

手动触发分别对应save和bgsave命令：

• save命令：阻塞当前Redis服务器，直到RDB过程完毕为止，对于内存比较大的实例会造成长时间的阻塞。（这很不推荐）
• bgsave：Redis过程执行fork之后，会创建子进程，RDB的持久化工作就是让子进程负载，完成后自动结束。

自动触发机制

• 使用save配置。 如“save m n” 表示m秒内数据发送了n次修改，自动RDB持久化
• 从节点进行全量复制操作的时候，主节点自动进行RDB持久化，随后将文件内容发送给从节点
• 执行shutdown命令关闭Redis时，执行RDB持久化

下图是bgsave命令的过程：

1. 执行bgsave的时候，Redis父进程判断当前进程是否存在其他进程的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回
2. 如果不存在，父进程创建子进程，fork过程中父进程阻塞，可以通过info stat命令查看latest_fork_user选项，可以获取最近一次fork操作的耗时（单位是毫秒）
3. 父进程fork完毕后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令
4. 子进程会创建RDB文件，根据父进程内存生成一个临时快照文件，完成后对原有的文件进行替换。
5. 最后，子进程发送信号给父进程，父进程更新统计结果

Redis默认的配置文件中提供了bgsave的方式

save 900 1
save 300 10
save 60 10000

• 900s之内，对数据进行一次修改
• 300s之内，对数据进行10次修改
• 60s之内，对数据进行1000修改

如果触发了上面的条件，那么就会触发RDB机制。

RDB文件的处理

保存：RDB⽂件保存在dir配置指定的⽬录（默认/var/lib/redis/）下，⽂件名通过dbfilename配置（默认dump.rdb）指定。可以通过执⾏config set dir {newDir} 和 config set dbfilename {newFilename}运⾏期间动态执⾏，当下次运⾏时RDB⽂件会保存到新⽬录。

RDB的优缺点

• RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间上的数据快照。 使用于备份，全量复制等场景。
• Redis加载RDB文件恢复数据远远快于AOF文件，因为RDB文件是以二进制存储的。
• RDB方式数据没办法做到实时持久化/秒级持久。 因为bgsave每次运行都要执行fork创建子进程，属于重量操作，频繁操作成本高。

AOF机制

AOF持久化：以独立日志的方式记录每次写操作，重启的时候执行AOF文件中的命令达到恢复数据的目的。

可以在配置文件中开启appendonly yes选项，默认是不开启。
下图是AOF的工作流程

1. 将所有的写入操作追加到aof_buf缓冲区中
2. AOF缓冲区根据对应的策略向硬盘做同步操作
3. 随着AOF文件越来越大，需要定期的AOF文件进行重写，达到压缩的目的
4. 当Redis启动的时候，可以加载AOF文件进行数据的恢复

AOF命令写入的内容是以文本协议格式。 例如set hello world 这条命令，在AOF缓冲区追加如下文本所示

*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n

AOF是选择文本协议来进行存储的，Redis以这种方式存储有可能的原因如下：

• 文本协议有较好的兼容性
• 实现简单，可读性好

看了AOF的工作流程后，想一想为什么AOF需要aof_buf这个缓冲区呢？ Redis使用单线程响应命令，如果每次写AOF文件都直接同步到硬盘上，性能从内存到IO读写，性能会下降。 所以先将数据写入到aof_buf中，会有效降低IO的次数，同时Redis提供了3种缓冲区的同步策略。
如下图所示：

文件同步：

Redis提供了3种AOF缓冲区同步文件策略。由参数appendfsync控制

系统调用write和fsync：

• write操作会触发延迟写机制。Linux在内核中提供了页缓冲区来提供硬盘IO性能。write在写入系统缓冲区后立即返回。同步硬盘操作依赖于系统调度机制。
• fsync是对单个文件进行操作，做强制硬盘同步，fsync将阻塞直到数据写入到硬盘上。

当Redis同步策略为always时，每次写都要同步AOF文件，性能很差。
配置为no的时候，同步策略不可控，虽然提高了性能，但数据丢失的可能性增大了
当配置为everysec的时候，是默认配置，兼顾了数据安全和性能。

所以不同的策略，如果发送数据丢失，数据丢失的程度是不一样的，如果是always，那么每次都会进行同步操作，数据不会丢失，但是如果设置为no，那么数据丢失就可能很多，而everysec，数据只会丢失1s内的数据。

AOF重写机制

随着命令不断地写入到AOF文件中，文件会越来越大，为了解决这个问题，Redis引入了重写机制来解决。

什么是重写机制

Redis会将旧的命令删除掉，只会保留数据的最新版本。 并且多条写操作会合并成一条。

而较小的AOF文件一方面降低了硬盘的空间，一方面可以提高启动Redis恢复数据的速度。

AOF重写过程也分为手动触发和自动触发

• 手动触发：调用bgrewriteof命令
• 自动触发：根据auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定自动触发时机。

auto-aof-rewrite-min-size： 表示触发时AOF的最小文件大小，默认是64MB
auto-aof-rewrite-percentage：代表当前AOF占用大小相比较上次重写时增加的比例

AOF重写的流程图如下：

1. 执行AOF重写请求
   如果当前进程正在执行AOF重写，请求不执行。如果当前进程正在执行bgsave操作，重写命令延迟到bgsave操作完毕后执行
2. 父进程执行fork，创建子进程
3. 重写
   a.主进程fork之后，继续响应其他命令。所有的修改写入到AOF的缓冲区中并根据appendfsync策略同步到硬盘，保证旧的AOF文件机制正确
   b. 子进程只有fork之前的所有内存信息。父进程需要将fork之后的这段时间的写操作写入到AOF重写缓冲区中
4. 子进程根据内存快照，将命令合并到新的AOF文件
5. 完成子进程重写，新文件写入后，子进程发送信号给父进程。父进程将AOF重写缓冲区的数据追加到新的AOF文件中。 最后将新的AOF文件替换旧的AOF文件

所以Redis持久化的机制为下图所示

为什么会有混合持久化

RDB的优势就是恢复速度快，因为是以二进制存储的，但是快拍的频率不好把握。频率太低，丢失的数据量就多，频率太多，就会导致性能降低

AOF的优点：丢失的数据少，但是恢复的速度不快。

所以结合了RDB和AOF的优点，Redis4.0推出了混合持久化的机制，保证了Redis的重启速度，又降低了数据丢失的风险。 混合持久化最大的差别就是AOF文件不再是以文本来存储的了，而是以二进制的方式来存储。这就导致了恢复数据的时候，速度会比AOF快。