Redis的持久化-AOF

Redis的AOF持久化策略是將發送到Redis服務端的每一條命令都記錄下來，並且儲存到硬碟中的AOF檔案中，類似打記錄檔，來一條命令就記錄一條。

AOF設定

AOF檔案的位置和RDB檔案的位置相同，都是通過dir參數設定，預設的檔案名稱是appendonly.aof，可以通過appendfilename參數來修改。

AOF測試

當用戶端向伺服器發送一些redis命令時，Redis會將所執行的命令記錄到aof檔案中，如下所示：

當redis伺服器重啟後，會將執行該aof檔案，達到資料恢複的目的。

AOF檔案重寫

為什麼要重寫。重寫可以去除資料的中間執行過程，直接保留最終資料命令。

舉個栗子：比如在redis用戶端對key執行了一系列命令

set count 1 //初始值為1
incr count // 加1
incr count //加1
decr count //減1

這個時候結果為

get count
“2”

如果不進行AOF重寫的話，進行AOF檔案恢複的時候，Redis會執行AOF檔案中的每一條命令,並最終得到 count 為2 。

進行AOF重寫後，相當於把中間的計算過程略去。直接把計算得到的結果設定進redis，相當於僅執行了一條命令 set count 2。

可以使用BGREWRITEAOF命令來重寫AOF檔案。

重寫策略

重寫策略的參數設定：

auto-aof-rewrite-percentage 100

當前的AOF檔案大小超過上一次重寫時的AOF檔案大小的百分之多少時，會再次進行重寫，如果之前沒有重寫過，則以啟動時的AOF檔案大小為依據。

auto-aof-rewrite-min-size 64mb

限制了允許重寫的最小AOF檔案大小，通常在AOF檔案很小的時候，即使其中有些冗餘的命令也是可以忽略的。

RDB 優點

RDB 是一種表示某個即時點的 Redis 資料的緊湊檔案。RDB 檔案適合用於備份。例如，你可能想要每小時歸檔最近 24 小時的 RDB 檔案，每天儲存近 30 天的 RDB 快照集。這允許你很容易的恢複不同版本的資料集以容災。

RDB 非常適合於災難恢複，作為一個緊湊的單一檔案，可以被傳輸到遠端資料中心，或者是 Amazon S3(可能得加密)。

RDB 最大化了 Redis 的效能，因為 Redis 父進程持久化時唯一需要做的是啟動(fork)一個子進程，由子進程完成所有剩餘工作。父進程執行個體不需要執行像磁碟 IO 這樣的操作。

RDB 在重啟儲存了大資料集的執行個體時比 AOF 要快。

RDB 缺點

當你需要在 Redis 停止工作(例如停電)時最小化資料丟失，RDB 可能不太好。你可以配置不同的儲存點。然而，你通常每隔 5 分鐘或更久建立一個 RDB 快照集，所以一旦 Redis 因為任何原因沒有正確關閉而停止工作，你就得做好最近幾分鐘資料丟失的準備了。

RDB 需要經常調用 fork()子進程來持久化到磁碟。如果資料集很大的話，fork()比較耗時，結果就是，當資料集非常大並且 CPU 效能不夠強大的話，Redis 會停止服務用戶端幾毫秒甚至一秒。AOF 也需要 fork()，但是你可以調整多久頻率重寫日誌而不會有損(trade-off)持久性(durability)。

AOF 優點

使用 AOF Redis 會更具有可持久性(durable)：你可以有很多不同的 fsync 策略：沒有 fsync，每秒 fsync，每次請求時 fsync。使用預設的每秒 fsync 策略，寫效能也仍然很不錯(fsync 是由後台線程完成的，主線程繼續努力地執行寫請求)，即便你也就僅僅只損失一秒鐘的寫資料。

AOF 日誌是一個追加檔案，所以不需要定位，在斷電時也沒有損壞問題。即使由於某種原因檔案末尾是一個寫到一半的命令(磁碟滿或者其他原因),redis-check-aof 工具也可以很輕易的修複。

AOF 檔案裡麵包含一個接一個的操作，以易於理解和解析的格式儲存。你也可以輕易的匯出一個 AOF 檔案。例如，即使你不小心錯誤地使用 FLUSHALL 命令清空一切，如果此時並沒有執行重寫，你仍然可以儲存你的資料集，你只要停止伺服器，刪除最後一條命令，然後重啟 Redis 就可以。

AOF 缺點

對同樣的資料集，AOF 檔案通常要大於等價的 RDB 檔案。

AOF 可能比 RDB 慢，這取決於準確的 fsync 策略。通常 fsync 設定為每秒一次的話效能仍然很高，如果關閉 fsync，即使在很高的負載下也和 RDB 一樣的快。不過，即使在很大的寫負載情況下，RDB 還是能提供能好的最大延遲保證。

RDB和AOF如何取捨

通常來說，你應該同時使用這兩種持久化方法，以達到和 PostgreSQL 提供的一樣的資料安全程度。

如果你很關注你的資料，但是仍然可以接受災難時有幾分鐘的資料丟失，你可以只單獨使用 RDB。

有很多使用者單獨使用 AOF，但是我們並不鼓勵這樣，因為時常進行 RDB 快照集非常方便於Database Backup，啟動速度也較之快，還避免了 AOF 引擎的 bug。