Redis持久化机制比对

RDB
1.按特定的时间间隔来为数据集做快照
2.每次持久化都是将全量数据写入，而不是增量
3.每次写入时先将数据写入临时文件再替换掉原来的rdb文件
优点：
1.RDB是一个单独的文件，方便备份以及灾难恢复
2.写数据的模式为parent进程fork出一个子进程来进行磁盘io操作，而parent进程则不需要参与io操作
3.在数据比较大的情况下，启动速度比AOF快
缺点：
1.该模式下如果redis崩溃或者断电情况下可能有数据丢失；因为RDB是按照固定策略(如10秒刷入一次或者5分钟内写入100条数据则刷入磁盘等)来持久化的，那么则断电或者服务崩溃的情况下可能会丢失某一个时间段的数据
2.RDB在进程持久化时需要fork子进程来做磁盘操作，当数据集比较大时fork操作非常耗时，而且在fork过程中server是不能对client服务的；AOF虽然也需要fork但是我们可以设置多久重写一次日志

AOF
1.服务端为每个写操作记录日志；
2.如果服务重启，则根据所记录的log来进行重放来重建整个数据集。
3.日志的记录使用的是redis自己的协议，以追加的模式记录。
4.如果日志过大，redis可以在后台重写日志文件
优点：
1.可以设置各种fsync策略：从不刷数据、每秒同步一次(默认)、每次查询时同步,使用默认策略时可能会丢失最近一秒数据；当配置从不刷数据是由主线程在当前进程没有在刷数据时尽可能的来同步数据到文件，默认策略时会启动一个后台子线程来同步数据到文件
2.日志文件是追加模式，在断点后不牵扯到文件指针查找以及数据丢失问题；就算是因为某些原因(如磁盘写满等)导致日志文件最后一条只写入了一半也可以通过redis-check-aof工具来修复
3.当日志文件过大时，redis会自动重写日志文件(新的文件只保留创建当前数据集需要用到的命令)；在重写的过程中同时还会往老的日志文件写入，一旦新的文件处理完成，redis会切换至新的文件
4.日志文件内容简单清晰，方便人工干预。例如我们调用flushall来刷新保存所有数据失败，如果此时日志文件没有其他命令写入，我们可以停掉server，删掉日志中最后一条错误，然后重新启动来恢复数据
缺点：
1.相同数据集下，AOF模式对应文件通常比RDB对应文件大
2.AOF在某些策略下比RDB模式慢。比如，将fsync设置为每秒一次时，性能仍然很高；将fsync禁用时，性能和RDB接近
3.有些命令可能在AOF下有问题，如BRPOPLPUSH命令在AOF下重新加载时重放失败

说明：
在同一个实例中可以同时使用RDB和AOF持久化机制；但是在服务启动时使用AOF机制来重建数据集(因为AOF最大程度的保留了数据的完整性)

选择：
1.如果要严格保证数据完整性，则RDB与AOF同时使用
2.如果可以容忍少量数据丢失，则使用RDB
3.不建议单独使用AOF(因为RDB备份更方便，重新启动相对较快；AOF可能有bug)

参考：
https://redis.io/topics/persistence