redis RDB和AOF持久化机制

redis 持久化机制

RDB(Redis DataBase)

• 特点
  通过配置触发条件或者手动触发将内存中数据写入到磁盘的临时文件中，作为快照存储。恢复时候把快照读进内存

  # 核心配置
  # 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）  
  # 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）  
  # 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）  
  save 900 1  
  save 300 10  
  save 60 10000 
  # 保存快照失败时,redis停止接受更新操作（例如持久化时候发现磁盘满了，不能再存储。redis会报错起到提示作用）
  stop-writes-on-bgsave-error yes
  # 导出数据库的文件名称  
  dbfilename dump.rdb
  # 配置工作目录 dir /usr/local/redis/workspace
  dir ./
  # 开启rdb压缩模式
  rdbcompression yes
  

  手动触发 bgsave

• 优劣

  • 优
    1. 每隔一段时间备份，全量备份
    2. 灾备简单，可以远程传输
    3. 子进程备份的时候，主进程不会有任何IO操作（不会有写入修改或删除），保证备份数据的的完整性
    4. 相对AOF来说，当有更大文件的时候可以快速重启恢复
  • 劣
    1. 发生故障是，有可能会丢失最后一次的备份数据
    2. 子进程所占用的内存比会和父进程一模一样，会造成CPU负担
    3. 由于定时全量备份是重量级操作，所以对于实时备份，就无法处理了。

AOF(Append Only File)

• 通过日志追加的方式记录用户请求的写指令。恢复时候读取文件再执行一遍恢复。

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

• 优劣

  • 优

    1. AOF更加耐用，可以以秒级别为单位备份，如果发生问题，也只会丢失最后一秒的数据，大大增加了可靠性和数据完整性。

    2. 以log日志形式追加，如果磁盘满了，会执行 redis-check-aof 工具

    3. 当数据太大的时候，redis可以在后台自动重写AOF。当redis继续把日志追加到老的文件中去。

    4. AOF 日志包含的所有写操作，会更加便于redis的解析恢复。
       （ps： 当出现类似FLUSHALL这种悲剧情况时，立刻停掉redis编辑AOF文件删掉这行命令还能恢复回来）

  • 劣

    1. 相同的数据下，AOF文件比RDB大
    2. 对比RDB的故障恢复相对复杂缓慢，会存在异常的AOF文件情况

个人思考

• 默认是开启使用RDB模式持久化的，不想使用RDB就把save ""
• 如果只用redis做缓存的话，可以把持久化关闭
• 如果实际场景可以接受 丢失一段缓存可以使用用RDB模式，不能则使用AOF
• 如果要使用redis持久化，且数据很重要的话。可以RDB和AOF同时开启