RDB详解
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
RDB配置
打开redis.conf配置文件，在SNAPSHOTTING模块下，看到rdb的配置信息
save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。默认配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
若不想用RDB方案，可以把 save "" 的注释打开，下面三个注释，或者通过命令config set save ""
默认数据文件
本地默认数据文件名称为dump.rdb,可通过在redis.conf中修改文件名及文件所在位置
触发RDB快照
- 在指定的时间间隔内，执行指定次数的写操作
- 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
- 执行flushall 命令，清空数据库所有数据
- 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据
RDB 的优缺点
优点：
- 适合大规模的数据恢复。
- 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
- 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
- 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
RDB总结
AOF
AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
修改redis.conf文件开启aof模式，如以下所示：
aof配置触发重写配置
通过客户端执行info persistence 命令查看，当前aof文件大小，及上次重写后记录的文件大小
aof重写机制
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制。根据aof配置生效，达到以下条件时触发aof重写,生成新的aof文件，只保留可以恢复数据的最小指令集.或者可以使用命令bgrewriteaof进行重写文件。
aof重写原理
- AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)。
- 遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件。
- 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
AOF优缺点
优点
- 每次修改同步：appendfsync always同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
- 每秒同步：appendfsync everysec异步操作，每秒记录，如果一秒内宕机，仅一秒内的数据丢失
缺点
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- Aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
AOF总结
持久化方案选择
无论是RDB还是AOF，redis开启持久化都是要付出性能代价，对于rdb持久化，一方面是bgsave在进行fork操作时Redis的主进程会阻塞，另一方面，子进程向硬盘写数据也会带来IO压力；aof持久化，向硬盘写数据的频率大大提高（默认配置时每秒写一次），IO压力会更大。
在实际生产环境中，根据数据量、应用对数据的安全要求等情况，会有各种各样的持久化策略。比如完全不使用任何持久化，使用RDB或AOF中的一种，或者同时开启RDB和AOF。
（1）如果Redis中的数据完全丢弃也没有关系，那么可以不开启持久化；
（2）在单机环境下（对于个人开发者，这种情况可能比较常见），如果可以接受十几分钟或更多的数据丢失，选择RDB对Redis的性能更加有利；如果只能接受秒级别的数据丢失，应该选择AOF。
（3）主从配置情况
master：完全关闭持久化（包括RDB和AOF），这样可以让master的性能达到最好
slave：关闭RDB，开启AOF（如果对数据安全要求不高，开启RDB关闭AOF也可以），并定时对持久化文件进行备份（如备份到其他文件夹，并标记好备份的时间）；然后关闭AOF的自动重写，然后添加定时任务，在每天Redis闲时（如凌晨12点）调用bgrewriteaof。
