Redis持久化方式(RDB和AOF)

RDB持久化

RDB进行Redis的持久化,是将Redis在内存中的二进制数据进行压测保存到文件,在启动Redis时候,Redis会检测是否存在RDB文件,如果存在就会对文件进行分析和恢复。

两种触发RDB备份的操作

  • SAVE:通过SAVE命令触发Redis进行RDB备份,此时服务器进程会处理备份请求,不会在处理任何其他的命令请求。
  • BGSAVE:通过新建子进程来进行备份,Redis服务器会进行处理客户端的其他命令请求。

配置RDB

如果我们没有在配置文件中显式去配置,Redis会有一个默认的RDB配置。

save 900 1            //900秒内发生1次更新
save 300 10          //300秒内发生10次更新
save 60 10000      //60秒内发生10000次更新

三个条件满足任意一个,BGSAVE命令就会被Redis执行。

计数与计时

redisServer由dirty属性以及lastsave属性。

  • dirty:每次备份开始会被置为0,每一次发生更新该属性会加1。
  • lastsave:每次备份开始都会记录当前时间,通过该属性可以计算出距离上次备份经过了多长时间。
    redis服务器每100毫秒进行一次判断是否应该进行RDB备份,就是通过dirty和lastsave配合配置进行的判断。

AOF持久化

与RDB把内存中二进制数据保存的方式不同,AOF是把更新数据库的命令保存下来。

基本原理

每一次发生更新命令时,redis会把命令放到aof_buf中,每次在执行完成命令之后,会判断是否达到备份条件,如果达到就把aof_buf中的数据保存到AOF文件中。

AOP配置

appendfsync always         //每次执行完成更新命令,都会被命令写到AOF文件中
appendfsync everysec     //每秒一次,把aof_buf中的命令写道AOF文件中
appendfsync no               //由redis执行决定何时同步

AOF的载入还原

如果Redis服务器同时配置了RDB和AOF两种持久化策略,会优先使用AOF进行数据恢复。使用AOF文件进行数据恢复的方式与RDB不同,开始备份时,会创建一个不带网络连接的伪客户端,该客户端来读取AOF中的命令,并一条一条的发送给Redis服务器进行执行。

AOF重写

随着服务器的运行,AOF文件会越来越大,这个时候Redis会对AOF进行重写。进行重写并不是像字面上的意思那样,对AOF文件进行解析重写,Redis在进行AOF重写时,实际上是把数据库中的每一个键值对进行分析,分析成为Redis命令写到新的AOF文件中,完成之后再用新的AOF文件替换旧的AOF文件。

后台AOF

Redis进行AOF的时候,其实也是在后台开启了一个子进程进行AOF的备份,此时在子进程进行AOF备份时,主进程同样可以处理其他命令,这样就会出现在这期间新发生的更新操作没办法记录到AOF的情况,导致数据不一致的情况。为了解决这个问题,在发生AOF重写时,主进程在处理更新请求时,不仅会把命令写道aof_buf中,同时会写到AOF重写缓冲区中。当子进程完成AOF重写时,会发送一个信号给主进程,主进程触发信号处理函数,将AOF重写缓冲区中的所有内容写到新的AOF文件中。在信号处理函数执行期间,主进程会阻塞,不在处理其他命令。
无论时RDB备份还是AOF重写都是在后台fork出一个子进程来完成具体操作,这样的好处是,子进程使用的是主进程的数据副本,不会影响主进程的正常使用,需要注意AOF重写时数据一致性的问题。

上一篇:pytest+Allure生成测试报告


下一篇:Redis的各种用途以及使用场景