Redis持久化——如何选择合适的持久化方式

1 RDB
持久化

RDB
的优点:

• 体积更小：相同的数据量RDB
  文件数据比AOF
  的小，因为RDB
  是紧凑型文件
• 恢复更快：因为RDB
  是数据的快照，基本上就是数据的复制，不用重新读取再写入内存。
• 性能更高:   父进程在保存RDB
  时候只需要fork
  一个子进程来干活，无需父进程，保证了Redis
  正常处理读写命令的性能。

RDB
的缺点：

• 故障丢失：因为RDB
  是全量的，又不能频繁的执行RDB
  文件，因此越大的时间间隔数据丢失的也就越多
• 耐久性差：相对AOF
  的异步策略来说，因为RDB
  的复制是全量的，即使是fork
  的子进程来进行备份，当数据量很大的时候对磁盘的消耗也是不可忽视的，尤其在访问量很高的时候，fork
  的时间也会延长，导致CPU
  吃紧，耐久性相对较差。
• 兼容性差：由于Redis
  更新换代的过程中RDB
  文件的格式一直在变化，老的版本Redis
  可能无法恢复新版本的RDB
  文件。

2 AOF
持久化

AOF
的优点：

• 数据保证：我们可以根据需要设置合适的回写策略，来保障数据尽可能少的丢失
• 易于解析：相对于RDB
  文件，AOF
  文件更易于理解和解析，且没有兼容性问题。

AOF
的缺点:

• 性能相对较差：它的操作模式决定了它会对redis
  的性能有所损耗
• 体积相对更大：尽管是将aof
  文件重写了，但是毕竟是操作过程和操作结果仍然有很大的差别，体积也毋庸置疑的更大。
• 恢复速度较慢：由于恢复的时候要逐条解析命令并写入，相对于RDB
  文件的恢复比较慢。

• 兼顾了性能与数据的同时也牺牲了部分性能
• AOF
  文件中添加了RDB
  格式的内容，使可读性变差，并且由于混合了RDB
  的内容，与RDB
  文件相同具有兼容性的问题

4 如何选择合适的持久化方式

• 如果你的业务场景需要很高的性能，或者宕机之后能够尽快的恢复，而对数据完整性的要求不是那么高，那么可以采用RDB
  持久化的方式。
• 如果你的业务场景对数据完整性的要求很高，那么可以采用AOF
  的持久化方式，而至于采用那种回写策略，则取决于你对数据完整性的要求程度。
• 如果你的业务场景既要兼顾性能，又注重数据完整性，那么可以采用混合持久化的方式。
• 如果你对数据丢失无所谓，追求性能最大化的情况下，甚至可以禁用持久化。