redis持久化RDB和AOF对比

前言

对于redis来说，持久化是必不可少的
持久化主要做灾难恢复，数据恢复
当redis挂了，那redis就不可用了，这样redis就无法做到高可用性
重启redis，如果redis发生了数据灾难，重启之后也是不可用的，没有数据备份，数据也就没有了
redis 的持久化主要有两种方式：RDB和AOF

RDB和AOF介绍

RDB持久化机制，对redis中的数据执行周期性的持久化
AOF持久化机制，对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在进行redis重启时，可以通过回放AOF日志中的写入指令来重构整个数据集

如果我们仅仅是想用redis作为纯内存的缓存用，就可以禁用AOF和RDB的所有持久化机制

通过RDB和AOF，可以将redis内存中的数据持久化到磁盘上面，然后将这些数据备份到其它地方，如云平台
如果redis挂了，或者存放redis 的服务器挂了，彻底无法恢复，可以从云平台拷贝回来之前的数据

如果同时使用两种RDB和AOF持久化机制，redis重启时，会优先使用AOF来重构数据，AOF数据更加完整

RDB持久化的特点

1. RDB会生成多个数据文件，每个数据文件代表某一时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这些数据文件存放到云上去，以定期备份策略来定期备份redis中的数据

   RDB可以做冷备，生成多个文件，每个文件代表某一时刻的完整的数据快照
   AOF也可以做冷备，只有一个文件，你可以每个一定时间，去copy一份这个文件

   RDB做冷备，优点是：由redis去控制固定时长生成快照文件，比较方便
   AOF做冷备，需要自己去手写定时脚本
   RDB做冷备，数据恢复，速度比AOF快

2. RDB对redis对外提供读写服务，影响非常小，可以保持redis高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来执行RDB持久化

   RDB，每次写，都是写入内存，在一定时候，才会把数据写入磁盘中
   AOF，每次都是要写文件，虽然可以快速写入os cache，但是，还是需要一定的时间开销，比RDB慢

3. 相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
   AOF，存放的是指令日志，做恢复的时候，需要回放和执行所有指令日志
   RDB，就是一份数据文件，恢复时，直接加载到内存中

AOF持久化的特点

1. 对于同一份数据而言，AOF文件要比RDB文件更大
2. AOF开启后，支持的写QPS（每秒查询量）要比RDB的QPS低，因为AOF一般会设置成每秒fsync一次日志，当然，每秒性能也是很高。如果要保证一条数据不丢失，可以设置成每写入一条数据，fsync一次，但是这样QPS会下降很多
3. 唯一的缺点，其实就是做数据恢复的时候，比较慢，做冷备时，定期的备份，不方便，要手写复杂的脚本去做

RDB和AOF如何选择

1. 不要仅仅使用RDB，那样会丢失很多数据
2. 也不要仅仅使用AOF，那样会存在两个问题，第一，使用AOF做冷备，没有RDB恢复的快。第二，RDB每次简单粗暴的生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
3. 综合考虑，用AOF来保证数据的不丢失，作为数据恢复的第一选择
   用RDB做冷备，在AOF文件丢失或损坏不可用的时候，还可以用RDB来进行快速的数据恢复