N.1 持久化介绍
1）Redis 提供了多种不同级别的持久化方式：
（1）RDB(Redis数据库) 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
（2）AOF （Append-only file）持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。
（3）AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite,指的是有规律的大量命令合成少量命令），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
2）Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整 。
你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
N.2 RDB持久化
1）RDB的介绍(是默认的)
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。RDB是Redis默认的持久化方式，会在对应的目录下生产一个dump.rdb文件，重启会通过加载dump.rdb文件恢复数据。
2）RDB优点
（1）只有一个文件dump.rdb，方便持久化;
（2）容灾性好，一个文件可以保存到安全的磁盘；
（3）性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化;
（4）如果数据集偏大，RDB的启动效率会比AOF更高;
3）RDB缺点
（1）数据安全性低：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障,会发生数据丢失;
（2）由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒
4）对过期key的处理
（1）持久化key之前，会检查是否过期，过期的key不进入RDB文件;
（2）数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）;
5）配置参数：redis.conf文件 内容如下 ：
147 save 900 1 #在900秒内，如果有1个key发生变化，执行RDB；
148 save 300 10 #在300秒内，如果有10个key发生变化，执行RDB；
149 save 60 10000 #在60秒内，如果10000个key发生变化，执行RDB；
164 stop-writes-on-bgsave-error yes #当后台写进程出错时，禁止写入新的数据；
170 rdbcompression yes #RDB是否压缩 如果看中性能 选no 压缩会节约空间，但会影响备份和恢复性能；
182 dbfilename dump.rdb #生成的文件名；
192 dir ./ #存放rdb文件的目录；
6）RDB的缺点：
在两次快照之间，如果发生断电，数据会丢失；
举例：在生成rdb后，插入新值。突然断电，数据可能会丢失；
N.3 AOF持久化
1）AOF的介绍
AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作文件中可以看到详细的操作记录出现是为了弥补RDB的不足（数据的不一致性,比如并发的情况下），所以它采用日志的形式来记录每个写操作，并追加到文件中，Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
2）AOF优点
（1）数据安全性更高:AOF持久化可以配置appendfsync属性，其中always，每进行一次命令操作就记录到AOF文件中一次。
（2）通过append模式写文件。
3）AOF缺点
（1）AOF文件比RDB文件大，且恢复速度慢；
（2）根据同步策略的不同，AOF在运行效率上往往会慢于RDB。
4）过期的key
当服务器以AOF持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被惰性删除或者定期删除，那么AOF文件不会因为这个过期键而产生任何影响。
当过期键被惰性删除或者定期删除之后，程序会向AOF文件追加（append）一条DEL命令，来显式地记录该键已被删除。
5）配置参数：redis.conf文件 内容如下 ：
509 appendonly yes #启动aof 改为yes；
513 appendfilename "appendonly.aof" #文件名 ；
538 # appendfsync always #每个操作都记录日志：优点：安全。缺点：慢；
539 appendfsync everysec #每秒记录一次日志；
540 # appendfsync no #一般不会用到。由操作系统来决定记录日志的方式；
581 auto-aof-rewrite-min-size 64mb #执行重写的aof文件大小。64兆触发重写；
561 no-appendfsync-on-rewrite yes #生成rdb的时候,是否不写入aof；
6）AOF日志重写案例：
overwrite
（1）举例：假设每个操作都记录日志：
set money 0
incr money
incr money
incr money
incr money
....自增100次
（2）如果每个操作都记录日志，会记录101条日志：
最终结果 money 100
（3）进行日志重写：
把101条，合并成1条
set money 100
N.4 RDB与AOF比较
1）aof文件比rdb更新频率高，优先使用aof还原数据；
2）aof比rdb更安全也更大
3）rdb性能比aof好
4）如果两个都配了优先加载AOF
N.5 持久化案例
[root@bigData111 redis-3.0.5]# ./bin/redis-server ./conf/redis.conf #启动服务器
[root@bigData111 redis-3.0.5]# ps -ef |grep redis #查看是否启动
[root@bigData111 redis-3.0.5]#./bin/redis-benchmark -n 100000 #模拟客户端的压力
查看这两个的文件大小：
AOF持久化：appendonly.aof 如果增加到64MB 就会优化重写(指合并一些命令)
RDB持久化：dump.rdb 文件大小不断增加(按时间规定来增加)