溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

玩轉(zhuǎn)redis持久化,阿里架構(gòu)師給你來一篇方案介紹

發(fā)布時間:2020-07-10 16:28:37 來源:網(wǎng)絡(luò) 閱讀:296 作者:愛碼仕i 欄目:編程語言

玩轉(zhuǎn)redis持久化,阿里架構(gòu)師給你來一篇方案介紹

一、基本介紹

本次演示使用的redis版本是3.2.100,操作系統(tǒng)是win10。

redis支持兩種持久化方案,RDB和AOF,前者是默認打開的,后者需要手動開啟。我們通過配置文件可以驗證這一點,

RDB默認開啟

save 900 1
save 300 10
save 60 10000

這三條配置是RDS觸發(fā)快照的條件,它們的意思分別是:

  1. 900秒內(nèi)如果有一條寫入,則產(chǎn)生快照
  2. 300秒內(nèi)如果有1000次寫入,則產(chǎn)生快照
  3. 60秒內(nèi)如果有10000次寫入,則產(chǎn)生快照

當(dāng)然,觸發(fā)rdb快照的條件不止這些,下面會講到。

AOF默認關(guān)閉

appendonly no

二、RDB介紹

RDB的方案是當(dāng)滿足觸發(fā)條件是,將內(nèi)存中的數(shù)據(jù)以二進制的方式寫入磁盤保存,默認保存的文件叫dump.rdb(可以改),當(dāng)redis重啟時,會讀取該文件進行數(shù)據(jù)恢復(fù)。

查看快照文件的信息

127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"
127.0.0.1:6379> config get dir
1) "dir"
2) "C:\\redis-6379"
127.0.0.1:6379>

觸發(fā)RDB快照條件

除了上面提到的在指定時間內(nèi),指定寫次數(shù)觸發(fā)之外,下面幾種情況也會觸發(fā)redis執(zhí)行RDB快照,

  1. 手動執(zhí)行save(同步阻塞)或者bgsave(異步阻塞)命令
  2. 執(zhí)行flushall命令
  3. redis退出,執(zhí)行shutdown命令

下面拿第一種情況演示下,這里會用到info Persistence命令,用來查看持久化信息。

127.0.0.1:6379> info persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1561595205
...省略其它
127.0.0.1:6379> save
OK
127.0.0.1:6379> info persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1561595940
...省略其它
127.0.0.1:6379>

注意看rdb_last_save_time字段,說明save命令觸發(fā)了持久化。

三、AOF介紹

為了演示AOF,我們需要手動把AOF開關(guān)打開,然后重啟redis。

AOF將Redis執(zhí)行的每一條寫命令追加到磁盤文件(appendonly.aof)中,如果打開了AOF,redis啟動時候優(yōu)先選擇從AOF文件恢復(fù)數(shù)據(jù)。

相關(guān)配置

除了開關(guān),和AOF相關(guān)的配置還有以下幾個:

appendfilename "appendonly.aof"   #數(shù)據(jù)庫文件名
# appendfsync always    #每個命令都追加寫入
appendfsync everysec    #每秒寫1次
# appendfsync no        #寫入工作交給操作系統(tǒng),由操作系統(tǒng)判斷緩沖區(qū)大小,統(tǒng)一寫入到aof

no-appendfsync-on-rewrite  yes:   #正在導(dǎo)出rdb快照的過程中,是否停止同步aof
auto-aof-rewrite-percentage 100   #aof文件大小比起上次重寫時的大小,增長率100%時,重寫
auto-aof-rewrite-min-size 64mb    #aof文件,至少超過64M時,才重寫

重寫機制

通過前面講述的AOF的過程,聰明的你可能會想到一個問題,AOF不斷的追加命令到文件,那文件豈不是越來越大,時間長了對磁盤空間也是負擔(dān)啊。

你都想到了,redis的作者會想不到嗎?redis引入了重寫機制來解決這個問題。上面配置的最后兩條其實就是重寫的觸發(fā)條件,說白了意思就是:

當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)

除了上面的條件觸發(fā),AOF也支持手動觸發(fā)(bgrewriteaof命令)下面用這個命令演示重寫

λ redis-cli.exe
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
127.0.0.1:6379>

啟動日志:

[18268] 27 Jun 09:23:41.282 # Server started, Redis version 3.2.100
[18268] 27 Jun 09:23:41.282 * The server is now ready to accept connections on port 6379
[18268] 27 Jun 09:24:03.236 * Background append only file rewriting started by pid 18740
[18268] 27 Jun 09:24:03.388 * AOF rewrite child asks to stop sending diffs.
[18268] 27 Jun 09:24:03.488 # fork operation complete
[18268] 27 Jun 09:24:03.489 * Background AOF rewrite terminated with success
[18268] 27 Jun 09:24:03.491 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
[18268] 27 Jun 09:24:03.496 * Background AOF rewrite finished successfully

四、總結(jié)

  1. 如果使用持久化,建議RDB和AOF都開啟,雙重保障。AOF會優(yōu)先執(zhí)行,如果執(zhí)行失敗還有RDB
  2. RDB適合大規(guī)模數(shù)據(jù)恢復(fù),但是完整性不如AOF,因為RDB可能在最后一次備份時宕機了
  3. RDB相對AOF比較占用內(nèi)存

寫在最后

玩轉(zhuǎn)redis持久化,阿里架構(gòu)師給你來一篇方案介紹

向AI問一下細節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI