目录
RDB(Redis DataBase)
什么是RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里
备份是如何执行的
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据恢复, 且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加高校。RDB的缺点是最后一次持久化后的数据可能丢失
配置文件
/etc/redis.conf中配置dbfilename dump.rdb
会生成dump.rdb文件
优势
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高更适合使用
- 节省磁盘空间
- 恢复速度快
劣势
- Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
- 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
- 在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改
为什么Redis持久化操作RDB最后一次持久化操作会丢失数据
Redis会单独创建fork一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能,如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式是比较高效的
RDB快照方式,默认是打开的,所以说,每次RDB快照之间是有时间间隔的,如果在一次RDB快照时发生宕机,那上一次快照之后的key数据就会丢失了(前提是没有开启AOF持久化方式 )
AOF(Append Of File)
AOF是什么
以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
AOF持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区内
- AOF缓冲区根据AOF持久化策略[always, everysec, no]将操作sync同步到磁盘的AOF文件中
修复aof
redis-check-aof --fix appendonly.aof
AOF同步频率设置
appendfsync always // 始终同步,每次redis的写入都会立刻记入日志,性能较差但数据完整性比较好
appendfsync everysec // 每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失
appendfsync no // redis不主动进行同步,把同步时机交给操作系统
Rewrite压缩
- AOF采用文件追加方式,文件会越来越大为避免出现此情况,新增重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof
- 重写原理,如何实现重写
Redis会记录上次重写时AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写。
优势
- 备份机制更稳健,丢失数据概率更低
- 可读的日志文本,通过操作AOF稳健,可以处理误操作
劣势
- 比起RDB占用更多的磁盘空间
- 恢复备份速度更慢
- 每次读写都同步的话,有一定的性能压力
AOF(append of file)和RDB(redis database)同时开启
默认根据AOF
总结
官方推荐两个都启用
如果对数据不敏感,可以选单独用RDB
不建议单独用AOF,因为可能会出现Bug
如果只是纯内存缓存,可以都不用