RDB 快照存储

• 将内存中的所有数据 完整的保存到硬盘中
• 机制
  • fork出⼀个子进程 ，专门进行数据持久化,，将内存中所有数据保存到单个rdb文件中(默认为
    dump.rdb)
  • redis重启后, 会加载rdb文件中的数据到内存中
• 触发方式
  • 配置中设置自动持久化策略
  • SAVE | BGSAVE | SHUTDOWN (前提是设置了自动持久化策略)
• 相关配置

 save 60 1000 # 多久执行⼀次自动快照操作 60秒内如果更新了1000次，则持久化⼀次
 stop-writes-on-bgsave-error no # 创建快照失败后,是否继续执行写命令
 rdbcompression yes # 是否对快照文件进行压缩
 dbfilename dump.rdb # 如何命名快照文件
 dir ./ # 快照文件保存的位置
 save # 关闭RDB机制

• 优点
  • 十分适合备份
  • 故障修复
  • 大数据集重启更快
  • 写时复制：子进程单独完成持久化操作, 父进程不参与IO操作，最大化redis性能
• 缺点
  • 可能丢失部分数据（不是实时保存数据）
  • 经常需要fork()复制数据到硬盘，十分耗时，数据量大时，redis响应会变慢

AOF 只追加文件

• Append-only file 只追加文件
  • 只追加 而不是全部重新写入
  • 追加命令 ，而不是数据
• 机制
  • 主线程将 写命令 追加到aof_buf(缓冲区)中， 根据使用的策略不同，子线程 将缓存区的命令写
    入到aof文件中 (不使⽤子进程)
  • 当redis重启时，会重新执行aof文件中的命令来恢复数据
    • 如果同时开启了 RDB， 则优先使用 AOF
• 文件修复
  • 如果AOF出错 (磁盘满了/写入中途宕机等)， 则redis重启时会拒绝使用该AOF文件
  • 修复步骤
    • 首先备份AOF文件
    • 使用redis-check-aof工具进行修复 (⼀般会删除末尾无法恢复的命令)
    • 重启redis服务器， 自动载入修复后的AOF文件，进行数据恢复

$ redis-check-aof –fix
# 可选操作: 使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件
之间的不同之处。

• 文件重写/压缩
  • AOF 提供了重写/压缩机制(优化命令)， 以避免AOF文件过大
  • fork子进程来完成 AOF 重写
• 相关配置

appendonly no # 是否开启AOF机制
appendfsync everysec # 多久将写⼊的内容同步到硬盘 每秒⼀次
no-appendfsync-on-rewirete no # 重写aof⽂件时是否执⾏同步操作
auto-aof-rewrite-percentage 100 # 多久执⾏⼀次aof重写, 当aof⽂件的体积⽐上⼀次重
写后的aof⽂件⼤了⼀倍时
auto-aof-rewrite-min-size 64mb # 多久执⾏⼀次aof重写,当aof⽂件体积⼤于64mb时
appendfilename appendonly.aof # aof⽂件名
dir ./ # aof⽂件保存的位置(和rdb⽂件共享该配置)

• 优点
  • 更可靠 默认每秒同步⼀次操作, 最多丢失⼀秒数据
  • 可以进行文件自动重写, 以避免AOF文件过大
• 缺点
  • 相同数据集，AOF体积更大
  • 除非是不同步情况，否则普遍比RDB慢
  • 健壮性比RDB差

如何选择？

对于更新频繁, ⼀致性要求不是非常高的数据， 可以选择使⽤redis进行持久化存储

• RDB or AOF
  • 数据安全性要求高，都打开
  • 可以接受短时间的数据丢失，只使用RDB
  • 即使使用AOF，最好也开启 RDB，因为便于备份并且回复速度快， bug更少