redis持久化方式
2018-01-24 22:17
190 查看
1、rdb(RedisDataBase)
当满足条件时,redis单独会fork(创建)一个新的线程,会先将内存中的数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次已经持久化好了的文件,整个过程中,主进程是不进行任何IO操作的,确保了极高的性能,此时的主进程还可以进行读写操作。rdb数据持久化的缺点是最后一次持久化的数据可能丢失,当在最后一次持久化的时间截点内还没有持久化,此时机器宕机了或出故障了,那么最后一次的数据就没有持久化到。
Fork:fork的作用是复制一个与当前进程一样的进程,新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,也称为原进程的子进程。
如果的内存中的数据量非常大的时候,rdb持久化的临时文件就会非常大,几乎是原文件的1倍,性能有所降低。
如果当写操作要立刻持久化的时候,可以执行命令:save
save是全阻塞的,bgsave是异步的。
flushall也会产生dump.rdb文件,清空所有数据库的数据,并保存在dump.rdb文件中。
shutdown也会产生dump.rdb文件,将内存中数据保存在dump.rdb文件中
2、aof(AppendOnly File)
aof的持久化:
aof是对redis的所有写操作的命令将他保存在.aof文件中,包括flushall和flushdb命令也会。当你flushall后,shuntdown了之后重启redis,keys*的数据是空的,因为.aof文件的最后一个写操作的语句是flushall,即使前面做了很多写操作,flushall后,前面的数据都没了。
当aof和rdb同时存在时,会加载aof文件,假如aof文件的语法有误,启动redis是会报错了,就如spring配置文件的bean错了,tomcat也会启动不了。rdb文件也是。
如果aof或rdb文件语法有误,可以使用上面两条命令来修复。
aof修复命令:redis-check-aof--fix appendonlly.aof
rdb修复命令:redis-check-rdb--fixdump.rdb
aof是采用文件追加方式,将所有的写操作保存在aof文件中,当文件越来越大时,有可能存在相同的写操作,这些相同的操作可以将他浓缩为一条操作,这样可以减少aof文件的容量。
redis对aof新增了一种重写机制,当aof文件大小超过所设定的阈值时,redis会启动aof文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof。
rewrite的原理:主进程会fork出一条新的进程对文件重写,遍历新进程的内存数据,每条记录有一条set语句。重写aof文件的操作并没有读取旧的aof文件,而是将整个内存的数据内容用命令的方式重写了一个新的aof文件。
触发rewrite的机制:redis会记录上一次重写时aof文件的大小,默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64mb时触发。如果启动redis后没有发生重写的,记录aof文件的大小就启动时加载的aof文件大小
RDB与AOF的选择:
做备份:当数据量大,且对恢复速度有要求,并且数据的一致性要求不高的话,可以只使用RDB
只做缓存:不用开启任何的持久化方式
两者都开启的建议:RDB数据不实时,同时使用两者时服务器只会找AOF文件,可不可以只使用AOF?作者建议不要,因为RDB更适合备份数据库(AOF在不断变化,不好备份)
快速重启,而且不会又AOF可能潜在的BUG,留作万一的手段。
当满足条件时,redis单独会fork(创建)一个新的线程,会先将内存中的数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次已经持久化好了的文件,整个过程中,主进程是不进行任何IO操作的,确保了极高的性能,此时的主进程还可以进行读写操作。rdb数据持久化的缺点是最后一次持久化的数据可能丢失,当在最后一次持久化的时间截点内还没有持久化,此时机器宕机了或出故障了,那么最后一次的数据就没有持久化到。
Fork:fork的作用是复制一个与当前进程一样的进程,新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,也称为原进程的子进程。
如果的内存中的数据量非常大的时候,rdb持久化的临时文件就会非常大,几乎是原文件的1倍,性能有所降低。
如果当写操作要立刻持久化的时候,可以执行命令:save
save是全阻塞的,bgsave是异步的。
flushall也会产生dump.rdb文件,清空所有数据库的数据,并保存在dump.rdb文件中。
shutdown也会产生dump.rdb文件,将内存中数据保存在dump.rdb文件中
2、aof(AppendOnly File)
aof的持久化:
aof是对redis的所有写操作的命令将他保存在.aof文件中,包括flushall和flushdb命令也会。当你flushall后,shuntdown了之后重启redis,keys*的数据是空的,因为.aof文件的最后一个写操作的语句是flushall,即使前面做了很多写操作,flushall后,前面的数据都没了。
当aof和rdb同时存在时,会加载aof文件,假如aof文件的语法有误,启动redis是会报错了,就如spring配置文件的bean错了,tomcat也会启动不了。rdb文件也是。
如果aof或rdb文件语法有误,可以使用上面两条命令来修复。
aof修复命令:redis-check-aof--fix appendonlly.aof
rdb修复命令:redis-check-rdb--fixdump.rdb
aof是采用文件追加方式,将所有的写操作保存在aof文件中,当文件越来越大时,有可能存在相同的写操作,这些相同的操作可以将他浓缩为一条操作,这样可以减少aof文件的容量。
redis对aof新增了一种重写机制,当aof文件大小超过所设定的阈值时,redis会启动aof文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof。
rewrite的原理:主进程会fork出一条新的进程对文件重写,遍历新进程的内存数据,每条记录有一条set语句。重写aof文件的操作并没有读取旧的aof文件,而是将整个内存的数据内容用命令的方式重写了一个新的aof文件。
触发rewrite的机制:redis会记录上一次重写时aof文件的大小,默认配置是当aof文件大小是上次rewrite后大小的一倍且文件大于64mb时触发。如果启动redis后没有发生重写的,记录aof文件的大小就启动时加载的aof文件大小
RDB与AOF的选择:
做备份:当数据量大,且对恢复速度有要求,并且数据的一致性要求不高的话,可以只使用RDB
只做缓存:不用开启任何的持久化方式
两者都开启的建议:RDB数据不实时,同时使用两者时服务器只会找AOF文件,可不可以只使用AOF?作者建议不要,因为RDB更适合备份数据库(AOF在不断变化,不好备份)
快速重启,而且不会又AOF可能潜在的BUG,留作万一的手段。
相关文章推荐
- Redis学习——Redis持久化之AOF备份方式保存数据
- redis的持久化方式
- redis持久化方式
- Redis的持久化之AOF方式
- 辛星解读Redis中的AOF持久化方式
- Redis持久化磁盘IO方式及其带来的问题
- redis的持久化方式 RDB和AOF
- redis 持久化的两种方式
- redis入门之持久化方式
- Redis持久化的两种方式
- Redis学习——Redis持久化之RDB备份方式保存数据
- redis的持久化(RDB和AOF方式)
- [转载] redis 的两种持久化方式及原理
- Redis持久化方式RBD和AOF对比
- redis 的两种持久化方式及原理
- Redis持久化的两种方式
- redis内存数据的持久化方式
- redis 的两种持久化方式及原理
- redis 的两种持久化方式及原理
- Redis学习——Redis持久化之AOF备份方式保存数据