【Redis AOF文件】
1、關於AOF
- AOF 持久化記錄服務器執行的所有寫操作命令，並在服務器啟動時，通過重新執行這些命令來還原數據集。 AOF 文件中的命令全部以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。 Redis 還可以在后台對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數據集狀態所需的實際大小。
- Redis 還可以同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當 Redis 重啟時， 它會優先使用 AOF 文件來還原數據集， 因為 AOF 文件保存的數據集通常比 RDB 文件所保存的數據集更完整。
AOF 的優點
- 使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設置不同的
fsync策略，比如無fsync，每秒鍾一次fsync，或者每次執行寫入命令時fsync。 AOF 的默認策略為每秒鍾fsync一次，在這種配置下，Redis 仍然可以保持良好的性能，並且就算發生故障停機，也最多只會丟失一秒鍾的數據（fsync會在后台線程執行，所以主線程可以繼續努力地處理命令請求）。 - AOF 文件是一個只進行追加操作的日志文件（append only log）， 因此對 AOF 文件的寫入不需要進行
seek， 即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等），redis-check-aof工具也可以輕易地修復這種問題。 - Redis 可以在 AOF 文件體積變得過大時，自動地在后台對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件里面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作。
- AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。
AOF 的缺點
- 對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積。
- 根據所使用的
fsync策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒fsync的性能依然非常高， 而關閉fsync可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。 - AOF 在過去曾經發生過這樣的 bug ： 因為個別命令的原因，導致 AOF 文件在重新載入時，無法將數據集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug 。） 測試套件里為這種情況添加了測試： 它們會自動生成隨機的、復雜的數據集， 並通過重新載入這些數據來確保一切正常。 雖然這種 bug 在 AOF 文件中並不常見， 但是對比來說， RDB 幾乎是不可能出現這種 bug 的。
AOF 的運作方式
AOF 重寫和 RDB 創建快照一樣，都巧妙地利用了寫時復制機制。
以下是 AOF 重寫的執行步驟：
- Redis 執行
fork()，現在同時擁有父進程和子進程。 - 子進程開始將新 AOF 文件的內容寫入到臨時文件。
- 對於所有新執行的寫入命令，父進程一邊將它們累積到一個內存緩存中，一邊將這些改動追加到現有 AOF 文件的末尾： 這樣即使在重寫的中途發生停機，現有的 AOF 文件也還是安全的。
- 當子進程完成重寫工作時，它給父進程發送一個信號，父進程在接收到信號之后，將內存緩存中的所有數據追加到新 AOF 文件的末尾。
- 搞定！現在 Redis 原子地用新文件替換舊文件，之后所有命令都會直接追加到新 AOF 文件的末尾。