Redis持久化详解(RDB&AOF)

Redis 对外提供数据访问服务时,使用的是常驻内存的数据。为了在Redis Server重启之后数据还可以得到恢复,Redis具备将数据持久化到硬盘中的能力。

全量模式的持久化(RDB)

Redis Server在多有db 中存储的key-value可以理解为Redis的一个状态。当发生写操作时,Redis就会从一个状态切换到另外一个状态。基于全量的持久化就是在某个时刻,将Redis的所有数据持久化到硬盘中,形成一个快照。当Redis 重启时,通过加载最近一个快照数据,可以将Redis 恢复至最近一次持久化状态上。

1、写入流程

Redis的全量写入包含2种方式:save 和 bgsave,两者的处理逻辑如下:

save 可以由客户端显示触发的,也可以在redis shutdown 时触发。Save本身是单线程串行化的方式执行的,因此当数据量大时,有肯能会发生Redis Server的长时间卡顿。但是其备份期间不会有其他命令执行,因此备份在这一时刻是一致性的。

bgsave 也可以由客户端显示触发、可以通过配置定时任务触发也可以在master-slave的分布式结构下由slave节点触发。bgsave命令在执行的时候,会fork一个子进程。子进程提交完成之后,会立即给客户端返回响应,备份操作在后台异步执行,在此期间不会影响Redis的正常响应。

image

​​​​​​​

对于bgsave来说,当父进程Fork完子进程之后,异步任务会将当前的内存状态作为一个版本进行复制。在复制过程中产生的变更,不会反映在这次备份当中。在Redis的默认配置当中,当满足下面任一条件时,会自动触发bgsave 的执行。

<caption style="box-sizing: border-box; padding-top: 8px; padding-bottom: 8px; color: rgb(119, 119, 119); text-align: left;">自动触发bgsave 条件</caption>

配置

seconds

changes

save

900

1

save

300

10

save

60

10000

bgsave相对于Save来说,其优势是异步执行,不影响后续的命令执行。但是Fork子进程时,涉及父进程的内存复制,此时会增加服务器的内存开销。当内存开销高到使用虚拟内存时,bgsave的Fork子进程会阻塞运行,可能会造成秒级的不可用。因此使用bgsave需要保证服务器空闲内存足够。

<caption style="box-sizing: border-box; padding-top: 8px; padding-bottom: 8px; color: rgb(119, 119, 119); text-align: left;">save和bgsave对比</caption>

命令

save

bgsave

IO类型

同步

异步

是否阻塞

阻塞

非阻塞(在fork是阻塞)

复杂度

O(n)

O(n)

优点

不会消耗额外内存

不阻塞客户端命令

缺点

阻塞客户端命令

需要Fork子进程,内存开销大

2、恢复流程

当Redis重新启动时,会从本地磁盘加载之前持久化的文件。当恢复完成之后,再受理后续的请求操作。

增量模式的持久化(AOF)

RDB记录的是每个状态的全量数据,而AOF(append-only-file)记录的则是每条写命令的记录,通过所有写命令的执行,最后恢复出最终的数据状态。其文件的生成如下所示:

image

1、写入流程

Redis的AOF 包含3 种同步策略:

always:每一次的刷新缓冲区,都会同步触发同步操作。因为每次的写操作都会触发同步,所以该策略会降低Redis的吞吐量,但是这种模式会拥有最高的容错能力。

every second:每秒异步的触发同步操作,这种是Redis的默认配置。

no:由操作系统决定何时同步,这种方式Redis无法决定何时落地,因此不可控。

image

<caption style="box-sizing: border-box; padding-top: 8px; padding-bottom: 8px; color: rgb(119, 119, 119); text-align: left;">always/everysec/no对比</caption>

命令

always

everysec

no

优点

不丢失数据

每秒1次fsync,丢1秒数据

无需设置

缺点

IO开销大,一般的STAT盘只有几百TPS

丢1秒数据

不可控

2、回放流程

AOF的回放时机也是在机器启动时,一旦存在AOF,Redis会选择增量回放。因为增量的持久化持续的写入磁盘,相比全量持久化,数据更加完整。回放的过程就是将AOF中存放的命令,重新执行一遍。完成之后再继续接受客户端的新命令。

AOF模式的优化重写

随着Redis 持续的运行,会有大量的增量数据append 到AOF 文件中。为了减小硬盘存储和加快恢复速度,Redis 通过rewrite 机制合并历史AOF 记录。如下所示:

image

整个流程描述如下:

历史AOF:以快照的方式保存。

快照写入期间的增量:待快照写入完成之后append 到快照文件中。

后续的增量:写入新的AOF。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏解Bug之路

解Bug之路-串包Bug

笔者很热衷于解决Bug,同时比较擅长(网络/协议)部分,所以经常被唤去解决一些网络IO方面的Bug。现在就挑一个案例出来,写出分析思路,以飨读者,希望读者在以后...

11310
来自专栏码洞

求不更学不动之Redis5.0新特性Stream尝鲜

Redis5.0最近被作者突然放出来了,增加了很多新的特色功能。而Redis5.0最大的新特性就是多出了一个数据结构Stream,它是一个新的强大的支持多播的可...

20460
来自专栏吴伟祥

Redis实现消息队列 转

打开浏览器,输入地址,按下回车,打开了页面。于是一个HTTP请求(request)就由客户端发送到服务器,服务器处理请求,返回响应(response)内容。

36110
来自专栏养码场

一周播报|程序员竟说自己就是搬砖工人?原因居然是......

问题2/ 来自养码人D的问题:有人做过DDD的充血模型实践吗?有没有什么比较好的方案能让充血模型和spring ioc集成起来?

8120
来自专栏养码场

一周播报|正逃离北上广深的程序员,杭州是远方还是前方?

2号养码人:redis里面指令是串行的吧,单key和多个key是一样的。如果是不同key,可以用做集群。

7710
来自专栏养码场

一周播报|程序猿到了35岁,就真的碰到职场天花板了吗?

面试官心态其实就是相亲心态,看上了你能写出hell word就可以,看不上的你写出一整套jvm算法也没用。

11020
来自专栏吴伟祥

超强、超详细Redis入门教程 转

1.redis是什么 2.redis的作者何许人也 3.谁在使用redis 4.学会安装redis 5.学会启动redis 6.使用redis客户端 ...

15840
来自专栏码洞

深入理解 RPC 消息协议设计

本节我们开始讲解 RPC 的消息协议设计背后的基本原理,了解 RPC 的协议开发背后有哪些需要考虑的基本点。在通晓原理之后,我们就可以自己设计一套协议来开发属于...

17130
来自专栏华章科技

大数据产业链之路还有多远?

随着大数据炒作期的结束,国内外大量企业开始投入大数据实战,大数据生态产业链逐渐形成。整体而言,全球的大数据应用处于发展初期,中国大数据应用才刚刚起步。目前,大数...

72720
来自专栏KaliArch

记一次混合监控的反思

作为最底层的技术人员,目前由于有客户在运维中遇到混合架构,公有云上使用了产品级别Redis数据库,同时由于业务在云服务器和kubnets的容器内也有redis数...

19150

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励