Redis 持久化

1、AOF 持久化

• AOF - 将每条写命令追加至 aof 文件，当重启时会执行 aof 文件中每条命令来重建内存数据

• AOF 日志是写后日志，即先执行命令，再记录日志

  • Redis 为了性能，向 aof 记录日志时没有对命令进行语法检查，如果要先记录日志，那么日志里就会记录语法错误的命令

• 记录 AOF 日志时，有三种同步策略

  • Always 同步写，日志写入磁盘再返回，可以做到基本不丢数据，性能不高

    • 为什么说基本不丢呢，因为 aof 是在 serverCron 事件循环中执行 aof 写入的，并且这次写入的是上一次循环暂存在 aof 缓冲中的数据，因此最多还是可能丢失一个循环的数据

  • Everysec 每秒写，日志写入 AOF 文件的内存缓冲区，每隔一秒将内存缓冲区数据刷入磁盘，最多丢一秒的数据

  • No 操作系统写，日志写入AOF 文件的内存缓冲区，由操作系统决定何时将数据刷入磁盘

1.1、AOF 重写

• AOF 文件太大引起的问题

  1. 文件大小受操作系统限制

  2. 文件太大，写入效率变低

  3. 文件太大，恢复时非常慢

• 重写就是对同一个 key 的多次操作进行瘦身

  1. 例如一个 key 我改了 100 遍，aof 里记录了100 条修改日志，但实际上只有最后一次有效

  2. 重写无需操作现有 aof 日志，只需要根据当前内存数据的状态，生成相应的命令，记入一个新的日志文件即可

  3. 重写过程是由另一个后台子进程完成的，不会阻塞主进程

1.2、AOF 重写过程

1. 创建子进程时会根据主进程生成内存快照，只需要对子进程的内存进行遍历，把每个 key 对应的命令写入新的日志文件（即重写日志）

2. 此时如果有新的命令执行，修改的是主进程内存，不会影响子进程内存，并且新命令会记录到 重写缓冲区

3. 等子进程所有的 key 处理完毕，再将 重写缓冲区 记录的增量指令写入重写日志

4. 在此期间旧的 AOF 日志仍然在工作，待到重写完毕，用重写日志替换掉旧的 AOF 日志

 

2、RDB 持久化

• RDB - 是把整个内存数据以二进制方式写入磁盘

  • 对应数据文件为 dump.rdb

  • 好处是恢复速度快

• 相关命令有两个

  • save - 在主进程执行，会阻塞其它命令

  • bgsave - 创建子进程执行，避免阻塞，是默认方式

    • 子进程不会阻塞主进程，但创建子进程的期间，仍会阻塞，内存越大，阻塞时间越长

    • bgsave 也是利用了快照机制，执行 RDB 持久化期间如果有新数据写入，新的数据修改发生在主进程，子进程向 RDB 文件中写入还是旧的数据，这样新的修改不会影响到 RDB 操作

    • 但这些新数据不会补充至 RDB 文件

• 缺点： 可以通过调整 redis.conf 中的 save 参数来控制 rdb 的执行周期，但这个周期不好把握

  • 频繁执行的话，会影响性能

  • 偶尔执行的话，如果宕机又容易丢失较多数据

 

3、混合持久化

• 从 4.0 开始，Redis 支持混合持久化，即使用 RDB 作为全量备份，两次 RDB 之间使用 AOF 作为增量备份

  • 配置项 aof-use-rdb-preamble 用来控制是否启用混合持久化，默认值 no

  • 持久化时将数据都存入 AOF 日志，日志前半部分为二进制的 RDB 格式，后半部分是 AOF 命令日志

  • 下一次 RDB 时，会覆盖之前的日志文件

• 优缺点

  • 结合了 RDB 与 AOF 的优点，恢复速度快，增量用 AOF 表示，数据更完整（取决于同步策略）、也无需 AOF 重写

  • 与旧版本的 redis 文件格式不兼容