Redis持久化

Redis持久化的意义

意义在于故障恢复，我们都知道，redis数据主要操作的就是内存，那么数据肯定也是在cache内存中存储的。万一生产环境出现了灾难性的故障，redis所在的主机一旦宕机，那么数据就会全都丢失了。所以说将数据从内存中持久化到磁盘中是很有必要的。

RDB和AOF持久化

RDB是对redis的数据进行周期性的持久化，也就是说，每隔一个周期性的时间，对redis的全量数据进行一次持久化。

AOF是对每条写入命令作为日志，以append-only的形式写入一个日志文件中，在redis重启的时候，可以通过回放AOF命令来恢复整个数据集。因为redis中会不断的更新、淘汰数据，所以当AOF膨胀到一定大小的时候，会基于redis中的最新数据重新构建一份比较小的文件，将历史的文件删除掉。

当然如果仅仅是将redis作为一个缓存来使用的话，可以禁止AOF和RDB。
如果两种方式都开启的话，redis会优先使用AOF来重新构建数据，因为AOF数据更加完整。

RDB的优缺点

优点

• RDB会生成多个数据文件，每个数据文件代表了redis某一时刻中的数据，这种多数据的存储方式非常适合做冷备，可以将这些数据上传到某个地方的云上，
• RDB对redis的性能影响非常小，因为redis只需要一个fork子进程，让子进程来执行磁盘IO操作进行持久化就可以了。
• 相对于AOF日志持久化机制来说，用RDB数据文件来做数据恢复，更加快速，时间更短
  缺点
• 因为RDB是周期性的，那么在他快照数据周期中的时候宕机了，就必然会损失一部分数据，如果周期是5分钟，那么最长就可能损失5分钟的数据。
• RDB每次生成数据快照的时候，如果数据文件特别大，有可能会对用户的读写造成暂停服务数毫秒甚至数秒。

AOF的优缺点

优点

• AOF可以更好的保护数据不丢失，因为每隔1秒，AOF就会进行一次fsync操作，将缓冲中的操作日志持久化到磁盘的文件中。最多丢失1秒的数据。
• AOF文件以append-only的形式写入，所以没有任何磁盘寻址的开销，写入的性能非常高，且不容易破损，即使文件尾部损坏也很容易恢复
• 即使AOF文件过大，重写新的日志文件时也不会影响客户端的读写，因为在写入新的rewrite log时，会对其进行指导压缩，创建出一份当前数据需要的最小操作日志。
• AOF通过非常可读的方式进行记录，比如对redis进行了误删操作flushall清除了所有的数据，这时候只要将后台还没有进行rewrite操作的日志文件拿出来，删除最后一个flushall操作命令，然后做数据恢复就可以了

缺点

• 对于同一份数据来说，AOF的日志文件会比RDB的快照文件大很多
• AOF开启后，redis 支持写的QPS会比RDB支持写的QPS低一些，因为每秒都会进行fsync操作，当然性能依旧还是很高的
• AOF恢复的时候容易发生bug，因为是大量的日志数据进行数据恢复，不过后来rewrite操作的时候回基于当前数据重新构建，而不是通过历史的AOF日志文件更新，所以数据的健壮性会好很多。

RDB和AOF选型

• 最好不要仅仅使用RDB，因为这样可能会使你丢失一部分数据
• 最好不要仅仅使用AOF，因为RDB的冷备恢复速度更快，并且数据更加健壮，不怕bug
• 最好是综合两种备份来使用，可以使用AOF做数据恢复的第一选择， 万一文件损坏了，可以有更加健壮的RDB来做数据恢复