1.概述

在Redis的使用中，持久化是一個(gè)重要的特性，它將內(nèi)存中的數(shù)據(jù)保存到硬盤上，以防止數(shù)據(jù)丟失。

Redis 提供了三種主要的持久化方式：AOF（Append Only File）、RDB（Redis DataBase）以及混合持久化（RDB和AOF）。

本文將詳細(xì)介紹 AOF 和 RDB 的區(qū)別及配置方式，幫助讀者更好地理解和選擇合適的持久化方式。

2.RDB和AOF

2.1 RDB

2.1.1 RDB概念

RDB 持久化方式是 Redis 將當(dāng)前內(nèi)存中的數(shù)據(jù)快照（snapshot）保存到硬盤的過程。

這種方式是就是將內(nèi)存中數(shù)據(jù)以快照的方式寫入到二進(jìn)制文件中，默認(rèn)的文件名為dump.rdb。其實(shí)就是每隔一段時(shí)間，Redis 會(huì)創(chuàng)建一個(gè)代表某一時(shí)刻的數(shù)據(jù)集的磁盤文件。

2.1.2 RDB工作原理（Copy-On-Write）

RDB 的生成過程依賴于操作系統(tǒng)的寫時(shí)復(fù)制（COW）機(jī)制，這一機(jī)制確保了快照生成期間 Redis 依然能正常處理讀寫請求，不會(huì)阻塞業(yè)務(wù)。

具體流程如下：

• 1.觸發(fā)快照生成：當(dāng)滿足預(yù)設(shè)條件時(shí)（時(shí)間到、達(dá)到修改次數(shù)閾值），Redis 主進(jìn)程會(huì)fork 一個(gè)子進(jìn)程（此時(shí)子進(jìn)程與主進(jìn)程共享同一塊內(nèi)存空間）； 
• 2.子進(jìn)程寫入快照：子進(jìn)程負(fù)責(zé)遍歷內(nèi)存中的所有數(shù)據(jù)，將其序列化后寫入一個(gè)臨時(shí)的.rdb 文件； 
• 3.主進(jìn)程正常服務(wù)：在子進(jìn)程生成快照期間，主進(jìn)程繼續(xù)處理客戶端的讀寫請求。若有數(shù)據(jù)被修改，操作系統(tǒng)會(huì)為該數(shù)據(jù)塊創(chuàng)建一個(gè)副本，主進(jìn)程修改副本數(shù)據(jù)，而子進(jìn)程依然讀取原始數(shù)據(jù)（避免快照被污染）； 
• 4.替換舊快照：當(dāng)子進(jìn)程完成快照寫入后，會(huì)用臨時(shí)文件替換當(dāng)前的.rdb 文件，至此一次 RDB 持久化完成。

2.1.3 RDB觸發(fā)方式

1.自動(dòng)觸發(fā)：基于配置的"指定時(shí)間+修改次數(shù)"

在Redis 的配置文件（redis.conf）中，通過save指令定義RDB的觸發(fā)規(guī)則，格式為：

save <seconds> <changes> [<seconds> <changes> ...]

表示 “在 seconds 秒內(nèi)，若數(shù)據(jù)修改次數(shù)達(dá)到 changes 次，則觸發(fā) RDB”。

默認(rèn)配置如下：

# 3600秒(1小時(shí))內(nèi)修改1次、300秒內(nèi)修改100次、60秒內(nèi)修改10000次，滿足任一條件即觸發(fā)RDB
save 3600 1
save 300 100
save 60 10000

2.手動(dòng)觸發(fā)：主動(dòng)備份場景

手動(dòng)觸發(fā)主要通過save、bgsave指令實(shí)現(xiàn)：

• save命令：由主進(jìn)程直接生成 RDB，期間會(huì)阻塞所有客戶端請求（線上不推薦使用，會(huì)阻塞請求導(dǎo)致業(yè)務(wù)中斷）； 
• bgsave命令：主進(jìn)程 fork 子進(jìn)程生成 RDB，主進(jìn)程本身不阻塞（線上手動(dòng)觸發(fā)的首選指令）

3.RDB核心配置文件

#指定 RDB 文件的名稱，默認(rèn)為dump.rdb
dbfilename dump.rdb  
#指定 RDB 文件的保存路徑，默認(rèn)是 Redis 的啟動(dòng)目錄（建議改為絕對路徑，如/var/redis/）
dir ./   
#是否對 RDB 文件進(jìn)行壓縮（默認(rèn)開啟，用 CPU 開銷換取磁盤空間，關(guān)閉可提升快照速度）
rdbcompression yes  
#是否對 RDB 文件進(jìn)行校驗(yàn)（默認(rèn)開啟，通過 CRC64 算法確保文件完整性，關(guān)閉可提升加載速度）
rdbchecksum yes  

4.RDB優(yōu)缺點(diǎn)

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

• 恢復(fù)速度快： RDB 是二進(jìn)制的全量快照，加載時(shí)無需解析復(fù)雜指令，僅需反序列化數(shù)據(jù)，適合大規(guī)模數(shù)據(jù)的快速恢復(fù)； 
• 文件體積小： 壓縮后的 RDB文件體積遠(yuǎn)小于 AOF 文件，便于備份和傳輸； 
• 對性能影響小： 子進(jìn)程負(fù)責(zé)生成快照，主線程僅在fork子進(jìn)程時(shí)短暫阻塞（阻塞時(shí)間與內(nèi)存大小相關(guān)，通常毫秒級(jí)），對業(yè)務(wù)讀寫影響低。

缺點(diǎn)：

• 數(shù)據(jù)一致性低： RDB獲取的是“某一時(shí)間點(diǎn)快照”，若在兩次快照間隔期間 Redis 宕機(jī)，則該時(shí)間段內(nèi)修改的數(shù)據(jù)將全部丟失（例如：配置save 30 1000，則最多可能丟失30秒的數(shù)據(jù)）； 
• 文件可讀性性低： RDB 文件是一個(gè)二進(jìn)制文件，并不是一個(gè)易于讀取和理解的文本文件； 
• 不適合實(shí)時(shí)備份： 存在丟失數(shù)據(jù)的可能，適用于對數(shù)據(jù)一致性要求不高的業(yè)務(wù)。

2.2 AOF

2.2.1 AOF概念

AOF其實(shí)就是將每一個(gè)收到的寫命令都通過write函數(shù)追加到文件中，當(dāng) Redis 需要恢復(fù)數(shù)據(jù)時(shí)，只需執(zhí)行 AOF 文件中的命令就可以恢復(fù)到原來的狀態(tài)。

這個(gè)文件有點(diǎn)像MySQL的binlog日志文件，只不過binlog日志文件是二進(jìn)制，Redis的AOF生成的文件是文本格式。

2.2.2 AOF工作原理

1.命令追加

• 每當(dāng) Redis 執(zhí)行一條寫命令并成功處理后，會(huì)將該命令按照 Redis 協(xié)議格式追加到內(nèi)存中的 “AOF 緩沖區(qū)”（避免直接寫入磁盤，降低IO開銷）。 
• 2.文件刷盤AOF 緩沖區(qū)中的命令需要定期寫入磁盤，刷盤策略由appendfsync配置決定。 

3.日志重寫

• 隨著運(yùn)行時(shí)間延長，AOF 文件會(huì)產(chǎn)生大量重復(fù)命令（如多次set同一個(gè)key）而變得異常龐大，占用大量磁盤空間，還會(huì)導(dǎo)致Redis重啟恢復(fù)時(shí)間邊長。
• Redis攜帶了 “日志重寫” 機(jī)制，會(huì)生成一個(gè)包含 “當(dāng)前內(nèi)存數(shù)據(jù)最終狀態(tài)” 的精簡 AOF 文件，替換舊的AOF文件，能有效降低空間占用率、提升恢復(fù)效率。

例如：

• 若指定key的值經(jīng)過多次set，最終是value3，AOF文件中記錄了SET key value1、SET key
• value2、SET key value3三條命令，重寫后只會(huì)保留SET key value3一條命令。

2.2.3 AOF配置

1.啟用AOF

# 啟用AOF（默認(rèn)no）
appendonly yes  
# AOF文件名稱，默認(rèn)appendonly.aof
appendfilename "appendonly.aof" 
# AOF文件保存路徑，與RDB一致
dir ./  

2.刷盤策略

appendfsync定義了 AOF 緩沖區(qū)的命令何時(shí)寫入磁盤，有三種可選值：

3.日志重寫規(guī)則

AOF 重寫同樣支持自動(dòng)觸發(fā)和手動(dòng)觸發(fā)，自動(dòng)觸發(fā)通過auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置實(shí)現(xiàn)：

auto-aof-rewrite-percentage 100  # 當(dāng)AOF文件大小比上次重寫后增大100%（即翻倍）時(shí)觸發(fā)
auto-aof-rewrite-min-size 64mb   # 當(dāng)AOF文件大小至少達(dá)到64MB時(shí)才觸發(fā)（避免小文件頻繁重寫）

手動(dòng)觸發(fā)：執(zhí)行bgrewriteaof命令，主進(jìn)程 fork 子進(jìn)程完成重寫，不阻塞業(yè)務(wù)（和bgsave類似）。

4.AOF優(yōu)缺點(diǎn) 

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

• 數(shù)據(jù)一致性高： 可通過appendfsync always實(shí)現(xiàn) “數(shù)據(jù)零丟失”，或everysec實(shí)現(xiàn) “最多丟失 1 秒數(shù)據(jù)”，滿足高一致性需求； 
• 日志可讀性強(qiáng)： 由于AOF 文件是一個(gè)易于讀取和理解的文本文件，可以方便地進(jìn)行數(shù)據(jù)恢復(fù)、備份和分析； 
• 可靠性高： 記錄了Redis執(zhí)行的所有寫操作，可以提供更可靠的數(shù)據(jù)持久性，避免數(shù)據(jù)丟失。

缺點(diǎn)：

• 恢復(fù)速度慢： 恢復(fù)數(shù)據(jù)時(shí)需要執(zhí)行大量的寫命令，因此恢復(fù)速度相對較慢； 
• 文件體積大： 即使經(jīng)過重寫，AOF 文件體積通常仍大于 RDB 文件，占用更多磁盤空間； 
• 性能開銷較高： 每次寫操作都需要追加到 AOF 文件中，可能會(huì)導(dǎo)致磁盤 I/O 的負(fù)載增加。

2.3 RDB與AOF對比

3.總結(jié)

1.RDB持久化方式能夠在指定的時(shí)間間隔內(nèi)對數(shù)據(jù)進(jìn)行快照存儲(chǔ)；

2.AOF持久化方式記錄每次對服務(wù)器寫的操作，服務(wù)器重啟時(shí)會(huì)重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)；

3.RDB和AOF可同時(shí)開啟，Redis重啟時(shí)會(huì)優(yōu)先載入AOF文件來恢復(fù)原始數(shù)據(jù)，因?yàn)橥ǔＧ闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整；

4.一般情況下，RDB文件只用作后備用途，建議只在slave機(jī)器上持久化RDB文件，并且只要15分鐘備份一次就夠了；

5.如果只做緩存，只希望數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在，其實(shí)不需要持久化操作。

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