Redis持久化机制
一、redis持久化的意义
在于故障恢复
如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据
如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的
二、持久化的方式- RDB方式
这是系统的默认方式，每隔一段时间就将内存中以快照的方式写入到二进制文件中，默认为dump.rdb，可以配置设置自动做快照持久化方式，我们可以配置redis在n秒内如果超过m个key就修改自动做快照。
Snapshotting设置:系统的默认设置
save 900 1 #900秒内如何超过1个Key被修改则发起快照保存
save 300 10 #300秒内如果超过10个key被修改,则发起快照保存
save 60 10000 ##60秒内如果超过10000个key被修改,则发起快照保存
并且会每隔100毫秒就执行一次serverCron方法，检查Snapshotting设置有没有满足的条件，满足则发起快照保存。
三、持久化的方式- AOF方式(append-only file)
AOF比快照方式有更好的持久化性,是由于在使用AOF时,redis会将每一个收到的写命令都通过write函数追加到命令中,当redis重新启动时会重新执行文件中保存的写命令来在内存中重建这个数据库的内容.这个文件在bin目录下:appendonly.aof
aof不是立即写到硬盘中,可以通过配置文件修改强制写到硬盘中.
aof的配置：
appendonly yes //启动aof持久化方式有三种修改方式
#appendfsync always//收到命令就立即写到磁盘,效率最慢.但是能保证完全的持久化
#appendfsync everysec//每秒写入磁盘一次,在性能和持久化方面做了很好的折中
#appendfsync no //完全以依赖os 性能最好,持久化没保证
四、两种方式的比较
RDB
优点：快！性能高，并且恢复数据的时候，是直接把数据文件直接读到内存，恢复速度很快
缺点：容易缺失最后一次的key修改，比如我修改了一条key，但是要隔900秒才发起快照保存，此时redis宕机了，这条修改key的信息就没有保存了，但是对于数据安全性不高的项目还是可以接受的
AOF
优点：安全性能高，每一条命令都会保存，并且如果我们执行了那条清空数据库的命令，此时数据库会清空，RDB方法恢复不了，但是AOF方法可以，只需要打开appendonly.aof，删除掉清空数据库的命令就可以了。
OF方法可以，只需要打开appendonly.aof，删除掉清空数据库的命令就可以了。
缺点：占用内存上，恢复慢；
