Redis 持久化策略

Redis 持久化策略

RDB

RDB是redis默认的持久化方式，按照一定的时间间隔将内存的数据以快照的形式保存到硬盘，每次都是从 Redis 中生成一个快照进行数据的全量备份。RDB文件是经过压缩的二进制文件，恢复时是将快照读取到内存中。

**备份过程：**RDB 机制是通过把某个时刻的所有数据生成一个快照来保存，其存在三种触发机制，分别是 save、 bgsave 和自动化，以实现这个过程。

• save：该命令会阻塞当前 Redis 服务器，执行 save 命令期间，Redis 不能处理其他命令，直到 RDB 过程完成为止，因而有可能会造成长时间阻塞，线上环境不建议使用。

• bgsave：执行该命令时，Redis 会在后台异步进行快照操作，与此同时还可以响应客户端请求。(background save)

  • Redis 父进程首先判断：当前是否在执行 save，或 bgsave/bgrewriteaof 的子进程，如果在执行则 bgsave 命令直接返回。bgsave/bgrewriteaof 的子进程不能同时执行，主要是基于性能方面的考虑：两个并发的子进程同时执行大量的磁盘写操作，可能引起严重的性能问题。
  • 父进程执行 fork 操作创建子进程，这个过程中父进程是阻塞的，Redis 不能执行来自客户端的任何命令。父进程 fork 后，bgsave 命令返回”Background saving started”信息并不再阻塞父进程，并可以响应其他命令。
  • 子进程进程对内存数据生成快照文件。
  • 父进程在此期间接收的新的写操作，使用 COW 机制写入。
  • 子进程完成快照写入，替换旧 RDB 文件，随后子进程退出。

  【COW写时复制】

  • 当主进程执行读操作时，访问共享内存；
  • 当主进程执行写操作时，则会拷贝一份数据，执行写操作。

• 自动触发：自动触发（即让服务器每隔一段时间自动执行一次 bgsave 命令）是由我们的配置文件来完成的。

  save m n：m秒内数据发生n次修改，自动触发bgsave

优点：

• RB 是一个紧凑压缩的二进制文件，存储效率较高。

• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

• 适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）

缺点：

• 容易丢失两次快照之间 Redis 服务器中变化的数据。
• RDB 通过 fork 子进程对内存快照进行全量备份，是一个重量级操作，频繁执行成本高。

AOF

AOF是把所有对内存进行修改的指令（写操作）以独立日志文件的方式进行记录，重启时通过执行 AOF 文件中的 Redis 命令来恢复数据。

备份过程：

1. 客户端的请求写命令会被append追加到AOF缓冲区内；

2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；

3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；

4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

AOF重写机制：

AOF的文件会越来越大，当AOF达到一定程度大小之后再通过AOF文件恢复数据是异常缓慢的，那么对于这种情况Redis在开启AOF持久化机制的时候会存在AOF文件的重写。

AOF 重写是 AOF 持久化的一个机制，用来压缩 AOF 文件，通过 fork 一个子进程，重新写一个新的 AOF 文件，该次重写不是读取旧的 AOF 文件进行复制，而是读取内存中的Redis数据库，重写一份 AOF 文件，有点类似于 RDB 的快照方式。

AOF重写过程：

1. bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。

2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞。

3. 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。

4. • 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
   • 主进程会将重写缓冲区aof_rewrite_buf中的所有内容写到新 AOF 文件的末尾，使得新的 AOF文件保存的数据库状态与现有的数据库状态一致。

5. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

文件重写之所以能够压缩 AOF文件原因：

• 过期的数据不再写入文件
• 无效的命令不再写入文件
• 多条命令可以合并为一个：如 sadd myset v1, sadd myset v2, sadd myset v3 可以合并为 sadd myset v1 v2 v3。

优点：

• 数据的备份更加完整，丢失数据的概率更低，适合对数据完整性要求高的场景

• AOF 日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。

• 日志文件可读，AOF 可操作性更强，可通过操作日志文件进行修复

缺点：

• 对于同一份数据来说，AOF 日志文件通常比 RDB 数据快照文件更大。

• 恢复备份速度比较慢

• 同步写操作频繁会带来性能压力

Redis 为什么考虑使用 AOF 而不是 WAL 呢?

• Redis 使用AOF写后日志这种形式，可以避免出现记录错误命令的情况。

• AOF 是在命令执行后才记录日志，所以不会阻塞当前的写操作。

字节技术-Redis 持久化策略浅析