Not Only SQL~03.Redis持久化策略
本文是上一篇文章的后续,详情点击该链接~
关于持久化策略
redis的持久化策略其实对于应用者来说并没有太大的价值,可是对于维护者来说的话呢作用还是比较显著的。
Redis不仅仅是一个内存型数据库，它其实还具备持久化能力。Redis每次启动时都会从硬盘存储文件中把数据读取到内存中。运行过程中操作的数据都是内存中的数据。
关于持久化策略这个问题,一般是包含两种,一种是RDB,另一种则是AOF
RDB（Redis DataBase）
RDB这种模式是默认模式，可以在指定的时间间隔内生成数据快照（snapshot），默认保存到dump.rdb文件中。当redis重启后会自动加载dump.rdb文件中内容到内存中。用户可以使用SAVE（同步）或BGSAVE（异步）手动保存数据。可以设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令，可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。
而且rdb文件是一个紧凑文件，直接使用rdb文件就可以还原数据。数据保存会由一个子进程进行保存，不影响父进程做其他事情。恢复数据的效率要高于aof
但是RDB有一个缺陷,当频率不达标的时候,异常断电,会导致数据丢失,而且数据量级不确定。因为它的频率和数据写的频率相关。
什么是频率不达标?
我们进入redis的bin目录下的redis.conf配置文件里面看看
那什么是频率不达标呢?就比如说,假设300秒之内,对数据库只进行了九次修改,这个时候突然断电,那这数据就丢失了。或者说60秒内,9999次突然断电,那结果还是丢失了~当然,也不是每次都会完全丢失,具体丢失多少,也没准。这也是快照式数据持久化的唯一缺陷
虽然说,这个频率是可以手动调整的,但是假如调整的太快或者太频,那么又会对redis的损耗太大。
AOF（AppendOnly File）
AOF默认是关闭的，需要在配置文件redis.conf中开启AOF。Redis支持AOF和RDB同时生效，如果同时存在，AOF优先级高于RDB（Redis重新启动时会使用AOF进行数据恢复）
AOF的原理则是监听执行的命令，如果发现执行了修改数据的操作，同时直接同步到数据库文件中，同时会把命令记录到日志中。即使突然出现问题，由于日志文件中已经记录命令，下一次启动时也可以按照日志进行恢复数据，由于内存数据和硬盘数据实时同步，即使出现意外情况也需要担心。
所以说AOF相对RDB,数据还是更加安全的。但是缺点的话呢,在相同数据集里,AOF要大于RDB。相对RDB可能会慢一些。
如何开启?
我们现在还是在刚刚那个redis的bin目录下的redis.conf配置文件中
总结
由此对比就可以看出,AOF相比RDB显得更加安全,但是效率可能要慢一些。RDB或许效率快,但是安全性就不如ADF了