redis快照模式_動力節(jié)點Java學院整理
我們知道redis是帶有持久化這個能力了,那到底持久化成到哪里,持久化成啥樣呢???這篇我們一起來尋求答案。
一、快照模式
或許在用Redis之初的時候,就聽說過redis有兩種持久化模式,第一種是SNAPSHOTTING模式,還是一種是AOF模式,而且在實戰(zhàn)場景下用的最多的莫過于SNAPSHOTTING模式,這個不需要反駁吧,而且你可能還知道,使用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,那么也會執(zhí)行save操作,就這么簡單,看了我剛才說了這么幾句話,是不是有種直覺在
告訴你,有兩個問題是不是要澄清一下:
1. 上面這個操作應(yīng)該是redis自身進行的同步操作,請問是否可以手工執(zhí)行save呢?
當然可以進行手工操作,redis提供了兩個操作命令:save,bgsave,這兩個命令都會強制將數(shù)據(jù)刷新到硬盤中,如下圖:

2. 看上面的圖,貌似bgsave是開啟單獨線程的,請問是嗎?
確實如你所說,bgsave是開啟次線程進行數(shù)據(jù)刷新的,不信的話我們來看看代碼,它的代碼是在rdb.c源文件中,如下:

從上面的代碼中,有沒有看到一個重點,那就是fork方法,它就是一些牛人口中說的什么fork出一個線程,今天你也算終于看到了,其實redis并不是單純的單線程服務(wù),至少fork告訴我們,它在一些場景下也是會開啟工作線程的,然后可以看到代碼會在工作線程中執(zhí)行同步的bgsave操作,就這么簡單。
3. 能簡單說下saveparams參數(shù)在redis源碼中的邏輯嗎?
可以的,其實在redis中有一個周期性函數(shù),叫做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) {
上面的紅色字體就是做了我們所關(guān)心的save操作,看過方法的注釋,接下來我們來找一下具體邏輯。

從上面這段代碼邏輯,你應(yīng)該可以發(fā)現(xiàn)以下幾點:
<1>.saveparams參數(shù)是在server對象下面,而server對象正好是redisServer類型,如下圖:

從上面圖中 *saveparams 的注釋上來看,你應(yīng)該知道*saveparams是saveparam類型的數(shù)組,那現(xiàn)在是不是有強烈的好奇心想看一下saveparam
類型是怎么定義的的呢??? 如下圖:

可以看到,saveparam參數(shù)里面有兩個參數(shù),seconds就是保存秒數(shù),changes就是改變量,而這二個參數(shù)就對應(yīng)著我們配置文件中的900 0 這樣的配置。
<2> 然后我們通過if發(fā)現(xiàn),如果終滿足,就會最終調(diào)用rdbSaveBackground來持久化我們的rdb文件。
以上就是本文的全部內(nèi)容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
相關(guān)文章
Redis實現(xiàn)排行榜及相同積分按時間排序功能的實現(xiàn)
這篇文章主要介紹了Redis實現(xiàn)排行榜及相同積分按時間排序,本文通過實例代碼給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-08-08
分布式鎖為什么要選擇Zookeeper而不是Redis?看完這篇你就明白了
Zookeeper的機制可以保證分布式鎖實現(xiàn)業(yè)務(wù)代碼簡單,成本低,Redis如果要解決分布式鎖的問題,對于一些復(fù)雜的情況,很難解決,成本較高,這篇文章重點給大家介紹分布式鎖選擇Zookeeper 而不是Redis的理由,一起看看吧2021-05-05

