总结分享 | Redis 持久化

redis提供了两种持久化的方式，分别是RDB (Redis DataBase)和AOF (Append Only File)。

redis默认采用的是RDB方式。

AOF

• 将每条写命令追加至 aof 文件，当重启时会执行 aof 文件中每条命令来重建内存数据
• AOF 日志是写后日志，即先执行命令，再记录日志
  • Redis 为了性能，向 aof 记录日志时没有对命令进行语法检查，如果要先记录日志，那么日志里就会记录语法错误的命令

同步策略

• 记录 AOF 日志时，有三种同步策略
  • Always 同步写，日志写入磁盘再返回，可以做到基本不丢数据，但性能不高。
    • 为什么说基本不丢呢，因为 aof 是在 serverCron 事件循环中执行 aof 写入的，并且这次写入的是上一次循环暂存在 aof 缓冲中的数据，因此最多还是可能丢失一个循环的数据
  • Everysec 每秒写，日志写入 AOF 文件的内存缓冲区，每隔一秒将内存缓冲区数据刷入磁盘，最多丢一秒的数据
  • No 操作系统写，日志写入AOF 文件的内存缓冲区，由操作系统决定何时将数据刷入磁盘

AOF 重写

• AOF 文件太大引起的问题
  1. 文件大小受操作系统限制
  2. 文件太大，写入效率变低
  3. 文件太大，恢复时非常慢
• 重写就是对同一个 key 的多次操作进行瘦身
  1. 例如一个 key 我改了 100 遍，aof 里记录了100 条修改日志，但实际上只有最后一次有效
  2. 重写无需操作现有 aof 日志，只需要根据当前内存数据的状态，生成相应的命令，记入一个新的日志文件即可
  3. 重写过程是由另一个后台子进程完成的，不会阻塞主进程
• AOF 重写过程
  1. 创建子进程时会根据 主进程 生成 内存快照，只需要对子进程的内存进行遍历，把每个 key 对应的命令写入新的日志文件（即重写日志）
  2. 此时如果有新的命令执行，修改的是主进程内存，不会影响子进程内存，并且新命令会记录到 重写缓冲区
  3. 等子进程所有的 key 处理完毕，再将 重写缓冲区 记录的增量指令写入重写日志
  4. 在此期间旧的 AOF 日志仍然在工作，待到重写完毕，用重写日志替换掉旧的 AOF 日志

RDB

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

  • 对应数据文件为 dump.rdb
  • 恢复速度快
    • AOF，以命令为单位，通过执行一条条命令来进行数据恢复，速度慢。
    • RDB，恢复时，直接将磁盘中的数据文件加载到内存中即可。

• 相关命令有两个

  • save - 在主进程执行，会阻塞其它命令
  • bgsave - 创建子进程执行，避免阻塞，是默认方式
    • 子进程不会阻塞主进程，但创建子进程的期间，仍会阻塞，内存越大，阻塞时间越长
    • bgsave 也是利用了快照机制，执行 RDB 持久化期间如果有新数据写入，新的数据修改发生在主进程，子进程向 RDB 文件中写入还是旧的数据，这样新的修改不会影响到 RDB 操作
    • 但这些新数据不会补充至 RDB 文件（两次快照之间宕机了，会丢失数据）

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

  • 频繁执行的话，会影响性能
  • 偶尔执行的话，如果宕机又容易丢失较多数据

  save 900 1      -- 900秒内至少有一个改动
  save 300 10		-- 300秒内至少有10个改动
  save 60 10000	-- 60秒内至少有10000个改动
  

  
  

混合持久化

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

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

    • aof-use-rdb-preamble yes
      

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

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

• 优缺点

  • 结合了 RDB 与 AOF 的优点，恢复速度快，增量用 AOF 表示，数据更完整（取决于同步策略）、也无需 AOF 重写
  • 与旧版本的 redis 文件格式不兼容