Redis持久化就是将数据存入磁盘，以保证数据在redis在崩溃时减小对数据的影响，redis提供两种持久化方式。
1.快照（snapshotting）方式RDB，RDB是redis默认的持久化方式，可以再redis.conf中配置其存储频度，如图:
由于项目比较小，数据也没啥用，就随便设置了小，1分钟内有100次写操作则进行一次快照，同理分别10分
钟10次，1小时1次。
此外也还可以通过命令方式执行快照如:save,bgsave,区别使save会阻塞redis写操作，而bgsave会开启异步执行非阻塞。
此外还可以开启压缩存储，以减小快照大小，但是在存储和读取效率会有所下降。
通过RDB文件恢复数据
将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb
RDB 的优缺点
优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
2.AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
从配置文件了解AOF
打开 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快照
根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。
根据AOF文件恢复数据
正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。
AOF的重写机制
前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。
