Redis 持久化之 AOF
1. AOF 是什麼？
- 以日誌的形式來記錄每個寫操作， 將 redis 執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis 啓動之初會讀取該文件重新構建數據，換言之，redis 重啓的話就根據日誌文件的內容將寫指令從前到後執行一次以完成數據的恢復工作
2. AOF 保存的是 appendonly.aof 文件
3. 配置位置
配置位置默認就是在哪個目錄下啓動的 redis 服務，就會在哪裏進行創建，可以看我之前寫過的文章【大廠面試】Redis 中的 redis.conf 配置文件詳解
4. AOF啓動 / 修復 / 恢復
- 正常恢復
啓動：設置 yes，修改默認的 appendonly no, 改爲 yes
將有數據的 aof 文件複製一份保存到對應目錄 config get dir
恢復：重啓 redis 然後重新加載 - 異常恢復
啓動：設置 yes，修改默認的 appendonly no, 改爲 yes
備份被寫壞的 AOF 文件
修復：Redis-check-aof --fix aof文件名稱 進行修復
恢復：重啓 redis 然後重新加載即可
5. Rewrite
是什麼
AOF 採用文件追加方式，文件會越來越大爲了避免出現這種情況，新增了重寫機制，當AOF文件的大小超過所設定的閾值時，Redis就會啓動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集，可以使用命令 bgrewriteaof
重寫原理
AOF文件持續增長而過大時，會 fork 出一條新進程來將文件重寫(也就是先寫臨時文件最後在 rename)，遍歷新進程的內存中數據，每條記錄有一條的 Set 語句，重寫 aof 文件的操作，並沒有讀取舊的 aof 文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似
觸發機制
Redis 會記錄上次重寫時的 AOF 大小，默認配置是當 AOF 文件大小是上次 rewrite 後大小的一倍且文件大於 64M 時觸發
6. 優勢
- 每秒同步：appendfsync always 同步持久化，每次發生數據變更會被立即記錄到磁盤，性能較差但數據完整性比較一致
- 每次修改同步：appendfsync everysec 異步操作，每秒記錄，如果一秒內宕機，會有數據丟失
- 不同步：appendfsync no 從不同步
7. 劣勢
- 相同數據集的數據而言aof文件要遠大於rdb文件，恢復速度慢於rdb
- aof 運行效率要慢於 rdb，每秒同步策略效率較好，不同步效率和 rdb 相同。
8. 小總結
優勢：
- AOF 文件是一個只進行追加的日誌文件
- Redis 可以在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫
- AOF 文件有序地保存了對數據庫執行的所有寫入操作，這些寫入操作以 Redis 協議的格式保存，因此 AOF 文件的內容非常容易被人讀懂，對文件進行分析也很輕鬆
劣勢： - 對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積
- 根據所使用的 fsync 策略，AOF 的速度可能慢於 RDB