AOF（Append Only File）

Redis持久化：AOF日志

用 AOF 方法進行故障恢復的時候，需要逐一把操作日志都執行一遍。如果操作日志非常多，Redis 就會恢復得很緩慢，影響到正常使用。

RDB（Redis DataBase）

內存數據的全量快照，即把內存數據都保存到磁盤。

save：主進程執行，會導致redis阻塞
bgsave：創建子進程進行RDB文件寫入。

bgsave

同AOF的bgrewriteaof 一樣: fork子進程需要拷貝進程必要的數據結構，其中有一項就是拷貝內存頁表（虛擬內存和物理內存的映射索引表），這個拷貝過程會消耗大量CPU資源，拷貝完成之前整個進程是會阻塞的.

如果主進程僅做read操作，那么父子進程互不影響。若主進程做write操作，那么這塊數據會復制一份生成數據副本，主進程修改此副本數據。bgsave子進程則繼續將原有數據寫入RDB文件

執行快照的頻率

bgsave不會重復執行

當一個bgsave操作正在運行時，不會啟動第二個bgsave子進程。這是因為Redis在執行bgsave操作時，會創建一個子進程來執行備份任務。如果一個bgsave操作已經開始，那么Redis不會再啟動另一個bgsave操作，直到當前的bgsave操作完成或被取消。

頻率不好控制

要想盡可能恢復數據，快照間隔就必須得短，但是頻繁執行RDB備份，會有：

1. 磁盤壓力
2. 進程拷貝頻繁阻塞主進程

save選項可以設置多個保存條件，只要其中任意一個條件被滿足，服務器就會執行bgsave命令。例如，可以設置服務器在900秒之內對數據庫進行了至少1次修改，或者在300秒之內對數據庫進行了至少30次修改，或者在60秒之內對數據庫進行了至少10000次修改等。

混合持久化

Redis 6.0和5.0默認開啟了aof-use-rdb-preamble。

當開啟混合持久化時，Redis會先使用RDB方式將現有內存中的數據寫入RDB文件，然后再將緩沖區中的增量命令以AOF方式寫入AOF文件。在完成寫入后，主進程會接收到通知，并將新的含有RDB和AOF兩種格式的文件替換舊的AOF文件。

這樣做的目的是同時利用RDB和AOF兩種持久化方式的優點，即快速恢復數據和保證數據的完整性。

恢復時，Redis會優先使用AOF日志進行恢復。

總結

以上是生活随笔為你收集整理的Redis宕机恢复的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。