文章目錄

• • 1 AOF（append only file）
  • • 1.1 AOF是什么
    • 1.2 AOF 持久化流程
    • 1.3 AOF 默認不開啟
    • 1.4 AOF 和RDB同時開啟聽誰的
    • 1.5 AOF啟動修復恢復
    • 1.6 AOF 同步頻率
    • 1.7 Rewrite壓縮
    • 1.8 優勢
    • 1.9 劣勢
  • 2 小總結（which one）

1 AOF（append only file）

1.1 AOF是什么

以日志的形式來記錄每個寫操作（增量保存），將redis 執行過的所有寫指令記錄下來（讀操作不記錄），只允許追加文件但不可以改寫文件，reids 啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作

1.2 AOF 持久化流程

客戶端的請求寫命令會被append追加到aof 緩沖區內；

aof 緩沖區根據aof持久化策略（always，everysec，no）將操作sync同步到磁盤的aof文件中；

aof文件大小超過重寫策略或手動重寫時，會對aof文件rewrite重寫，壓縮aof文件容量

redis 服務重啟時，會重新load加載aof文件中的寫操作達到數據恢復的目的；

1.3 AOF 默認不開啟

可以在redis.conf中配置文件名稱，默認為appendonly.aof
AOF文件的保存路徑，同RDB路徑一致

appendonly no# The name of the append only file (default: "appendonly.aof")appendfilename "appendonly.aof"

1.4 AOF 和RDB同時開啟聽誰的

AOF 和RDB同時開啟，redis 會默認取AOF的數據（數據不會丟失）

1.5 AOF啟動修復恢復

aof的備份機制和性能雖然和rdb不同，但是備份和恢復的操作同rdb一樣，都是拷貝備份文件，需要恢復時再拷貝到redis工作目錄，啟動系統即加載

正常恢復
修改默認的appendonly no 改為yes
將有數據的aof文件復制一份保存到對應的目錄（查看目錄：config get dir）

恢復
重啟reids然后重新加載

異常恢復
修改默認的appendonly no 改為yes
如果遇到aof文件損壞，通過/usr/loacal/bin/redis-check-aof --fix appendonly.aof 進行恢復
備份被寫壞的aof文件
恢復：重啟redis，然后重新加載

# redis-check-aof --fix appendonly.aof

1.6 AOF 同步頻率

始終同步，每次redis的寫入都會立刻記入日志，性能較差但數據完整性較好

# appendfsync always

每秒同步，每秒記入日志一次，如果宕機，本秒的數據可能丟失

appendfsync everysec

redis不主動同步，把同步時機交給操作系統

# appendfsync no

1.7 Rewrite壓縮

aof采用文件追加方式，文件會越來越大，為避免出現此種情況，新增了重寫機制，當aof文件的大小超過所設定的閾值時，redis就會啟動aof文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用命令bgrewriteaof

重寫原理
aof文件持續增長而過大時，會fork出一條新進程來將文件重寫（也是先寫臨時文件最后再rename），reids4.0版本后的重寫，是把rdb的快照，以二進制的形式附在新的aof頭部，作為已有的歷史數據，替換原來的流水賬操作

no-appendfsync-on-rewrite no

觸發機制
redis會記錄上次重寫時的aof大小，默認配置是當aof文件大小是上次rewrite后大小的一倍且文件大于64M時觸發

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

auto-aof-rewrite-percentage 設置重寫的基準值，文件達到100%時開始重寫（文件是原來重寫后文件的兩倍時觸發）

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

重寫流程
bgrewriteaof觸發重寫，判斷是否當前有bgsave或bgrewriteaof在運行，如果有，則等待該命令結束后再繼續執行。

主進程fork出子進程執行重寫操作，保證主進程不會阻塞

子進程遍歷redis內存中數據到臨時文件，客戶端的寫請求同時寫入aof_buf
緩沖區和aof_rewrite_buf重寫緩沖區保證原aof文件完整以及新aof文件生成期間的新的數據修改動作不會丟失

子進程寫完新的aof文件后，向主進程發信號，父進程更新統計信息，
主進程把aof_rewrite_buf中的數據寫入到新的aof文件

使用新的aof文件覆蓋舊的aof文件，完成aof重寫

1.8 優勢

備份機制更穩健，丟失數據概率更低

可讀的日志文本，通過操作aof文件，可以處理誤操作

1.9 劣勢

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

2 小總結（which one）

官方推薦兩個都啟用
如果對數據不敏感，可以單獨選用RDB
不建議單獨用aof，因為可能會出現bug
如果只是做純內存緩存，可以都不用

總結

以上是生活随笔為你收集整理的9 Redis 持久化AOF的全部內容，希望文章能夠幫你解決所遇到的問題。

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