redis持久化之RDB and AOF原理

redis官方提供了两种持久化方式

RDB   和 AOF。

 

RDB(快照):

快照是基于内存数据的二进制序列化形式,

redis是单线程程序,使用多了多路复用api,但是rdb是io文件操作,io文件操作是不可以使用多路复用技术的。

所以rdb使用了操作系统的多线程cow(Copy on Write)机制实现快照持久化,这个机制很少人知道。

redis在持久化的时候会调用glibc的函数fork产生一个子线程,持久化处理交给子线程处理,主线程继续处理线上请求。

子线程做数据持久化,不会修改现在的内存数据结构,它只是对数据结构进行遍历读取,然后序列化到磁盘里,但是主线程不一样,它必须持续服务客户端请求,然后对内存里的数据进行修改。

调用方式:

手动调用执行save和bgsave命令可以手动触发RDB持久化

--save前台调用会阻塞当前服务器,知道RDB完成为止,如果数据量大的话会造成服务器的阻塞,线上环境一般不推荐使用

--bgsave后台调用,执行bgsave命令时候redis进程会fork一个子进程来完成io文件操作,完成后自动结束,只有fork的时候会阻塞主线程,时间很短,推荐使用

自动调用通过设置配置文件,配置redis.config文件如下:

save  
save 900 1

 这个命令指的是如果900秒内有一条key信息发生变化就执行bgsave。

在执行shutdown的时候,如果没有开启aof持久化,也会自行执行一次bgsave。

 

 

AOF:

aof日志存储的是redis服务器的顺序指令序列,aof日志只记录对内存进行修改的指令记录。

记录的是resp通讯协议的命令存储格式。

当你的redis数据全没有了,通过aof恢复相当于重放,重新执行的之前所有写命令操作,

当然存储在文件里面的都是resp格式的东西。

如果redis长期运行,aof的日志会越来越长,如果发生宕机重启,重放整个aof文件是很耗时的。导致redis会无法对

外提供服务,所有需要对aof日志瘦身, 就用到了重写机制

重写机制:

每次都是生成一个aof文件,都会去掉一些重复和无用的命令,达到瘦身的需求。

调用方式:

1.可以手动调用bgrewriteaof命令。

2.也可以自动调用

auto-aof-rewrite-min-size 64MB
auto-aof-rewrite-min-percenrage 100

上面两个配置表示: 
- 当AOF文件小于64MB的时候不进行AOF重写 
- 当当前AOF文件比上次AOF重写后的文件大100%的时候进行AOF重写

 

 

Redis重启时加载持久化文件的顺序

--redis重启的时候会优先加载aof文件,如果aof文件不存在再去加载rdb文件,

--如果aof文件和rdb文件都不存在,则直接启动

--如果加载aof和rdb文件报错,则启动失败

 

 

Redis4.0之后,很少使用rdb来恢复内存状态, 因为会丢失大量数据,我们通常使用aof重放,但是重放aof文件相对于

rdb要慢得多,这样启动会要很长时间,redis4.0为了解决这个问题,新增了一个新的持久化方式选项-混合持久化,

aof重写产生的文件同时包含rdb格式的内容和aof格式的内容,其中rdb格式的内容记录所有的数据,aof记录发生更改的数据,这样就可以快速的生成重写文件。

这个功能可以在redis.conf里面开启

aof-use-rdb-preamble no

 

以上

你可能感兴趣的:(redis)