Redis6.x持久化配置AOF+RDB的选择问题和混合模式超级大汇总—

简介： Redis6.x持久化配置AOF和RDB的选择问题

Redis提供了不同的持久性选项：
- RDB持久化以指定的时间间隔执行数据集的时间点快照。
- AOF持久化记录服务器接收的每个写入操作，将在服务器启动时再次读取，重建原始数据集。使用与Redis协议本身相同的格式以仅追加方式记录命令，当文件太大时，Redis能够重写

补充之前的配置

auto-aof-rewrite-min-size
AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,6.x默认配置64mb。

auto-aof-rewrite-percentage
当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。

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是否存在

本文作者为DBC，转载请注明。