Redis持久化
Posted dddjp
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis持久化相关的知识,希望对你有一定的参考价值。
redis持久化
官方推荐都启用(先使用aof)
-
对数据不敏感,单独用RDB
-
不建议单独使用AOF
1.rdb
在指定时间间隔内,将内存中的数据作为一个快照文件(snapshot)写入到磁盘,读取的时候也是直接读取snapshot文件到内存中
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。
redis单独创建(fork)一个进程来持久化,会先将数据写入临时文件中,待上次持久化结束后,会将该临时文件替换上次持久化文件,比aof高效,但是最后一次数据可能会丢失
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000
劣势
1). 如果你想保证数据的高可用性,即最大限度的避免数据丢失,那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。
2.aof
以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。
以日志形式记录每个写操作,启动时通过日志恢复操作
默认每秒记录一次,如果宕机该秒记可能失效
bgrewriteaof 因为日志是追加方式,文件会越来越大,当超过了设置的阈值时,日志文件会压缩,只保留可以恢复数据的最小指令集
主进程会fork出一条新的进程对文件重写,重写aof文件的操作并没有读取旧的aof文件,而是将整个内存的数据内容用命令的方式重写了一个新的aof文件。
当aof文件大小是上次rewrite后大小的一倍且文件大于64mb时触发重写
appendonly no
appendfilename appendonly.aof
appendfsync everysec
no:表示等操作系统进行数据缓存同步到磁盘(快)
always:表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全)
everysec:表示每秒同步一次(折衷,默认值)
劣势
1). 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2). 根据同步策略的不同,AOF在运行效率上往往会慢于RDB。总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效
如果aof或rdb文件语法有误,可以使用上面两条命令来修复。
aof修复命令:redis-check-aof --fix appendonlly.aof
rdb修复命令:redis-check-rdb--fix dump.rdb
以上是关于Redis持久化的主要内容,如果未能解决你的问题,请参考以下文章