在復習Redis相關知識時，系統整理了Redis持久化相關的知識點，

前言

Redis作為一個記憶體資料庫，資料都保存在記憶體中，但是記憶體的資料是容易發生丟失的，Redis提供了持久化的機制，RDB(Redis DataBase)和AOF(Append Only File)，
下面Redis將資料保存到磁盤上的五個步驟：
前面三個步驟是Redis完成，后面兩個步驟是作業系統完成，
所有和持久化相關的配置都在redis.conf中，

Redis官方對持久化機制的介紹見：https://redis.io/topics/persistence

下面翻譯一下Redis官網對持久化機制的一個大體介紹：

Redis提供了一系列不同的持久性機制：

• RDB（Redis Database）：RDB持久化在指定的時間間隔執行資料集的快照，

• AOF（Append Only File）：AOF持久化記錄服務器接收到的每個寫入操作，這些操作將在服務器啟動時再次執行，重建原始資料集，命令使用與Redis協議本身相同的格式，以僅附加的方式記錄，當日志變得太大時，Redis能夠在后臺重寫日志，

• No persistence ：如果希望，可以完全禁用持久化，只要服務器在運行，資料就一直存在，

• RDB + AOF：可以在同一個實體中組合AOF和RDB，注意，在這種情況下，當Redis重新啟動時，AOF檔案將用于重建原始資料集，因為它保證是最完整的，

最重要的事情是理解RDB和AOF持久性之間的不同權衡，

Redis持久化之RDB（Redis DataBase）

1.理解RDB機制

在指定的時間間隔內將記憶體中的資料集快照寫入磁盤（Snapshot快照），它恢復時是將快照檔案直接讀到記憶體里，

Redis 會單獨fork一個子行程來進行持久化：

• 首先將資料寫入到一個臨時檔案中，等所有持久化程序全部結束了，再用臨時檔案替換上次持久化好的檔案，
• 整個程序中，主行程是不進行任何IO操作的，這就確保了極高的性能，
• 如果需要進行大規模資料的恢復，且對于資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，
• 但是最后一次持久化后的資料可能丟失，

2.RDB觸發方式

save觸發方式

執行save命令時只管保存，其它不管，全部阻塞，
該命令會阻塞當前Redis服務器，執行save命令期間，Redis不能處理其他命令，直到RDB程序完成為止，

bgsave觸發方式

執行該命令時，Redis會在后臺異步進行快照操作，快照同時還可以回應客戶端請求，阻塞只發生在fork階段，一般時間很短，
可以通過lastsave命令獲取最后一次成功執行快照的時間，

自動觸發方式

自動觸發是由組態檔來完成的，具體配置如下：

# save：用來配置觸發 Redis的 RDB 持久化條件，也就是什么時候將記憶體中的資料保存到硬碟，
# “save m n” 表示m秒內資料集存在n次修改時，自動觸發bgsave，
# 如果不需要持久化，可以注釋掉所有的 save 行來停用保存功能，
# 默認配置如下：
save 900 1 # 表示900 秒內如果至少有 1 個 key 的值變化，則保存
save 300 10
save 60 10000


# dbfilename ：設定快照的檔案名，默認是 dump.rdb
dbfilename dump.rdb

# dir：設定快照檔案的存放路徑，這個配置項是一個目錄
dir ./

# 當Redis無法寫入磁盤的話，直接關掉Redis的寫操作，
# 推薦yes
stop-writes-on-bgsave-error yes

# 對于存盤到磁盤中的快照，可以設定是否進行壓縮存盤，如果是的話，redis會采用LZF演算法進行壓縮，
# 如果你不想消耗CPU來進行壓縮的話，可以設定為關閉此功能，
# 推薦yes
rdbcompression yes

# 在存盤快照后，還可以讓redis使用CRC64演算法來進行資料校驗，
# 但是這樣做會增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關閉此功能
# 推薦yes
rdbchecksum yes

動態停止RDB的方式：

#save后給空值，表示禁用保存策略
redis-cli config set save "" 

3.RDB的優劣勢

優勢

• 適合大規模的資料恢復
• 對資料完整性和一致性要求不高更適合使用
• 節省磁盤空間
• 恢復速度快

劣勢

• Fork的時候，記憶體中的資料被克隆了一份，大致2倍的膨脹性需要考慮，
• 雖然Redis在fork時使用了寫時拷貝技術,但是如果資料龐大時還是比較消耗性能，
• 在備份周期在一定間隔時間做一次備份，所以如果Redis意外down掉的話，就會丟失最后一次快照后的所有修改，

Redis持久化之AOF（Append Only File）

1.理解AOF機制

以日志的形式來記錄每個寫操作（增量保存機制），將Redis執行過的所有寫指令記錄下來(讀操作不記錄)， 只許追加檔案但不可以改寫檔案，redis啟動之扯訓讀取該檔案重新構建資料，通俗理解就是日志記錄，

redis 重啟的話就根據日志檔案的內容將寫指令從前到后執行一次以完成資料的恢復作業，

持久化流程：

（1）客戶端的請求寫命令會被append追加到AOF緩沖區內；
（2）AOF緩沖區根據AOF持久化策略[always,everysec,no]將操作sync同步到磁盤的AOF檔案中；
（3）AOF檔案大小超過重寫策略或手動重寫時，會對AOF檔案rewrite重寫，壓縮AOF檔案容量；
（4）Redis服務重啟時，會重新load加載AOF檔案中的寫操作達到資料恢復的目的；

2.重寫（Rewrite）

AOF采用檔案追加方式，檔案會越來越大為避免出現此種情況，新增了重寫機制, 當AOF檔案的大小超過所設定的閾值時，Redis就會啟動AOF檔案的內容壓縮， 只保留可以恢復資料的最小指令集，
使用如下命令：

bgrewriteaof

重寫原理

AOF檔案持續增長而過大時，會fork出一條新行程來將檔案重寫，先寫臨時檔案最后再rename，
redis4.0版本后，重寫的原理是：將rdb對的快照，以二進制的形式附在新的aof的頭部，作為已有的歷史資料，替換掉原來的流水賬操作，

重寫雖然可以節約大量磁盤空間，減少恢復時間，但是每次重寫還是有一定的負擔的，因此設定Redis要滿足一定條件才會進行重寫，

# 設定重寫的基準值，檔案達到100%時開始重寫（檔案是原來重寫后檔案的2倍時觸發）
auto-aof-rewrite-percentage
# 設定重寫的基準值，最小檔案64MB，達到這個值開始重寫，
auto-aof-rewrite-min-size

# 如果值為yes 不寫入aof檔案 只寫入快取 用戶請求不會阻塞 在這段時間如果宕機會丟失這段時間的快取資料，資料安全性降低 性能提高
# 如果值為no,會把資料寫入磁盤，但是遇到重寫操作，可能會發生阻塞， 資料安全性提高 性能降低
no-appendfsync-on-rewrite yes 

重寫流程

當使用bgrewriteaof命令后，重寫流程如下：
（1）判斷是否有bgsave和bgrewriteaof還未結束，如果有，則等待其結束再執行，
（2）主行程fork出子行程進行重寫操作，
（3）子行程將redis記憶體中資料保存到臨時檔案，與此同時，新的客戶端寫請求會寫入aof_buf緩沖區和aof_rewrite_buf重寫緩沖區保證原AOF檔案完整以及檔案生成的程序中新的資料修改操作不會丟失，
（4）子行程寫完新的AOF檔案后，通知父行程，
（5）主行程把aof_rewrite_buf中的資料寫入到心的AOF檔案，
（6）使用新的AOF檔案覆寫舊的AOF檔案，完成該次的AOF重寫操作，

3.AOF同步頻率

# 始終同步，每次Redis的寫入都會立刻記入日志；性能較差但資料完整性比較好
appendfsync always
# 每秒同步，每秒記入日志一次，如果宕機，本秒的資料可能丟失，
appendfsync everysec
# redis不主動進行同步，把同步時機交給作業系統，
appendfsync no

4.相關配置說明

• AOF默認不開啟，修改組態檔開啟，

# 改為yes開啟
appendonly no

• 可以在redis.conf中組態檔名稱，默認為 appendonly.aof

• AOF檔案的保存路徑，同RDB的路徑一致，

• AOF的備份機制和性能雖然和RDB不同, 但是備份和恢復的操作同RDB一樣，都是拷貝備份檔案，需要恢復時再拷貝到Redis作業目錄下，啟動系統即加載，

AOF和RDB同時開啟，系統默認取AOF的資料（資料不會存在丟失）

5.AOF的優劣勢

優勢

• AOF可以更好的保護資料不丟失，一般AOF會每隔1秒，通過一個后臺執行緒執行一次fsync操作，最多丟失1秒鐘的資料，
• AOF日志檔案即使過大的時候，出現后臺重寫操作，也不會影響客戶端的讀寫，
• 可讀的日志文本，通過操作AOF檔案可以處理誤操作，
• AOF日志檔案沒有任何磁盤尋址的開銷，寫入性能非常高，檔案不容易破損，

劣勢

• 比起RDB占用更多的磁盤空間，
• 恢復備份速度要慢，
• 每次讀寫都同步的話，有一定的性能壓力，
• 存在個別Bug，造成恢復不完全，

RDB和AOF的權衡

Redis官網的建議

• RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照存盤

• AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以redis協議追加保存每次寫的操作到檔案末尾.

• Redis還能對AOF檔案進行后臺重寫,使得AOF檔案的體積不至于過大

• 只做快取：如果你只希望你的資料在服務器運行的時候存在,你也可以不使用任何持久化方式.

• 同時開啟兩種持久化方式

  • 在這種情況下,當redis重啟的時候會優先載入AOF檔案來恢復原始的資料, 因為在通常情況下AOF檔案保存的資料集要比RDB檔案保存的資料集要完整.

• RDB的資料不實時，同時使用兩者時服務器重啟也只會找AOF檔案，那要不要只使用AOF呢？

  • 建議不要，因為RDB更適合用于備份資料庫(AOF在不斷變化不好備份)， 快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段，

• 如果對資料不敏感，可以選單獨用RDB，

性能建議

• 1.RDB檔案一般只做后備用途，建議只在Slave上持久化RDB資料檔案，一般15分鐘備份一次就足夠了，
• 2.如果硬碟容量允許，盡量減少AOF rewrite的頻率，AOF重寫的基礎大小是64M，實際生產環境中過小，可以設到5G以上，
• 3.默認超過原大小100%大小時重寫，可以做適當的修改，

參考

• 《Redis設計與實作》
• 《Redis開發與運維》
• 《深入理解Redis》
• https://redis.io/topics/persistence

ATFWUS 2021-09-29