Redis -持久化方式對比

redis 提供兩種持久化方式，一種是RDB持久化（定時將數據被分到磁盤上），另一種是AOF（append only file）持久化（將對 redis 的操作日誌以追加形式寫入文件）

---

RDB持久化

RDB持久化是指在指定的時間間隔內將內存中的數據集快照寫入磁盤，實際操作過程是fork一個子進程，先將數據集寫入臨時文件，寫入成功後，再替換之前的文件，用二進制壓縮存儲。

配置方式

在redis.conf中默認配置

#   save <seconds> <changes>

# 時間策略
# 900s (15min)內超過 1 個key被修改，則進行持久化
save 900 1
# 300s (5min)內超過 10 個key被修改，則進行持久化
save 300 10
# 60s 內超過 10000 個key被修改，則進行持久化
save 60 10000

# 文件名稱
dbfilename dump.rdb

# 文件保存路徑
dir /home/suhw/data/redis

# 如果持久化出錯，主進程是否停止寫入
stop-writes-on-bgsave-error yes

# 是否壓縮
rdbcompression yes

# 導入時是否檢查
rdbchecksum yes

使用

手動觸發

在 redis 中手動觸發持久化可使用以下命令（一般只適用bgsave）

• save：會阻塞當前Redis服務器，直到持久化完成，線上應該禁止使用。
• bgsave：該觸發方式會fork一個子進程，由子進程負責持久化過程，因此阻塞只會發生在fork子進程的時候。

自動觸發

• 根據 save m n 配置自動觸發
• 從節點全量複製時，主節點發送rdb文件給從節點完成複製操作，主節點會觸發bgsave
• 執行debug reload時
• 執行shutdown時，若沒有開啓aof，也會觸發

執行流程

優勢

1. 備份出的數據只包含一個文件，當系統出現災難性故障時，恢復十分容易
2. 性能最大化，對於redis的服務進程來說，在開始持久化時，唯一需要做的就是fork出子進程，之後再由子進程完成持久化的工作，從而避免服務進程執行IO操作
3. 相比於AOF，如果數據量很大，RDB的啓動效率會很高

劣勢

1. 在兩次持久化之間若服務宕機，數據就會因爲還未保存而丟失
2. 通過fork子進程完成持久化工作，若數據量較大時，可能會導致服務器暫時停止服務幾百ms，或1s

---

AOF持久化

AOF持久化以日誌的形式記錄服務器所處理的每一個寫、刪除操作，查詢操作不會記錄，以文本的方式記錄，可以打開文件看到詳細的操作記錄。

配置方式

同樣在redis.conf中默認配置文件672行

############################## APPEND ONLY MODE ###############################
# 是否開啓AOF，默認關閉（no）
appendonly yes

# 指定 AOF 文件名
appendfilename appendonly.aof

# Redis支持三種不同的刷寫模式：
# appendfsync always #每次收到寫命令就立即強制寫入磁盤，是最有保證的完全的持久化，但速度也是最慢的，一般不推薦使用。
appendfsync everysec #每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，是受推薦的方式。
# appendfsync no     #完全依賴OS的寫入，一般爲30秒左右一次，性能最好但是持久化最沒有保證，不被推薦。

#在日誌重寫時，不進行命令追加操作，而只是將其放在緩衝區裏，避免與命令的追加造成DISK IO上的衝突。
#設置爲yes表示rewrite期間對新寫操作不fsync,暫時存在內存中,等rewrite完成後再寫入，默認爲no
no-appendfsync-on-rewrite no 

#當前AOF文件大小是上次日誌重寫得到AOF文件大小的二倍時，自動啓動新的日誌重寫過程。
auto-aof-rewrite-percentage 100

#當前AOF文件啓動新的日誌重寫過程的最小值，避免剛剛啓動Reids時由於文件尺寸較小導致頻繁的重寫。
auto-aof-rewrite-min-size 64mb

使用

手動觸發

通過bgrewriteaof命令手動觸發AOF持久化

自動觸發

根據redis.conf中的配置規則來觸發

執行流程

優勢

1. 對比RDB持久化，具有更高的數據安全性。redis 中提供了三種同步策略：每秒同步，每修改同步和不同步。
   1. 每秒同步也是異步完成的，但是若系統突然宕機，可能一秒中之內的數據將會丟失
   2. 每修改同步是效率最低的，每次發生數據的變化都會被立刻記錄到磁盤中
2. AOF對於日誌文件採用的是追加模式，因此在寫入過程中即使出現宕機，也不會破壞日誌文件中已經存在的內容；若只寫入一半數據就宕機，在redis下次啓動時，可通過redis-check-aod工具來解決數據一致性的問題
3. 若日誌文件過大，redis可自動啓用rewrite機制。
4. AOF包含一個格式清晰，易於理解的日誌文件用於記錄所有的數據修改操作。

劣勢

1. 對於相同數據量時，AOF文件通常大於RDB文件，並且RDB在恢復大數據量時速度要比AOF快
2. 根據同步策略的不同，AOF在運行效率上往往會慢於RDB

注

不論是RDB還是AOF都是先寫入一個臨時文件，然後通過 rename 完成文件的替換工作。

參考

• https://www.php.cn/redis/421586.html
• https://blog.csdn.net/aitangyong/article/details/52072708