登录
首页 >  数据库 >  Redis

redis快照模式_动力节点Java学院整理

来源:脚本之家

时间:2023-01-01 14:44:41 231浏览 收藏

在数据库实战开发的过程中,我们经常会遇到一些这样那样的问题,然后要卡好半天,等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《redis快照模式_动力节点Java学院整理》,聊聊redis快照模式,希望可以帮助到正在努力赚钱的你。

我们知道redis是带有持久化这个能力了,那到底持久化成到哪里,持久化成啥样呢???这篇我们一起来寻求答案。

一、快照模式

  或许在用Redis之初的时候,就听说过redis有两种持久化模式,第一种是SNAPSHOTTING模式,还是一种是AOF模式,而且在实战场景下用的最多的莫过于SNAPSHOTTING模式,这个不需要反驳吧,而且你可能还知道,使用SNAPSHOTTING模式,需要在redis.conf中设置配置参数,比如下面这样:

# Save the DB on disk:
#
# save 
#
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
#
# Note: you can disable saving completely by commenting out all "save" lines.
#
# It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
#
# save ""

save 900 1
save 300 10
save 60 10000

上面三组命令也是非常好理解的,就是说900指的是“秒数”,1指的是“change次数”,接下来如果在“900s“内有1次更改,那么就执行save保存,同样的道理,如果300s内有10次change,60s内有1w次change,那么也会执行save操作,就这么简单,看了我刚才说了这么几句话,是不是有种直觉在

告诉你,有两个问题是不是要澄清一下:

1. 上面这个操作应该是redis自身进行的同步操作,请问是否可以手工执行save呢? 

当然可以进行手工操作,redis提供了两个操作命令:save,bgsave,这两个命令都会强制将数据刷新到硬盘中,如下图:

2. 看上面的图,貌似bgsave是开启单独线程的,请问是吗?

确实如你所说,bgsave是开启次线程进行数据刷新的,不信的话我们来看看代码,它的代码是在rdb.c源文件中,如下:

从上面的代码中,有没有看到一个重点,那就是fork方法,它就是一些牛人口中说的什么fork出一个线程,今天你也算终于看到了,其实redis并不是单纯的单线程服务,至少fork告诉我们,它在一些场景下也是会开启工作线程的,然后可以看到代码会在工作线程中执行同步的bgsave操作,就这么简单。

3. 能简单说下saveparams参数在redis源码中的逻辑吗?

可以的,其实在redis中有一个周期性函数,叫做serverCron,它会周期性启动,大概会做七件事情,如redis注释所说:

/* This is our timer interrupt, called server.hz times per second.
 * Here is where we do a number of things that need to be done asynchronously.
 * For instance:
 *
 * - Active expired keys collection (it is also performed in a lazy way on
 * lookup).
 * - Software watchdog.
 * - Update some statistic.
 * - Incremental rehashing of the DBs hash tables.
 * - Triggering BGSAVE / AOF rewrite, and handling of terminated children.
 * - Clients timeout of different kinds.
 * - Replication reconnection.
 * - Many more...
 *
 * Everything directly called here will be called server.hz times per second,
 * so in order to throttle execution of things we want to do less frequently
 * a macro is used: run_with_period(milliseconds) { .... }
 */

int serverCron(struct aeEventLoop *eventLoop, long long id, void *clientData) {

上面的红色字体就是做了我们所关心的save操作,看过方法的注释,接下来我们来找一下具体逻辑。

从上面这段代码逻辑,你应该可以发现以下几点:

.saveparams参数是在server对象下面,而server对象正好是redisServer类型,如下图:

从上面图中 *saveparams 的注释上来看,你应该知道*saveparams是saveparam类型的数组,那现在是不是有强烈的好奇心想看一下saveparam

类型是怎么定义的的呢??? 如下图:

可以看到,saveparam参数里面有两个参数,seconds就是保存秒数,changes就是改变量,而这二个参数就对应着我们配置文件中的900 0 这样的配置。

然后我们通过if发现,如果终满足,就会最终调用rdbSaveBackground来持久化我们的rdb文件。

理论要掌握,实操不能落!以上关于《redis快照模式_动力节点Java学院整理》的详细介绍,大家都掌握了吧!如果想要继续提升自己的能力,那么就来关注golang学习网公众号吧!

声明:本文转载于:脚本之家 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表