redis-持久化

目录

• 一、RDB
  • 1.1 触发机制
  • 1.2 流程说明
  • 1.3 RDB优缺点
• 二、AOF
  • 2.1 开启AOF
  • 2.2 AOF流程
• 三、重启加载流程

持久化即备份，这是单机高可用的策略之一，有了备份，就可以在Redis故障通过备份进行恢复。redis持久化主要有RDB和AOF。

1. RDB

   RDB（Redis DataBase），基于策略定时将redis内存中的数据保存到硬盘。需要时可以通过这个备份文件进行恢复。

2. AOF

   AOF（Append Only File），是把每次redis执行的命令记录到日志文件中（类似于MySql的Bin log），当Redis启动时可以通过执行log中的命令来恢复数据

一、RDB

1.1 触发机制

save命令：阻塞当前redis服务器，直到RDB过程完成，服务器在阻塞期间不能处理如何客户端请求，原则上save命令已经废弃。

bgsave命令：会fork一个子进程，RDB的持久化由这个子进程来完成，阻塞只发生在fork阶段，耗时较短，子进程执行rdb期间redis服务器不会阻塞，正常处理客户端请求。

自动触发机制：在redis.conf 配置：

save m n

代表如果在m秒内存在n次的修改时，则执行bgsave命令

1.2 流程说明

1. 执行bgsave命令，redis父进程判断如果当前存在正在执行的子进程，则直接返回，比如AOF或者RDB子进程。
2. 父进程fork一个子进程，fork过程父进程是阻塞，无法响应客户端请求
3. fork结束后，bgsave返回“background saving started”信息，并且不再阻塞父进程，父进程可以继续响应客户端请求。
4. 子进程根据父进程的内存快照创建RDB文件，完成后对原有文件进行原子替换。
5. 子进程发送信号给父进程表示RDB完成

1.3 RDB优缺点

优点

1. RDB是一个压缩的二进制文件，代表Redis在某个时间点上的数据快照，适合备份，全量复制等场景
2. Redis加载RDB恢复数据远远快于AOF

缺点

1. RDB无法做到实时持久化
2. 兼容性问题，新版本的redis可能无法兼容老版本的RDB

为了解决实时持久化问题，redis引入了AOF。

二、AOF

2.1 开启AOF

AOF默认是关闭的，通过如下命令开启：

appendonly yes

2.2 AOF流程

AOF工作基本流程：

1. 命令写入（append）：redis所有的写入命令会追加到aof_buf（缓冲区）中
2. 文件同步（sync）：AOF缓冲区根据对应的策略向硬盘做同步操作
3. 文件重写（rewrite）：随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的
4. 重启加载（load）：redis启动后可以加载AOF文件进行数据恢复。

命令写入

对于每一条redis写入命令，在AOF中会追加一条文本，文本格式是redis文本协议格式（RESP），直接采用协议格式，以来兼容性和可读性高，二来避免了二次处理的开销。

如果直接把命令写入硬盘会影响到redis的性能。先写入aof_buf，然后后期通过同步策略写入硬盘，避免直接的IO影响到redis的性能。

文件同步

redis提供了多种AOF缓冲区文件同步策略，同步策略分别使用了操作系统的wirte函数和fsync函数，说明如下：

write: 会触发延迟写（delayed write）操作，为了性能，linux在内核提供了页缓冲区用来提高硬盘的IO性能，write操作在写入系统缓冲区后直接返回，后期同步硬盘操作依赖于操作系统调度（比如按时，或者缓冲区慢等）。如果在同步前出现系统宕机故障，缓冲区的数据会丢失。

fsync: 强制操作系统将缓冲区的操作同步到硬盘。

由appendfsync参数控制：

可配置的值	说明
always	命令写入buf后调用系统调用fsync同步AOF文件，fsync完成后线程返回
no	命令写入buf后调用系统调用write操作，后续fsync同步操作由操作系统来完成，一般为30秒一次。
everysec	命令写入buf后调用系统调用write操作，后续fsync同步操作专门线程每一秒调用一次。

everysec是always和no的折中，是性能和安全性的这种，是redis默认的配置，也是比较推荐的配置。

文件重写

文件重写就是把Redis进程里面的最新数据转化为写命令然后同步到aof文件的过程，通过重写不但可以减小aof文件的体积，从而进一步提高aof文件在恢复过程中的加载速度。

由以下原因可以通过aof重写减少aof文件的体积：

1. 旧的apf包含过期的数据不再写入aof，比如 set k1 aaa，这条命令已经过期，但是已经在aof文件中存在，通过重写这条命令将移除aof文件。
2. 旧的aof中存在无效的命令，比如set k1 111,set k1 222，aof中存在两条命令，其实第一条已经失效，通过重写，可以变成一条。
3. 多条命令命令合并。

触发机制：

1. 手动触发：执行bgrewriteaof命令

2. 自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机：

   • auto-aof-rewrite-min-size：表示运行aof重写时文件的最小体积，默认为64MB

   • auto-aof-rewrite-percentage：表示当前aof文件的size（aof_current_size）和上一次重写后aof文件的size(aof_base_size)的比值。

     只有当以上两个条件同时满足时，才会触发自动aof

aof重写流程：

1. 执行aof重写请求
2. 父进程fork一个子进程，开销等同于bgsave时候fork的过程
3. aof缓冲区写入
   1. fork结束后，主进程继续响应客户端请求，所有修改命令都会写入aof_buf，后续基于appendfsync策略写入硬盘
   2. 由于fork操作运用写时复制技术，子进程只能共享fork操作时的的内存数据。在执行bgrewrite期间，主进程依然在响应命令，redis用aof_rewrite_buf来保存这部分数据，防止在新的aof文件生成期间丢失这部分数据。
4. 写入新的AOF，子进程基于fork后的aof_buf（快照）生成新的aof文件
5. 后续操作
   1. 子进程发送信号通知父进程aof生成完成，父进程更新相关统计信息
   2. 父进程把aof_rewrite_buf的数据写入到新的aof文件
   3. 使用最新的aof文件替换老文件，完成最终的AOF重写。

三、重启加载流程

1. 优先加载AOF
2. AOF关闭时加载RDB
3. 加载成功后redis才能成功启动
4. 加载失败，则redis启动失败