Redis持久化策略是什么

144次閱讀

共計(jì) 7245 個(gè)字符，預(yù)計(jì)需要花費(fèi) 19 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“Redis 持久化策略是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

Redis（Remote Dictionary Server )，即遠(yuǎn)程字典服務(wù)，是一個(gè)開(kāi)源的內(nèi)存高速緩存數(shù)據(jù)存儲(chǔ)服務(wù)。使用 ANSI C 語(yǔ)言編寫(xiě)，支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value 數(shù)據(jù)存儲(chǔ)，并提供多種語(yǔ)言的 API

Redis 是內(nèi)存數(shù)據(jù)庫(kù)，數(shù)據(jù)都是存儲(chǔ)在內(nèi)存中，為了避免進(jìn)程退出導(dǎo)致數(shù)據(jù)的永久丟失，需要定期將 Redis 中的數(shù)據(jù)以某種形式（數(shù)據(jù)或命令）從內(nèi)存保存到硬盤(pán)。當(dāng)下次 Redis 重啟時(shí)，利用持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)。除此之外，為了進(jìn)行災(zāi)難備份，可以將持久化文件拷貝到一個(gè)遠(yuǎn)程位置。Redis 的持久化機(jī)制有兩種：

RDB(Redis Data Base) 內(nèi)存快照

AOF(Append Only File) 增量日志

RDB 將當(dāng)前數(shù)據(jù)保存到硬盤(pán)，AOF 則是將每次執(zhí)行的寫(xiě)命令保存到硬盤(pán)（類(lèi)似于 MySQL 的 Binlog）。AOF 持久化的實(shí)時(shí)性更好，即當(dāng)進(jìn)程意外退出時(shí)丟失的數(shù)據(jù)更少。

RDB 持久化簡(jiǎn)介

RDB ( Redis Data Base) 指的是在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤(pán)，RDB 是內(nèi)存快照（內(nèi)存數(shù)據(jù)的二進(jìn)制序列化形式）的方式持久化，每次都是從 Redis 中生成一個(gè)快照進(jìn)行數(shù)據(jù)的全量備份。

優(yōu)點(diǎn)：

存儲(chǔ)緊湊，節(jié)省內(nèi)存空間。

恢復(fù)速度非常快。

適合全量備份、全量復(fù)制的場(chǎng)景，經(jīng)常用于災(zāi)難恢復(fù)（對(duì)數(shù)據(jù)的完整性和一致性要求相對(duì)較低的場(chǎng)合）。

缺點(diǎn)：

容易丟失數(shù)據(jù)，容易丟失兩次快照之間 Redis 服務(wù)器中變化的數(shù)據(jù)。

RDB 通過(guò) fork 子進(jìn)程對(duì)內(nèi)存快照進(jìn)行全量備份，是一個(gè)重量級(jí)操作，頻繁執(zhí)行成本高。

RDB 文件結(jié)構(gòu)

在默認(rèn)情況下，Redis 將數(shù)據(jù)庫(kù)快照保存在名字為 dump.rdb 的二進(jìn)制文件中。RDB 文件結(jié)構(gòu)由五個(gè)部分組成：

（1）長(zhǎng)度為 5 字節(jié)的 REDIS 常量字符串。

（2）4 字節(jié)的 db_version，標(biāo)識(shí) RDB 文件版本。

（3）databases: 不定長(zhǎng)度，包含零個(gè)或多個(gè)數(shù)據(jù)庫(kù)，以及各數(shù)據(jù)庫(kù)中的鍵值對(duì)數(shù)據(jù)。

（4）1 字節(jié)的 EOF 常量，表示文件正文內(nèi)容結(jié)束。

（5）check_sum: 8 字節(jié)長(zhǎng)的無(wú)符號(hào)整數(shù)，保存校驗(yàn)和。

數(shù)據(jù)結(jié)構(gòu)舉例，以下是數(shù)據(jù)庫(kù) [0] 和數(shù)據(jù)庫(kù) [3] 有數(shù)據(jù)的情況：

RDB 文件的創(chuàng)建

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

手動(dòng)觸發(fā) RDB 持久化的方式可以使用 save 命令和 bgsave 命令，這兩個(gè)命令的區(qū)別如下：

save：執(zhí)行 save 指令，阻塞 Redis 的其他操作，會(huì)導(dǎo)致 Redis 無(wú)法響應(yīng)客戶端請(qǐng)求，不建議使用。

bgsave：執(zhí)行 bgsave 指令，Redis 后臺(tái)創(chuàng)建子進(jìn)程，異步進(jìn)行快照的保存操作，此時(shí) Redis 仍然能響應(yīng)客戶端的請(qǐng)求。

自動(dòng)間隔性保存

在默認(rèn)情況下，Redis 將數(shù)據(jù)庫(kù)快照保存在名字為 dump.rdb 的二進(jìn)制文件中。可以對(duì) Redis 進(jìn)行設(shè)置，讓它在“N 秒內(nèi)數(shù)據(jù)集至少有 M 個(gè)改動(dòng)”這一條件被滿足時(shí)，自動(dòng)保存一次數(shù)據(jù)集。

比如說(shuō)，以下設(shè)置會(huì)讓 Redis 在滿足“60 秒內(nèi)有至少有 10 個(gè)鍵被改動(dòng)”這一條件時(shí)，自動(dòng)保存一次數(shù)據(jù)集:save 60 10。

Redis 的默認(rèn)配置如下，三個(gè)設(shè)置滿足其一即可觸發(fā)自動(dòng)保存：

save 60 10000
save 300 10
save 900 1

自動(dòng)保存配置的數(shù)據(jù)結(jié)構(gòu)

記錄了服務(wù)器觸發(fā)自動(dòng) BGSAVE 條件的 saveparams 屬性。

lastsave 屬性：記錄服務(wù)器最后一次執(zhí)行 SAVE 或者 BGSAVE 的時(shí)間。

dirty 屬性：以及自最后一次保存 RDB 文件以來(lái)，服務(wù)器進(jìn)行了多少次寫(xiě)入。

備份過(guò)程

RDB 持久化方案進(jìn)行備份時(shí)，Redis 會(huì)單獨(dú) fork 一個(gè)子進(jìn)程來(lái)進(jìn)行持久化，會(huì)將數(shù)據(jù)寫(xiě)入一個(gè)臨時(shí)文件中，持久化完成后替換舊的 RDB 文件。在整個(gè)持久化過(guò)程中，主進(jìn)程（為客戶端提供服務(wù)的進(jìn)程）不參與 IO 操作，這樣能確保 Redis 服務(wù)的高性能，RDB 持久化機(jī)制適合對(duì)數(shù)據(jù)完整性要求不高但追求高效恢復(fù)的使用場(chǎng)景。下面展示 RDB 持久化流程：

關(guān)鍵執(zhí)行步驟如下

Redis 父進(jìn)程首先判斷：當(dāng)前是否在執(zhí)行 save，或 bgsave/bgrewriteaof 的子進(jìn)程，如果在執(zhí)行則 bgsave 命令直接返回。bgsave/bgrewriteaof 的子進(jìn)程不能同時(shí)執(zhí)行，主要是基于性能方面的考慮：兩個(gè)并發(fā)的子進(jìn)程同時(shí)執(zhí)行大量的磁盤(pán)寫(xiě)操作，可能引起嚴(yán)重的性能問(wèn)題。

父進(jìn)程執(zhí)行 fork 操作創(chuàng)建子進(jìn)程，這個(gè)過(guò)程中父進(jìn)程是阻塞的，Redis 不能執(zhí)行來(lái)自客戶端的任何命令。父進(jìn)程 fork 后，bgsave 命令返回”Background saving started”信息并不再阻塞父進(jìn)程，并可以響應(yīng)其他命令。

子進(jìn)程進(jìn)程對(duì)內(nèi)存數(shù)據(jù)生成快照文件。

父進(jìn)程在此期間接收的新的寫(xiě)操作，使用 COW 機(jī)制寫(xiě)入。

子進(jìn)程完成快照寫(xiě)入，替換舊 RDB 文件，隨后子進(jìn)程退出。

在生成 RDB 文件的步驟中，在同步到磁盤(pán)和持續(xù)寫(xiě)入這個(gè)過(guò)程是如何處理數(shù)據(jù)不一致的情況呢？生成快照 RDB 文件時(shí)是否會(huì)對(duì)業(yè)務(wù)產(chǎn)生影響？

Fork 子進(jìn)程的作用

上面說(shuō)到了 RDB 持久化過(guò)程中，主進(jìn)程會(huì) fork 一個(gè)子進(jìn)程來(lái)負(fù)責(zé) RDB 的備份，這里簡(jiǎn)單介紹一下 fork：

Linux 操作系統(tǒng)中的程序，fork 會(huì)產(chǎn)生一個(gè)和父進(jìn)程完全相同的子進(jìn)程。子進(jìn)程與父進(jìn)程所有的數(shù)據(jù)均一致，但是子進(jìn)程是一個(gè)全新的進(jìn)程，與原進(jìn)程是父子進(jìn)程關(guān)系。

出于效率考慮，Linux 操作系統(tǒng)中使用 COW(Copy On Write)寫(xiě)時(shí)復(fù)制機(jī)制，fork 子進(jìn)程一般情況下與父進(jìn)程共同使用一段物理內(nèi)存，只有在進(jìn)程空間中的內(nèi)存發(fā)生修改時(shí)，內(nèi)存空間才會(huì)復(fù)制一份出來(lái)。

在 Redis 中，RDB 持久化就是充分的利用了這項(xiàng)技術(shù)，Redis 在持久化時(shí)調(diào)用 glibc 函數(shù) fork 一個(gè)子進(jìn)程，全權(quán)負(fù)責(zé)持久化工作，這樣父進(jìn)程仍然能繼續(xù)給客戶端提供服務(wù)。fork 的子進(jìn)程初始時(shí)與父進(jìn)程（Redis 的主進(jìn)程）共享同一塊內(nèi)存；當(dāng)持久化過(guò)程中，客戶端的請(qǐng)求對(duì)內(nèi)存中的數(shù)據(jù)進(jìn)行修改，此時(shí)就會(huì)通過(guò) COW (Copy On Write) 機(jī)制對(duì)數(shù)據(jù)段頁(yè)面進(jìn)行分離，也就是復(fù)制一塊內(nèi)存出來(lái)給主進(jìn)程去修改。

通過(guò) fork 創(chuàng)建的子進(jìn)程能夠獲得和父進(jìn)程完全相同的內(nèi)存空間，父進(jìn)程對(duì)內(nèi)存的修改對(duì)于子進(jìn)程是不可見(jiàn)的，兩者不會(huì)相互影響；

通過(guò) fork 創(chuàng)建子進(jìn)程時(shí)不會(huì)立刻觸發(fā)大量?jī)?nèi)存的拷貝，采用的是寫(xiě)時(shí)拷貝 COW (Copy On Write)。內(nèi)核只為新生成的子進(jìn)程創(chuàng)建虛擬空間結(jié)構(gòu)，它們來(lái)復(fù)制于父進(jìn)程的虛擬究竟結(jié)構(gòu)，但是不為這些段分配物理內(nèi)存，它們共享父進(jìn)程的物理空間，當(dāng)父子進(jìn)程中有更改相應(yīng)段的行為發(fā)生時(shí)，再為子進(jìn)程相應(yīng)的段分配物理空間；

AOF 持久化簡(jiǎn)介

AOF (Append Only File) 是把所有對(duì)內(nèi)存進(jìn)行修改的指令（寫(xiě)操作）以獨(dú)立日志文件的方式進(jìn)行記錄，重啟時(shí)通過(guò)執(zhí)行 AOF 文件中的 Redis 命令來(lái)恢復(fù)數(shù)據(jù)。類(lèi)似 MySql bin-log 原理。AOF 能夠解決數(shù)據(jù)持久化實(shí)時(shí)性問(wèn)題，是現(xiàn)在 Redis 持久化機(jī)制中主流的持久化方案。

優(yōu)點(diǎn)：

數(shù)據(jù)的備份更加完整，丟失數(shù)據(jù)的概率更低，適合對(duì)數(shù)據(jù)完整性要求高的場(chǎng)景

日志文件可讀，AOF 可操作性更強(qiáng)，可通過(guò)操作日志文件進(jìn)行修復(fù)

缺點(diǎn)：

AOF 日志記錄在長(zhǎng)期運(yùn)行中逐漸龐大，恢復(fù)起來(lái)非常耗時(shí)，需要定期對(duì) AOF 日志進(jìn)行瘦身處理

恢復(fù)備份速度比較慢

同步寫(xiě)操作頻繁會(huì)帶來(lái)性能壓力

AOF 文件內(nèi)容

被寫(xiě)入 AOF 文件的所有命令都是以 RESP 格式保存的，是純文本格式保存在 AOF 文件中。

Redis 客戶端和服務(wù)端之間使用一種名為 RESP(REdis Serialization Protocol) 的二進(jìn)制安全文本協(xié)議進(jìn)行通信。

下面以一個(gè)簡(jiǎn)單的 SET 命令進(jìn)行舉例：

redis  SET mykey  hello  
// 客戶端命令 OK

客戶端封裝為以下格式（每行用 \r\n 分隔）

*3$3SET$5mykey$5hello

AOF 文件中記錄的文本內(nèi)容如下

*2\r\n$6\r\nSELECT\r\n$1\r\n0\r\n 
// 多出一個(gè) SELECT 0  命令，用于指定數(shù)據(jù)庫(kù)，為系統(tǒng)自動(dòng)添加
*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$5\r\nhello\r\n

AOF 持久化實(shí)現(xiàn)

AOF 持久化方案進(jìn)行備份時(shí)，客戶端所有請(qǐng)求的寫(xiě)命令都會(huì)被追加到 AOF 緩沖區(qū)中，緩沖區(qū)中的數(shù)據(jù)會(huì)根據(jù) Redis 配置文件中配置的同步策略來(lái)同步到磁盤(pán)上的 AOF 文件中，追加保存每次寫(xiě)的操作到文件末尾。同時(shí)當(dāng) AOF 的文件達(dá)到重寫(xiě)策略配置的閾值時(shí)，Redis 會(huì)對(duì) AOF 日志文件進(jìn)行重寫(xiě)，給 AOF 日志文件瘦身。Redis 服務(wù)重啟的時(shí)候，通過(guò)加載 AOF 日志文件來(lái)恢復(fù)數(shù)據(jù)。

AOF 的執(zhí)行流程包括：

命令追加(append)

Redis 先將寫(xiě)命令追加到緩沖區(qū) aof_buf，而不是直接寫(xiě)入文件，主要是為了避免每次有寫(xiě)命令都直接寫(xiě)入硬盤(pán)，導(dǎo)致硬盤(pán) IO 成為 Redis 負(fù)載的瓶頸。

struct redisServer { // 其他域... sds aof_buf; // sds 類(lèi)似于 Java 中的 String // 其他域...}

文件寫(xiě)入 (write) 和文件同步(sync)

根據(jù)不同的同步策略將 aof_buf 中的內(nèi)容同步到硬盤(pán)；

Linux 操作系統(tǒng)中為了提升性能，使用了頁(yè)緩存（page cache）。當(dāng)我們將 aof_buf 的內(nèi)容寫(xiě)到磁盤(pán)上時(shí)，此時(shí)數(shù)據(jù)并沒(méi)有真正的落盤(pán)，而是在 page cache 中，為了將 page cache 中的數(shù)據(jù)真正落盤(pán)，需要執(zhí)行 fsync / fdatasync 命令來(lái)強(qiáng)制刷盤(pán)。這邊的文件同步做的就是刷盤(pán)操作，或者叫文件刷盤(pán)可能更容易理解一些。

AOF 緩存區(qū)的同步文件策略由參數(shù) appendfsync 控制，有三種同步策略，各個(gè)值的含義如下：

always：命令寫(xiě)入 aof_buf 后立即調(diào)用系統(tǒng) write 操作和系統(tǒng) fsync 操作同步到 AOF 文件，fsync 完成后線程返回。這種情況下，每次有寫(xiě)命令都要同步到 AOF 文件，硬盤(pán) IO 成為性能瓶頸，Redis 只能支持大約幾百 TPS 寫(xiě)入，嚴(yán)重降低了 Redis 的性能；即便是使用固態(tài)硬盤(pán)（SSD），每秒大約也只能處理幾萬(wàn)個(gè)命令，而且會(huì)大大降低 SSD 的壽命。可靠性較高，數(shù)據(jù)基本不丟失。

no：命令寫(xiě)入 aof_buf 后調(diào)用系統(tǒng) write 操作，不對(duì) AOF 文件做 fsync 同步；同步由操作系統(tǒng)負(fù)責(zé)，通常同步周期為 30 秒。這種情況下，文件同步的時(shí)間不可控，且緩沖區(qū)中堆積的數(shù)據(jù)會(huì)很多，數(shù)據(jù)安全性無(wú)法保證。

everysec：命令寫(xiě)入 aof_buf 后調(diào)用系統(tǒng) write 操作，write 完成后線程返回；fsync 同步文件操作由專(zhuān)門(mén)的線程每秒調(diào)用一次。everysec 是前述兩種策略的折中，是性能和數(shù)據(jù)安全性的平衡，因此是 Redis 的默認(rèn)配置，也是我們推薦的配置。

文件重寫(xiě)(rewrite)

定期重寫(xiě) AOF 文件，達(dá)到壓縮的目的。

AOF 重寫(xiě)是 AOF 持久化的一個(gè)機(jī)制，用來(lái)壓縮 AOF 文件，通過(guò) fork 一個(gè)子進(jìn)程，重新寫(xiě)一個(gè)新的 AOF 文件，該次重寫(xiě)不是讀取舊的 AOF 文件進(jìn)行復(fù)制，而是讀取內(nèi)存中的 Redis 數(shù)據(jù)庫(kù)，重寫(xiě)一份 AOF 文件，有點(diǎn)類(lèi)似于 RDB 的快照方式。

文件重寫(xiě)之所以能夠壓縮 AOF 文件，原因在于：

過(guò)期的數(shù)據(jù)不再寫(xiě)入文件

無(wú)效的命令不再寫(xiě)入文件：如有些數(shù)據(jù)被重復(fù)設(shè)值 (set mykey v1, set mykey v2)、有些數(shù)據(jù)被刪除了(sadd myset v1, del myset) 等等

多條命令可以合并為一個(gè)：如 sadd myset v1, sadd myset v2, sadd myset v3 可以合并為 sadd myset v1 v2 v3。不過(guò)為了防止單條命令過(guò)大造成客戶端緩沖區(qū)溢出，對(duì)于 list、set、hash、zset 類(lèi)型的 key，并不一定只使用一條命令；而是以某個(gè)常量為界將命令拆分為多條。這個(gè)常量在 redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD 中定義，不可更改，2.9 版本中值是 64。

AOF 重寫(xiě)

前面提到 AOF 的缺點(diǎn)時(shí)，說(shuō)過(guò) AOF 屬于日志追加的形式來(lái)存儲(chǔ) Redis 的寫(xiě)指令，這會(huì)導(dǎo)致大量冗余的指令存儲(chǔ)，從而使得 AOF 日志文件非常龐大，比如同一個(gè) key 被寫(xiě)了 10000 次，最后卻被刪除了，這種情況不僅占內(nèi)存，也會(huì)導(dǎo)致恢復(fù)的時(shí)候非常緩慢，因此 Redis 提供重寫(xiě)機(jī)制來(lái)解決這個(gè)問(wèn)題。Redis 的 AOF 持久化機(jī)制執(zhí)行重寫(xiě)后，保存的只是恢復(fù)數(shù)據(jù)的最小指令集，我們?nèi)绻胧謩?dòng)觸發(fā)可以使用如下指令：

bgrewriteaof

文件重寫(xiě)時(shí)機(jī)

相關(guān)參數(shù)：

aof_current_size：表示當(dāng)前 AOF 文件空間

aof_base_size：表示上一次重寫(xiě)后 AOF 文件空間

auto-aof-rewrite-min-size: 表示運(yùn)行 AOF 重寫(xiě)時(shí)文件的最小體積，默認(rèn)為 64MB

auto-aof-rewrite-percentage: 表示當(dāng)前 AOF 重寫(xiě)時(shí)文件空間（aof_current_size）超過(guò)上一次重寫(xiě)后 AOF 文件空間（aof_base_size）的比值多少后會(huì)重寫(xiě)。

同時(shí)滿足下面兩個(gè)條件，則觸發(fā) AOF 重寫(xiě)機(jī)制：

aof_current_size 大于 auto-aof-rewrite-min-size

當(dāng)前 AOF 相比上一次 AOF 的增長(zhǎng)率:(aof_current_size – aof_base_size)/aof_base_size 大于或等于 auto-aof-rewrite-percentage

AOF 重寫(xiě)流程如下：

bgrewriteaof 觸發(fā)重寫(xiě)，判斷是否存在 bgsave 或者 bgrewriteaof 正在執(zhí)行，存在則等待其執(zhí)行結(jié)束再執(zhí)行

主進(jìn)程 fork 子進(jìn)程，防止主進(jìn)程阻塞無(wú)法提供服務(wù)，類(lèi)似 RDB

子進(jìn)程遍歷 Redis 內(nèi)存快照中數(shù)據(jù)寫(xiě)入臨時(shí) AOF 文件，同時(shí)會(huì)將新的寫(xiě)指令寫(xiě)入 aof_buf 和 aof_rewrite_buf 兩個(gè)重寫(xiě)緩沖區(qū)，前者是為了寫(xiě)回舊的 AOF 文件，后者是為了后續(xù)刷新到臨時(shí) AOF 文件中，防止快照內(nèi)存遍歷時(shí)新的寫(xiě)入操作丟失

子進(jìn)程結(jié)束臨時(shí) AOF 文件寫(xiě)入后，通知主進(jìn)程

主進(jìn)程會(huì)將上面 3 中的 aof_rewirte_buf 緩沖區(qū)中的數(shù)據(jù)寫(xiě)入到子進(jìn)程生成的臨時(shí) AOF 文件中

主進(jìn)程使用臨時(shí) AOF 文件替換舊 AOF 文件，完成整個(gè)重寫(xiě)過(guò)程。

在實(shí)際中，為了避免在執(zhí)行命令時(shí)造成客戶端輸入緩沖區(qū)溢出，重寫(xiě)程序會(huì)檢查集合元素?cái)?shù)量是否超過(guò) REDIS_AOF_REWRITE_ITEMS_PER_CMD 常量的值，如果超過(guò)了，則會(huì)使用多個(gè)命令來(lái)記錄，而不單單使用一條命令。

Redis 2.9 版本中該常量為 64，如果一個(gè)命令的集合鍵包含超過(guò)了 64 個(gè)元素，重寫(xiě)程序會(huì)拆成多個(gè)命令。

AOF 重寫(xiě)是一個(gè)有歧義的名字，該功能是通過(guò)直接讀取數(shù)據(jù)庫(kù)的鍵值對(duì)實(shí)現(xiàn)的，程序無(wú)需對(duì)現(xiàn)有 AOF 文件進(jìn)行任何讀入、分析或者寫(xiě)入操作。

思考 AOF 與 WAL

Redis 為什么考慮使用 AOF 而不是 WAL 呢?

很多數(shù)據(jù)庫(kù)都是采用的 Write Ahead Log（WAL）寫(xiě)前日志，其特點(diǎn)就是先把修改的數(shù)據(jù)記錄到日志中，再進(jìn)行寫(xiě)數(shù)據(jù)的提交，可以方便通過(guò)日志進(jìn)行數(shù)據(jù)恢復(fù)。

但是 Redis 采用的卻是 AOF（Append Only File）寫(xiě)后日志，特點(diǎn)就是先執(zhí)行寫(xiě)命令，把數(shù)據(jù)寫(xiě)入內(nèi)存中，再記錄日志。

如果先讓系統(tǒng)執(zhí)行命令，只有命令能執(zhí)行成功，才會(huì)被記錄到日志中。因此，Redis 使用寫(xiě)后日志這種形式，可以避免出現(xiàn)記錄錯(cuò)誤命令的情況。

另外還有一個(gè)原因就是：AOF 是在命令執(zhí)行后才記錄日志，所以不會(huì)阻塞當(dāng)前的寫(xiě)操作。

AOF 和 RDB 之間的相互作用

在版本號(hào)大于等于 2.4 的 Redis 中，BGSAVE 執(zhí)行的過(guò)程中，不可以執(zhí)行 BGREWRITEAOF。反過(guò)來(lái)說(shuō)，在 BGREWRITEAOF 執(zhí)行的過(guò)程中，也不可以執(zhí)行 BGSAVE。這可以防止兩個(gè) Redis 后臺(tái)進(jìn)程同時(shí)對(duì)磁盤(pán)進(jìn)行大量的 I/O 操作。

如果 BGSAVE 正在執(zhí)行，并且用戶顯示地調(diào)用 BGREWRITEAOF 命令，那么服務(wù)器將向用戶回復(fù)一個(gè) OK 狀態(tài)，并告知用戶，BGREWRITEAOF 已經(jīng)被預(yù)定執(zhí)行：一旦 BGSAVE 執(zhí)行完畢 BGREWRITEAOF 就會(huì)正式開(kāi)始。

當(dāng) Redis 啟動(dòng)時(shí)，如果 RDB 持久化和 AOF 持久化都被打開(kāi)了，那么程序會(huì)優(yōu)先使用 AOF 文件來(lái)恢復(fù)數(shù)據(jù)集，因?yàn)?AOF 文件所保存的數(shù)據(jù)通常是最完整的。

混合持久化

Redis4.0 后大部分的使用場(chǎng)景都不會(huì)單獨(dú)使用 RDB 或者 AOF 來(lái)做持久化機(jī)制，而是兼顧二者的優(yōu)勢(shì)混合使用。其原因是 RDB 雖然快，但是會(huì)丟失比較多的數(shù)據(jù)，不能保證數(shù)據(jù)完整性；AOF 雖然能盡可能保證數(shù)據(jù)完整性，但是性能確實(shí)是一個(gè)詬病，比如重放恢復(fù)數(shù)據(jù)。

Redis 從 4.0 版本開(kāi)始引入 RDB-AOF 混合持久化模式，這種模式是基于 AOF 持久化模式構(gòu)建而來(lái)的，混合持久化通過(guò) aof-use-rdb-preamble yes 開(kāi)啟。

那么 Redis 服務(wù)器在執(zhí)行 AOF 重寫(xiě)操作時(shí)，就會(huì)像執(zhí)行 BGSAVE 命令那樣，根據(jù)數(shù)據(jù)庫(kù)當(dāng)前的狀態(tài)生成出相應(yīng)的 RDB 數(shù)據(jù)，并將這些數(shù)據(jù)寫(xiě)入新建的 AOF 文件中，至于那些在 AOF 重寫(xiě)開(kāi)始之后執(zhí)行的 Redis 命令，則會(huì)繼續(xù)以協(xié)議文本的方式追加到新 AOF 文件的末尾，即已有的 RDB 數(shù)據(jù)的后面。

換句話說(shuō)，在開(kāi)啟了 RDB-AOF 混合持久化功能之后，服務(wù)器生成的 AOF 文件將由兩個(gè)部分組成，其中位于 AOF 文件開(kāi)頭的是 RDB 格式的數(shù)據(jù)，而跟在 RDB 數(shù)據(jù)后面的則是 AOF 格式的數(shù)據(jù)。

當(dāng)一個(gè)支持 RDB-AOF 混合持久化模式的 Redis 服務(wù)器啟動(dòng)并載入 AOF 文件時(shí)，它會(huì)檢查 AOF 文件的開(kāi)頭是否包含了 RDB 格式的內(nèi)容。

如果包含，那么服務(wù)器就會(huì)先載入開(kāi)頭的 RDB 數(shù)據(jù)，然后再載入之后的 AOF 數(shù)據(jù)。

如果 AOF 文件只包含 AOF 數(shù)據(jù)，那么服務(wù)器將直接載入 AOF 數(shù)據(jù)。

其日志文件結(jié)構(gòu)如下：