redis AOF和RDB持久化比较

转载：http://doc.redisfans.com/topic/persistence.html
一：redis持久化
redis虽然作为内存式的数据库，但是数据是可以持久化到磁盘上的，持久化的方式有如下几种
1，RDB：在特定的时间间隔内生成数据集的快照
2，AOF：记录服务器执行的写操作的命令，在重启的时候重新执行一遍命令来进行数据集的还原。AOF文件中命令都是以redis协议的格式保存，新命令追加在末尾
3，RDB和AOF持久化方式可以两者共存。如果共存的话，那么redis重启的时候会优先使用AOF来进行数据集的还原，因为AOF相对来说数据集更加的完整
4，可以关闭持久化方式，让数据只存在服务器运行时
二：RDB的优点
1，文件比较紧凑，保存了redis在某一个时间点的数据集，这种文件(dump.rdb,二进制文件)比较适合于备份。你可以选择在每一个小时备份一次，或者是每一天备份一次(备份策略可以选择时间间隔，也可以选择执行n个操作后自动备份，通过save/bgsave手动备份也是ok的)。那么就可以随时将数据集还原到想要的版本
2，文件内容紧凑，可以传输到其他的数据中心
3，性能最大化，RDB备份的流程是父进程会fork出一个子进程，然后子进程去执行备份的工作，父进程无需考虑磁盘io操作
copy-on-write,写时复制的工作策略：
redis rdb保存的时候，调用fork(),启动子进程
子进程将数据写入到临时文件
子进程写数据完毕之后，使用临时rdb文件替换旧文件，删除旧的rdb文件
https://blog.csdn.net/javadocdoc/article/details/109403979

4，因为是直接备份的数据集，所以相对于备份操作日志的AOF持久化方式来说，数据恢复的速度会更快
三：RDB的缺点
1，机器故障的时候有可能会有数据的丢失，因为虽然可以设置不同的保存时间点，但是如果是在两次保存时间点之间发生的数据变化，那么就有可能造成时间间隔内的数据集的不准确（有可能update,del,add数据）
2，每次保存的时候都会fork出子进程去执行数据集的持久化，如果数据集很大的话，那么cpu的占用资源和时间会比较久，可能会造成服务器停止处理客户端
四：AOF的优点
1，因为AOF是追加数据操作到文件中，所以redis会变得更加的耐久，AOF的时间也不会很久。可以设置不同的fsync策略，默认情况下是一秒一次，就算发生了机器故障，那么也只是会丢失掉一秒钟的数据。fsync是再后台线程中执行，主线程还是可以继续处理请求

AOF的耐久性：
1，有一条新命令，就fsync一次到AOF文件，那会很慢，但是是最安全的（完全耐久的持久化方式）
2，一秒执行一次fsync（默认配置），速度够快，最坏情况，丢失一秒数据（推荐）
3，从不fsync,最快，也最不安全

AOF的运作方式
copy-on-write,写时复制的工作策略：
1，redis 调用fork(),启动子进程
2，子进程将现有的AOF数据写入到临时文件
3，对于所有新执行的写入命令，父进程将他们累积到一个缓冲池中，并且将这些改动追加到现有的AOF文件的末尾；这样如果在重写的时候发生了宕机，那么现有的AOF文件是完好的
4，当子进程完成重写时，给父进程发一个信号，父进程收到消息，将缓冲池中的操作记录追加到临时文件中
5，使用新的临时文件替换旧文件（原子性），之后所有的命令就追加到新文件
https://blog.csdn.net/javadocdoc/article/details/109403979

2，redis再AOF文件体积变得很大的时候，会再后台对AOF文件进行自动重写。重写之后的AOF文件包含了对当前数据集所需的最小命令集合。整个重写操作也是安全的，因为redis在创建新的AOF文件的过程中，会继续将命令追加到现有的AOF文件中，即使重写的过程中发生了故障，那么现有的AOF文件是仍然存在的。一旦新的文件重写完毕，那么redis就会切换到新的AOF文件，对重写之后的AOF文件进行数据操作的追加

如果是对一个计数器执行了100次的increment,只是为了保存最终值，那么在当时生成的AOF文件中会有100条执行记录，但是redis在对AOF文件进行优化的时候，会将这100条记录优化为一条记录set

3，AOF文件对数据操作的保存是有序的，然后是以redis协议进行保存，文件容易被读懂。如果执行了flushall操作,那么只需要停止服务器，将AOF文件存储的最后一条命令删除，重启redis,就可以恢复到之前的数据集了

如果在写入AOF文件的时候发生故障，AOF文件出错，那么redis在重启的时候会拒绝加载
解决方法：
1，为现有的AOF文件备份
2，使用redis自带的redis-check-aof程序，对AOF文件进行修复（$ redis-check-aof --fix）
3，使用diff比较修复前后的文件差异，以供原因排查
4，重启redis，等待修复之后的AOF文件的载入，数据恢复

五：AOF的缺点
1，同等数据集，AOF文件的体积通常会大于RDB