redis持久化配置RDB和AOF选择

• redis提供了不同的持久化选项
  • RDB持久化以指定的时间间隔执行数据集的时间点快照
  • AOF持久化记录服务器接收的每个写入操作，将在服务器启动时再次读取，重建原始数据集。使用与redis协议本身相同的格式以仅追加方式记录命令，当文件太大时，redis能够重写
• RDB的优缺点
  • 优点
    • RDB最大限度的提高了redis的性能，父进程不需要参与磁盘I/O
    • RDB文件紧凑，全量备份，适合用于进行备份和灾难恢复
    • 在恢复大数据集时的速度比AOF的恢复速度要快
    • 生成的是一个紧凑压缩的二进制文件
  • 缺点
    • 如果您需要在redis停止工作后（例如断电后）将数据丢失的可能性将至最低，则RDB并不好
    • RDB经常需要fork才能使用子进程持久存储在磁盘上。如果数据集很大，fork可能会非常耗时
• AOF的优缺点
  • 优点
    • 数据更加安全
    • 当redis AOF文件太大时，redis能够在后台自动重写AOF
    • AOF以易于理解和解析的格式，一个接一个的包含所有操作的日志
  • 缺点
    • AOF文件通常比同一数据集的等效RDB文件大
    • 根据确切的fsync策略，恢复的时候AOF可能比RDB慢
• 在线上我们该如何选择
  • RDB持久化与AOF持久化一起使用
  • 如果redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据
  • 集群中可以关闭AOF持久化，靠集群的备份方式保证可用性
  • 自己指定策略定期检查redis的情况，然后可以手动触发备份、重写数据
  • 采用集群和主从同步
• redis4.0后开始的rewrite支持混合模式
  • 就是RDB和AOF一起用
  • 直接将RDB持久化的方式来操作将二进制内容覆盖到AOF文件中，RDB是二进制，所以很小
  • 有写入的话还是继续append追加到文件原始命令，等下次文件过大的时候再次rewrite
  • 默认是开启状态
  • 好处
    • 混合持久化结合了RDB持久化和AOF持久化的优点，采取了RDB的文件小易于灾难恢复
    • 同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失
  • 坏处
    • 前部分是RDB格式，是二进制，所以阅读性较差
  • 数据恢复
    • 先看是否存在AOF文件，若存在则先按照AOF文件恢复，AOF比RDB全，且AOF文件也rewrite成RDB二进制格式
    • 若AOF不存在，则才会查找RDB是否存在