Redis的持久化操作
Redis提供了两种持久化操作
RDB,AOF
RDB是什么
在指定的时间间隔中将内存的数据集快照写入磁盘,它恢复是将快照文件直接读取到内存中
如何利用RDB进行恢复
在我们使用RDB持久化策略的时候,注意有可能会丢失最后一份数据,因为在执行完一次rdb操作后,rdb执行策略时间会开始重新计算,因为没有达到时间所以会丢失
具体操作:
1.关闭Redis后
2.启动redis后,备份数据会直接被加载
优势
1.适合大规模的数据恢复
2.对数据完整性和一致性要求不高的更适合
3.节省磁盘空间
4.恢复速度快
不足处
1.Fork时候,内存中数据被克隆了一份,大致两倍的膨胀性需要考虑
2.虽然使用了写时复制技术,但是数据庞大时消耗性能
3。redis意外down掉的话,就会丢失最后一次快照后修改
AOF是什么
AOF是什么
以日志的形式记录写操作(增量保存),只记录写操作不记录读操作,只许追加文件但是不让改写文件,换言之redis重启的话根据日志文件将写指令从前到后执行一遍
AOF持久化流程
如何开启
默认不开启,可以修改redis.conf中的配置文件,默认为appendonly.aof,其中aof文件保存的路径和RDB一致
如果两个持久化操作同时开启,redis执行哪一种
AOF和RDB同时开启,reids默认读取AOF中的数据
如何进行恢复操作
当redis启动时候会自动读取appendonly.aof文件内容
异常恢复
通过命令redis-check-aof–fix进行恢复
AOF同步频率设置
appendfsync always:始终同步,每次写入都会立刻计入日志
**everysec:**每秒同步,每秒计入日志一次,如果down掉,这一秒数据会丢失
no:从来不进行主动同步,把同步时间交给操作系统
Rewrite压缩
AOF采用文件追加方式,文件会越来越大,为了避免这种情况,新增了重写操作,当超过文件设置的阙值后,启动AOF的内容压缩,只保留可以恢复数据的最小指令集
原理
AOF文件持续增长过大的时候,会fork出来一条新线程来讲将文件重写
优势
备份机制稳健,丢失数据概率低
可读的日志文本,可以处理误操作
劣势
占用更多的磁盘空间
恢复速度慢
每次读写同步,有一定的内存压力
存在个别bug,造成不能恢复
总结
使用哪个较好
官方推荐两个都启用
对于数据不敏感使用RDB
不建议单独使用AOF,可能出现bug
如果只是作为内存缓存,可以都不用