【Redis持久化】AOF持久化機制
4.1 AOF持久化簡介
AOF持久化機制： 對 每條寫入的命令 作爲日誌，以 append-only的模式 寫入到一個日誌文件中。在Redis重啓的時候，可以通過 回放AOF日誌文件中的寫入命令 重新構建整個數據集
4.2 AOF持久化的優點
-
AOF可以保證更少的數據不丟失，因爲他備份的頻率比較高，且不會影響Redis正常提供服務，通過每隔1秒，會通過一個後臺線程執行一次fsync操作，最多丟失一秒的數據。
-
AOF日誌文件 已 append-only 模式寫入，所以沒有磁盤尋址的開銷，寫入性能非常高，且文件不易損壞。
-
AOF日誌文件過大時，出現後臺重寫操作，不會影響客戶端的讀寫。因爲rewrite log的時候，會對其中的數據進行壓縮，創造一份需要回複數據的最小日誌出來。再創建新的日誌文件時，舊的日誌文件照常寫入。當新的merge後的日誌文件準備好的時候，再交換老的日誌文件。
-
AOF日誌文件的命令通常通過非常可讀的方式記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有數據，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝AOF文件，將最後一條flushall命令給刪了，然後再將該AOF文件放回去，就可以通過恢復機制，自動恢復所有數據
4.3 AOF持久化的缺點
-
對同一份數據，AOF日誌文件通常比RDB快照文件大的多，因此需要佔用更多的存儲空間。
-
AOF開啓後，支持的寫QPS會比RDB支持的寫QPS低，因爲AOF一般配置成每秒fsync一次日誌文件，當然，每秒一次fsync，性能也是非常高的，不會影響Redis正常爲客戶端提供服務。
-
AOF穩定性沒有RDB強，通過AOF記錄的日誌文件，在進行數據恢復的時候，沒有恢復出一模一樣的數據出來。所以說，類似AOF這種複雜的基於命令/merge/回放的方式，比基於Rdb每次持久化重新拷貝一份完整的數據快照文件的方式，穩定性沒有那麼高，容易有bug。不過AOF就是爲了避免 rewrite 過程導致的bug，因此每次rewrite並不是基於舊的指令日誌進行merge的，而是基於當時內存中的數據進行執行的重新構建，這樣健壯性會好很多。
參考石衫老師 《億級流量電商詳情頁系統》課程筆記
親，如果覺得還不錯，點個讚唄！！！你的鼓勵是我堅持的最大源泉。