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 <seconds> <changes>

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

 

以上