redis快照模式_動(dòng)力節(jié)點(diǎn)Java學(xué)院整理

我們知道redis是帶有持久化這個(gè)能力了，那到底持久化成到哪里，持久化成啥樣呢？？？這篇我們一起來尋求答案。

一、快照模式

　　或許在用Redis之初的時(shí)候，就聽說過redis有兩種持久化模式，第一種是SNAPSHOTTING模式，還是一種是AOF模式，而且在實(shí)戰(zhàn)場(chǎng)景下用的最多的莫過于SNAPSHOTTING模式，這個(gè)不需要反駁吧，而且你可能還知道，使用SNAPSHOTTING模式，需要在redis.conf中設(shè)置配置參數(shù)，比如下面這樣：

# Save the DB on disk:
#
# save seconds> changes>
#
# 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指的是“秒數(shù)”，1指的是“change次數(shù)”，接下來如果在“900s“內(nèi)有1次更改，那么就執(zhí)行save保存，同樣的道理，如果300s內(nèi)有10次change，60s內(nèi)有1w次change，那么也會(huì)執(zhí)行save操作，就這么簡(jiǎn)單，看了我剛才說了這么幾句話，是不是有種直覺在

告訴你，有兩個(gè)問題是不是要澄清一下：

1. 上面這個(gè)操作應(yīng)該是redis自身進(jìn)行的同步操作，請(qǐng)問是否可以手工執(zhí)行save呢？　

當(dāng)然可以進(jìn)行手工操作，redis提供了兩個(gè)操作命令：save，bgsave，這兩個(gè)命令都會(huì)強(qiáng)制將數(shù)據(jù)刷新到硬盤中，如下圖：

2. 看上面的圖，貌似bgsave是開啟單獨(dú)線程的，請(qǐng)問是嗎？

確實(shí)如你所說，bgsave是開啟次線程進(jìn)行數(shù)據(jù)刷新的，不信的話我們來看看代碼，它的代碼是在rdb.c源文件中，如下：

從上面的代碼中，有沒有看到一個(gè)重點(diǎn)，那就是fork方法，它就是一些牛人口中說的什么fork出一個(gè)線程，今天你也算終于看到了，其實(shí)redis并不是單純的單線程服務(wù)，至少fork告訴我們，它在一些場(chǎng)景下也是會(huì)開啟工作線程的，然后可以看到代碼會(huì)在工作線程中執(zhí)行同步的bgsave操作，就這么簡(jiǎn)單。

3. 能簡(jiǎn)單說下saveparams參數(shù)在redis源碼中的邏輯嗎？

可以的，其實(shí)在redis中有一個(gè)周期性函數(shù)，叫做serverCron，它會(huì)周期性啟動(dòng)，大概會(huì)做七件事情，如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) {

上面的紅色字體就是做了我們所關(guān)心的save操作，看過方法的注釋，接下來我們來找一下具體邏輯。

從上面這段代碼邏輯，你應(yīng)該可以發(fā)現(xiàn)以下幾點(diǎn)：

1>.saveparams參數(shù)是在server對(duì)象下面，而server對(duì)象正好是redisServer類型，如下圖：

從上面圖中 *saveparams 的注釋上來看，你應(yīng)該知道*saveparams是saveparam類型的數(shù)組，那現(xiàn)在是不是有強(qiáng)烈的好奇心想看一下saveparam

類型是怎么定義的的呢？？？ 如下圖：

可以看到，saveparam參數(shù)里面有兩個(gè)參數(shù)，seconds就是保存秒數(shù)，changes就是改變量，而這二個(gè)參數(shù)就對(duì)應(yīng)著我們配置文件中的900 0 這樣的配置。

2> 然后我們通過if發(fā)現(xiàn)，如果終滿足，就會(huì)最終調(diào)用rdbSaveBackground來持久化我們的rdb文件。

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。