概述

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

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

• 會對數(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ù)生成快照保存到磁盤上的過程，由于是某一時刻的快照，那么快照中的值要早于或者等于內(nèi)存中的值

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

觸發(fā)方式

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

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

手動觸發(fā)

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

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

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

自動觸發(fā)

自動觸發(fā)：以下4種情況時會自動觸發(fā)

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

save <seconds> <changes>

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

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

AOF（Append-Only File）

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

核心原理

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

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

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

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

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

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

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

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

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

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

AOF重寫

基本概念

AOF會記錄每個寫命令到AOF文件，隨著時間越來越長，AOF文件會變得越來越大。

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

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

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

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

觸發(fā)方式

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

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

重寫過程

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

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

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

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

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

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

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

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

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

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

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

RDB vs AOF

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

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

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

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

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

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

例如：

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

總結(jié)

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

最新評論