RDB:
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
配置文件解说：
打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容
save <seconds> <changes> # save "" save 900 1 save 300 10 save 60 10000
解说：save <指定时间间隔> <执行指定次数更新操作>
save 900 1 的意思是900秒内有一个更改就RDB快照一次，将数据保存到磁盘。2 指定本地数据库文件名，一般采用默认的 dump.rdb 即：dbfilename dump.rdb 存放的默认目录：dir ./
通过RDB恢复数据：
将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。
优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
APF:
AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容
1 redis 默认关闭，开启需要手动把no改为yes
## appendonly yes
2 指定本地数据库文件名，默认值为 appendonly.aof
## appendfilename "appendonly.aof"
3 指定更新日志条件
# appendfsync
always appendfsync everysec
# appendfsync no
解说：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步
4 配置重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。
AOF文件回复数据
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。
优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。
总结：
1、Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
2、RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
3、Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
4、AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
5、Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
6、若只打算用Redis 做缓存，可以关闭持久化。
7、若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。