Redis 的 RDB 和 AOF

RDB

• 1. Redis DataBase
• 2. 每隔一段时间，把内存中的数据写入磁盘的临时文件，作为快照，恢复的时候把快照文件读进内存，如果宕机重启，那么内存里的数据肯定会没有的，那么再次启动 redis 后，则会恢复
• 3. 内存备份 -> 磁盘临时文件
     临时文件 -> 恢复到内存
• 4. 优势
  • 4.1 每隔一段时间备份，全量备份
  • 4.2 灾备简单，可以远程传输
  • 4.3 子进程备份的时候，主进程不会有任何 io 操作(不会有写入修改或删除)，保证备份数据的的完整性
  • 4.4 相对 AOF 来说，当有更大文件的时候可以快速重启恢复
• 5. 劣势
  • 5.1 发生故障是，有可能会丢失最后一次的备份数据
  • 5.2 子进程所占用的内存比会和父进程一模一样，如会造成 CPU 负担
  • 5.3 由于定时全量备份是重量级操作，所以对于实时备份，就无法处理
• 6. RDB 的配置
  • 6.1 保存位置，可以在 redis.conf 自定义:
    /user/local/redis/working/dump.rdb
  • 6.2 保存机制
    • save 900 1 # 如果1个缓存更新，则15分钟后备份
    • save 300 10 # 如果10个缓存更新，则5分钟后备份
    • save 60 10000 # 如果10000个缓存更新，则1分钟后备份
    • save 10 3 # 如果3个缓存更新，则 10 秒后备份
  • 6.3 其他配置
    • stop-writes-on-bgsave-error
      yes # 如果 save 过程出错，则停止写操作
      no # 可能造成数据不一致
    • rdbcompression
      yes # 开启 rdb 压缩模式
      no # 关闭，会节约 cpu 损耗，但是文件会大，道理同 nginx
    • rdbchecksum
      yes # 使用 CRC64 算法校验对 rdb 进行数据校验，有 10% 性能损耗
      no # 不校验

AOF

• 1. Append Only File
• 2. 特点
  • 2.1 AOF 更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加可靠性和数据完整性，所以 AOF 可以每秒备份一次，使用 fsync 操作
  • 2.2 以 log 日志形式追加，如果磁盘满了，会执行 redis-check-aof 工具
  • 2.3 当数据太大的时候，redis 可以在后台自动重写 aof，当 redis 继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端的读写操作
  • 2.4 AOF 日志包含的所有写操作，会更加便于 redis 的解析恢复
• 3. 优势
  • 3.1 AOF 更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性，所以 AOF 可以每秒备份一次，使用 fsync 操作
  • 3.2 以 log 日志形式追加，如果磁盘满了，会执行 redis-check-aof 工具
  • 3.3 当数据太大的时候，redis 可以在后台自动重写 aof，当 redis 继续把日志追加到老的文件中去时，重写也是非常安全的，不会影响客户端的读写操作
  • 3.4 AOF 日志包含的所有写操作，会更加便于 redis 的解析恢复
• 4. 劣势
  • 4.1 相同的数据，同一份数据，AOF 比 RDB 大
  • 4.2 针对不同的同步机制，AOF 会比 RDB 慢，因为 AOF 每秒都会备份做写操作，这样相对与 RDB 来说就略低，每秒备份 fsync 没毛病 ，但是如果客户端的每次写入就做一次备份 fsync 的话，那么 redis 的性能就会下降
  • 4.3 AOF 发生过 bug，就是数据恢复的时候数据不完整，这样显得 AOF 会比较脆弱，容易出现 bug，因为 AOF 没有 RDB 那么简单，但是呢为了防止 bug 的产生，AOF 就不会根据旧的指令去重构，而是根据当时缓存中存在的数据指令去做重构，这样就更加健壮和可靠

• 5.配置

  • 5.1 AOF 默认关闭，yes 可以开启
    appendonly no
  • 5.2 AOF 的文件名
    appendfilename “appendonly.aof”
  • 5.3 AOF 同步间隔
    appendfsync everysec
    no：不同步
    everysec：每秒备份，推荐使用
    always：每次操作都会备份，安全并且数据完整，但是慢性能差
  • 5.4 重写的时候是否要同步，no 可以保证数据安全
    no-appendfsync-on-rewrite no
  • 5.5 重写机制，避免文件越来越大，自动优化压缩指令，会 fork 一个新的进程去完成重写动作，新进程里的内存数据会被重写，此时旧的 aof 文件不会被读取使用，类似 rdb，当前 aof 文件的大小是上次 aof 大小的 100% 并且文件体积达到 64m，满足两者则触发重写
    auto-aof-rewrite-percentage 100
    auto-aof-rewrite-min-size 64mb

AOF 和 RDB 区别

• 形式不同
  • RDB：RDB 在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储
  • AOF：AOF 以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录

• 启动效率不同
  • RDB：通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟
  • AOF：由子进程完成这些持久化的工作，可以极大地避免服务进程执行IO操作。如果数据集很大，AOF 的启动效率会更高

• 安全性不同
  • RDB：系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失
  • AOF：由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容