前言
redis虽然是内存缓存程序，但是可以将内存中的数据保存到硬盘上，从而实现数据保存。目前有两种redis数据持久化方式，分别是RDB和AOF。
RDB模式
RDB之简介
RDB(redis database)，redis每隔一段时间对当前数据生成一个“快照”，默认只保留最新的一份快照，默认快照文件名为“dump.rdb”。redis.conf的配置如下：
# 900秒内，如果超过1个key被修改，则发起快照保存 save 900 1 # 300秒内，如果超过10个key被修改，则发起快照保存 save 300 10 # 60秒内，如果超过10000个key被修改，则发起快照保存 save 60 10000
RDB之优缺点
- 优点
- RDB基于时间点保存数据，可以通过脚本自定义时间点备份并保留多个备份，当出现问题时可以恢复到不同时间点的版本。
- 大数据量时恢复较快
- 缺点：
- 实时性不高，一旦发生故障，可能会丢失好几分钟的数据。
- 数据量很大时，备份时间较长。
AOF模式
AOF之简介
AOF(Append Only File)，redis将所有对数据库进行写入的命令（及其参数）记录到AOF文件（默认文件appendonly.aof）中。redis.conf配置如下：
appendfsync yes # 每次有数据修改时都会写入AOF文件 appendfsync always # 每秒同步一次。aof默认策略 appendfsync everysec
appendfsync的三个可选值：
- everysec：每秒写回，每个写命令成功执行完，吸纳吧日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区的内容写入磁盘。优点：基本不丢数据。缺点：影响主线程性能。
- always：同步写回，每个写命令成功执行完，立马将日志同步写入磁盘。
- no：操作系统控制的写回，每个写命令成功执行完，只是先把日志写到AOF的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。优点：性能好。缺点：落盘时机不受redis控制，宕机时损失数据可能很多。
AOF重写机制
为了避免AOF文件多大，redis根据数据库现状创建一个新的AOF文件。旧日志中的多条重复命令被合并为一条命令。AOF重写时会fork一个子进程bgrewriteaof来处理（fork的一瞬间会阻塞主线程），避免对主线程造成过多的影响。
AOF之优缺点
- 优点：
- 实时性更强，即便故障，按照默认的fsync策略，也只会丢失1秒的数据。
- 缺点：
- 相较于RDB模式，更占用硬盘存储空间。而且由于记录的是操作命令，故障恢复时需要逐一执；如果操作日志很多，恢复就很缓慢。
补充
- redis4.0中提出了一个混合使用AOF和RDB的方法。简单来说，RDB以一定频率执行，两次RDB之间执行AOF。这样一来，RDB不需要频繁执行，AOF也只用记录两次RDB之间的操作。设置参数为：
aof-use-rdb-preamble yes
