概述

Redis 提供 RDB 和 AOF 兩種持久化機(jī)制，它們?cè)跀?shù)據(jù)安全性、性能、恢復(fù)速度等方面有顯著差異。

為什么要進(jìn)行持久化？如果是大數(shù)據(jù)量的恢復(fù)，會(huì)有下述的影響

• 會(huì)對(duì)數(shù)據(jù)庫帶來巨大的壓力，
• 數(shù)據(jù)庫的性能不如Redis。導(dǎo)致程序響應(yīng)慢
• 實(shí)現(xiàn)數(shù)據(jù)的持久化，避免從后端數(shù)據(jù)庫中恢復(fù)數(shù)據(jù)

RDB（Redis Database）

核心原理

RDB持久化是把當(dāng)前進(jìn)程數(shù)據(jù)生成快照保存到磁盤上的過程，由于是某一時(shí)刻的快照，那么快照中的值要早于或者等于內(nèi)存中的值

RDB文件默認(rèn)為當(dāng)前工作目錄下的dump.rdb，可以根據(jù)配置文件中的dbfilename和dir設(shè)置RDB的文件名和文件位置

觸發(fā)方式

有下述兩種觸發(fā)方式

• 手動(dòng)觸發(fā)：分別對(duì)應(yīng)save和bgsave命令
• 自動(dòng)觸發(fā)：以下4種情況時(shí)會(huì)自動(dòng)觸發(fā)

手動(dòng)觸發(fā)

• 手動(dòng)觸發(fā)：分別對(duì)應(yīng)save和bgsave命令
• save命令：阻塞當(dāng)前Redis服務(wù)器，直到RDB過程完成為止，對(duì)于內(nèi)存 比較大的實(shí)例會(huì)造成長(zhǎng)時(shí)間阻塞，線上環(huán)境不建議使用
• bgsave命令：Redis進(jìn)程執(zhí)行fork操作創(chuàng)建子進(jìn)程，RDB持久化過程由子 進(jìn)程負(fù)責(zé)，完成后自動(dòng)結(jié)束。阻塞只發(fā)生在fork階段，一般時(shí)間很短

fork()是由操作系統(tǒng)提供的函數(shù)，作用是創(chuàng)建當(dāng)前進(jìn)程的一個(gè)副本作為子進(jìn)程

fork一個(gè)子進(jìn)程，子進(jìn)程會(huì)把數(shù)據(jù)集先寫入臨時(shí)文件，寫入成功之后，再替換之前的RDB文件，用二進(jìn)制壓縮存儲(chǔ)，這樣可以保證RDB文件始終存儲(chǔ)的是完整的持久化內(nèi)容

自動(dòng)觸發(fā)

自動(dòng)觸發(fā)：以下4種情況時(shí)會(huì)自動(dòng)觸發(fā)

redis.conf中配置save m n，即在m秒內(nèi)有n次修改時(shí)，自動(dòng)觸發(fā)bgsave生成rdb文件；

save <seconds> <changes>

表示在seconds秒內(nèi)，至少有changes次變化，就會(huì)自動(dòng)觸發(fā)gbsave命令

• 主從復(fù)制時(shí)，從節(jié)點(diǎn)要從主節(jié)點(diǎn)進(jìn)行全量復(fù)制時(shí)也會(huì)觸發(fā)bgsave操作，生成當(dāng)時(shí)的快照發(fā)送到從節(jié)點(diǎn)
• 執(zhí)行debug reload命令重新加載redis時(shí)也會(huì)觸發(fā)bgsave操作；
• 默認(rèn)情況下執(zhí)行shutdown命令時(shí)，如果沒有開啟aof持久化，那么也會(huì)觸發(fā)bgsave操作；

AOF（Append-Only File）

針對(duì)RDB不適合實(shí)時(shí)持久化的問題，Redis提供了AOF持久化方式來解決.

核心原理

AOF日志采用寫后日志，即先寫內(nèi)存，后寫日志

• AOF持久化會(huì)把被執(zhí)行的寫命令寫到AOF文件的末尾，記錄數(shù)據(jù)的變化。
• 默認(rèn)情況下，Redis是沒有開啟AOF持久化的，
• 開啟后，每執(zhí)行一條更改Redis數(shù)據(jù)的命令，都會(huì)把該命令追加到AOF文件中，這是會(huì)降低Redis的性能，但大部分情況下這個(gè)影響是能夠接受的，
• 另外使用較快的硬盤可以提高AOF的性能

配置方式

通過配置redis.conf文件開啟AOF持久化

# appendonly參數(shù)開啟AOF持久化
appendonly no

# AOF持久化的文件名，默認(rèn)是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通過dir參數(shù)設(shè)置的
dir ./

# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

# aof重寫期間是否同步
no-appendfsync-on-rewrite no

# 重寫觸發(fā)配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加載aof出錯(cuò)如何處理
aof-load-truncated yes

# 文件重寫策略
aof-rewrite-incremental-fsync yes

AOF實(shí)現(xiàn)步驟

AOF需要記錄Redis的每個(gè)寫命令，步驟為：

• 命令追加（append）：?jiǎn)OF持久化功能后，服務(wù)器每執(zhí)行一個(gè)寫命令，都會(huì)把該命令以協(xié)議格式先追加到aof_buf緩存區(qū)的末尾

不是直接寫入文件，避免每次有命令都直接寫入硬盤，減少硬盤IO次數(shù)

文件寫入（write），文件同步（sync）：何時(shí)把a(bǔ)of_buf緩沖區(qū)的內(nèi)容寫入保存在AOF文件中，Redis提供了多種策略，appendfsync選項(xiàng)的默認(rèn)配置為everysec，即每秒執(zhí)行一次同步

• appendfsync always：將aof_buf緩沖區(qū)的所有內(nèi)容寫入并同步到AOF文件，每個(gè)寫命令同步寫入磁盤
• appendfsync everysec：將aof_buf緩存區(qū)的內(nèi)容寫入AOF文件，每秒同步一次，該操作由一個(gè)線程專門負(fù)責(zé)
• appendfsync no：將aof_buf緩存區(qū)的內(nèi)容寫入AOF文件，什么時(shí)候同步由操作系統(tǒng)來決定

AOF的同步策略是涉及到操作系統(tǒng)的write函數(shù)和fsync函數(shù)的

AOF重寫

基本概念

AOF會(huì)記錄每個(gè)寫命令到AOF文件，隨著時(shí)間越來越長(zhǎng)，AOF文件會(huì)變得越來越大。

為了解決AOF文件體積膨脹的問題，Redis提供AOF文件重寫機(jī)制來對(duì)AOF文件進(jìn)行“瘦身”。

AOF重寫的目的就是減小AOF文件的體積

Redis通過創(chuàng)建一個(gè)新的AOF文件來替換現(xiàn)有的AOF，新舊兩個(gè)AOF文件保存的數(shù)據(jù)相同，但新AOF文件沒有了冗余命令

• 時(shí)間長(zhǎng)了，AOF文件中通常會(huì)有一些冗余命令，
• 比如：過期數(shù)據(jù)的命令、無效的命令（重復(fù)設(shè)置、刪除）、多個(gè)命令可合并為一個(gè)命令（批處理命令）。
• 所以AOF文件是有精簡(jiǎn)壓縮的空間的

觸發(fā)方式

文件重寫可分為手動(dòng)觸發(fā)和自動(dòng)觸發(fā)，

• 手動(dòng)觸發(fā)執(zhí)行bgrewriteaof命令，該命令的執(zhí)行跟bgsave觸發(fā)快照時(shí)類似的，都是先fork一個(gè)子進(jìn)程做具體的工作
• 自動(dòng)觸發(fā)會(huì)根據(jù)auto-aof-rewrite-percentage和auto-aof-rewrite-min-size 64mb配置來自動(dòng)執(zhí)行bgrewriteaof命令

重寫過程

AOF重寫過程是由后臺(tái)進(jìn)程bgrewriteaof來完成的。

• 主線程fork出后臺(tái)的bgrewriteaof子進(jìn)程，fork會(huì)把主線程的內(nèi)存拷貝一份給bgrewriteaof子進(jìn)程，這里面就包含了數(shù)據(jù)庫的最新數(shù)據(jù)。
• 然后，bgrewriteaof子進(jìn)程就可以在不影響主線程的情況下，逐一把拷貝的數(shù)據(jù)寫成操作，記入重寫日志。
• 所以aof在重寫時(shí)，在fork進(jìn)程時(shí)是會(huì)阻塞住主線程的

重寫過程總結(jié)為：“一個(gè)拷貝，兩處日志”。在fork出子進(jìn)程時(shí)的拷貝，以及在重寫時(shí)，如果有新數(shù)據(jù)寫入，主線程就會(huì)將命令記錄到兩個(gè)aof日志內(nèi)存緩沖區(qū)中。

• 而在bgrewriteaof子進(jìn)程完成會(huì)日志文件的重寫操作后，會(huì)提示主線程已經(jīng)完成重寫操作，主線程會(huì)將AOF重寫緩沖中的命令追加到新的日志文件后面
• 這時(shí)候在高并發(fā)的情況下，AOF重寫緩沖區(qū)積累可能會(huì)很大，這樣就會(huì)造成阻塞，Redis后來通過Linux管道技術(shù)讓aof重寫期間就能同時(shí)進(jìn)行回放，這樣aof重寫結(jié)束后只需回放少量剩余的數(shù)據(jù)即可
• 最后通過修改文件名的方式，保證文件切換的原子性
• 在AOF重寫日志期間發(fā)生宕機(jī)的話，因?yàn)槿罩疚募€沒切換，所以恢復(fù)數(shù)據(jù)時(shí)，用的還是舊的日志文件

重寫過程中主線程有哪些地方會(huì)被阻塞？

fork子進(jìn)程時(shí)，需要拷貝虛擬頁表，會(huì)對(duì)主線程阻塞。

主進(jìn)程有bigkey寫入時(shí)，操作系統(tǒng)會(huì)創(chuàng)建頁面的副本，并拷貝原有的數(shù)據(jù)，會(huì)對(duì)主線程阻塞。

子進(jìn)程重寫日志完成后，主進(jìn)程追加aof重寫緩沖區(qū)時(shí)會(huì)對(duì)主線程阻塞

為什么不復(fù)用原AOF日志

子進(jìn)程寫同一個(gè)文件會(huì)產(chǎn)生競(jìng)爭(zhēng)問題，影響父進(jìn)程的性能。

如果AOF重寫過程中失敗了，相當(dāng)于污染了原本的AOF文件，無法做恢復(fù)數(shù)據(jù)使用

RDB vs AOF

Redis 4.0 中提出了一個(gè)混合使用 AOF 日志和內(nèi)存快照的方法。簡(jiǎn)單來說，內(nèi)存快照以一定的頻率執(zhí)行，在兩次快照之間，使用 AOF 日志記錄這期間的所有命令操作

AOF 日志也只用記錄兩次快照間的操作，也就是說，不需要記錄所有操作了，因此，就不會(huì)出現(xiàn)文件過大的情況了，也可以避免重寫開銷

這個(gè)方法既能享受到 RDB 文件快速恢復(fù)的好處，又能享受到 AOF 只記錄操作命令的簡(jiǎn)單優(yōu)勢(shì), 實(shí)際環(huán)境中用的很

如何保證數(shù)據(jù)一致性

RDB中的核心思路是Copy-on-Write，來保證在進(jìn)行快照操作的這段時(shí)間，需要壓縮寫入磁盤上的數(shù)據(jù)在內(nèi)存中不會(huì)發(fā)生變化。

• 一方面Redis主進(jìn)程會(huì)fork一個(gè)新的快照進(jìn)程專門來做這個(gè)事情，這樣保證了Redis服務(wù)不會(huì)停止對(duì)客戶端包括寫請(qǐng)求在內(nèi)的任何響應(yīng)。
• 另一方面這段時(shí)間發(fā)生的數(shù)據(jù)變化會(huì)以副本的方式存放在另一個(gè)新的內(nèi)存區(qū)域，待快照操作結(jié)束后才會(huì)同步到原來的內(nèi)存區(qū)域

例如：

• 如果主線程要修改一塊數(shù)據(jù)（例如圖中的鍵值對(duì) C），那么，這塊數(shù)據(jù)就會(huì)被復(fù)制一份，生成該數(shù)據(jù)的副本。
• 然后，bgsave 子進(jìn)程會(huì)把這個(gè)副本數(shù)據(jù)寫入 RDB 文件，
• 而在這個(gè)過程中，主線程仍然可以直接修改原來的數(shù)據(jù)。

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論