Redis詳解（七）- AOF 持久化
目錄
上一篇文章我們介紹了Redis的RDB持久化，RDB 持久化存在一個缺點是一定時間內做一次備份，如果redis意外down掉的話，就會丟失最後一次快照後的所有修改(資料有丟失)。對於資料完整性要求很嚴格的需求，怎麼解決呢？
本篇部落格接著來介紹Redis的另一種持久化方式——AOF。
回到頂部1、AOF簡介
Redis的持久化方式之一RDB是通過儲存資料庫中的鍵值對來記錄資料庫的狀態。而另一種持久化方式 AOF 則是通過儲存Redis伺服器所執行的寫命令來記錄資料庫狀態。
比如對於如下命令：
RDB 持久化方式就是將 str1,str2,str3 這三個鍵值對儲存到 RDB檔案中，而 AOF 持久化則是將執行的 set,sadd,lpush 三個命令儲存到 AOF 檔案中。
回到頂部2、AOF 配置
在 redis.conf 配置檔案的APPEND ONLY MODE 下：
①、appendonly：預設值為no，也就是說redis 預設使用的是rdb方式持久化，如果想要開啟 AOF 持久化方式，需要將 appendonly 修改為 yes。
②、appendfilename：aof檔名，預設是"appendonly.aof"
③、appendfsync：aof持久化策略的配置；
no表示不執行fsync，由作業系統保證資料同步到磁碟，速度最快，但是不太安全；
always表示每次寫入都執行fsync，以保證資料同步到磁碟，效率很低；
everysec表示每秒執行一次fsync，可能會導致丟失這1s資料。通常選擇 everysec ，兼顧安全性和效率。
④、no-appendfsync-on-rewrite：在aof重寫或者寫入rdb檔案的時候，會執行大量IO，此時對於everysec和always的aof模式來說，執行fsync會造成阻塞過長時間，no-appendfsync-on-rewrite欄位設定為預設設定為no。如果對延遲要求很高的應用，這個欄位可以設定為yes，否則還是設定為no，這樣對持久化特性來說這是更安全的選擇。 設定為yes表示rewrite期間對新寫操作不fsync,暫時存在記憶體中,等rewrite完成後再寫入，預設為no，建議yes。Linux的預設fsync策略是30秒。可能丟失30秒資料。預設值為no。
⑤、auto-aof-rewrite-percentage：預設值為100。aof自動重寫配置，當目前aof檔案大小超過上一次重寫的aof檔案大小的百分之多少進行重寫，即當aof檔案增長到一定大小的時候，Redis能夠呼叫bgrewriteaof對日誌檔案進行重寫。當前AOF檔案大小是上次日誌重寫得到AOF檔案大小的二倍（設定為100）時，自動啟動新的日誌重寫過程。
⑥、auto-aof-rewrite-min-size：64mb。設定允許重寫的最小aof檔案大小，避免了達到約定百分比但尺寸仍然很小的情況還要重寫。
⑦、aof-load-truncated：aof檔案可能在尾部是不完整的，當redis啟動的時候，aof檔案的資料被載入記憶體。重啟可能發生在redis所在的主機作業系統宕機後，尤其在ext4檔案系統沒有加上data=ordered選項，出現這種現象 redis宕機或者異常終止不會造成尾部不完整現象，可以選擇讓redis退出，或者匯入儘可能多的資料。如果選擇的是yes，當截斷的aof檔案被匯入的時候，會自動釋出一個log給客戶端然後load。如果是no，使用者必須手動redis-check-aof修復AOF檔案才可以。預設值為 yes。
回到頂部3、開啟 AOF
將 redis.conf 的appendonly 配置改為 yes 即可。
AOF 儲存檔案的位置和 RDB 儲存檔案的位置一樣，都是通過 redis.conf 配置檔案的 dir 配置：
可以通過config get dir 命令獲取儲存的路徑。
回到頂部4、AOF 檔案恢復
重啟 Redis 之後就會進行 AOF 檔案的載入。
異常修復命令：redis-check-aof --fix 進行修復
回到頂部5、 AOF 重寫
由於AOF持久化是Redis不斷將寫命令記錄到 AOF 檔案中，隨著Redis不斷的進行，AOF 的檔案會越來越大，檔案越大，佔用伺服器記憶體越大以及 AOF 恢復要求時間越長。為了解決這個問題，Redis新增了重寫機制，當AOF檔案的大小超過所設定的閾值時，Redis就會啟動AOF檔案的內容壓縮，只保留可以恢復資料的最小指令集。可以使用命令 bgrewriteaof 來重新。
比如對於如下命令：
如果不進行 AOF 檔案重寫，那麼 AOF 檔案將儲存四條 SADD 命令，如果使用AOF 重寫，那麼AOF 檔案中將只會保留下面一條命令：
| 1 |
sadd animals"dog""tiger""panda""lion""cat"
|
也就是說 AOF 檔案重寫並不是對原檔案進行重新整理，而是直接讀取伺服器現有的鍵值對，然後用一條命令去代替之前記錄這個鍵值對的多條命令，生成一個新的檔案後去替換原來的 AOF 檔案。
AOF 檔案重寫觸發機制：通過 redis.conf 配置檔案中的 auto-aof-rewrite-percentage：預設值為100，以及auto-aof-rewrite-min-size：64mb 配置，也就是說預設Redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發。
這裡再提一下，我們知道 Redis 是單執行緒工作，如果 重寫 AOF 需要比較長的時間，那麼在重寫 AOF 期間，Redis將長時間無法處理其他的命令，這顯然是不能忍受的。Redis為了克服這個問題，解決辦法是將 AOF 重寫程式放到子程式中進行，這樣有兩個好處：
①、子程序進行 AOF 重寫期間，伺服器程序（父程序）可以繼續處理其他命令。
②、子程序帶有父程序的資料副本，使用子程序而不是執行緒，可以在避免使用鎖的情況下，保證資料的安全性。
使用子程序解決了上面的問題，但是新問題也產生了：因為子程序在進行 AOF 重寫期間，伺服器程序依然在處理其它命令，這新的命令有可能也對資料庫進行了修改操作，使得當前資料庫狀態和重寫後的 AOF 檔案狀態不一致。
為了解決這個資料狀態不一致的問題，Redis 伺服器設定了一個 AOF 重寫緩衝區，這個緩衝區是在建立子程序後開始使用，當Redis伺服器執行一個寫命令之後，就會將這個寫命令也傳送到 AOF 重寫緩衝區。當子程序完成 AOF 重寫之後，就會給父程序傳送一個訊號，父程序接收此訊號後，就會呼叫函式將 AOF 重寫緩衝區的內容都寫到新的 AOF 檔案中。
這樣將 AOF 重寫對伺服器造成的影響降到了最低。
回到頂部6、AOF的優缺點
優點：
①、AOF 持久化的方法提供了多種的同步頻率，即使使用預設的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的資料而已。
②、AOF 檔案使用 Redis 命令追加的形式來構造，因此，即使 Redis 只能向 AOF 檔案寫入命令的片斷，使用 redis-check-aof 工具也很容易修正 AOF 檔案。
③、AOF 檔案的格式可讀性較強，這也為使用者提供了更靈活的處理方式。例如，如果我們不小心錯用了 FLUSHALL 命令，在重寫還沒進行時，我們可以手工將最後的 FLUSHALL 命令去掉，然後再使用 AOF 來恢復資料。
缺點：
①、對於具有相同資料的的 Redis，AOF 檔案通常會比 RDF 檔案體積更大。
②、雖然 AOF 提供了多種同步的頻率，預設情況下，每秒同步一次的頻率也具有較高的效能。但在 Redis 的負載較高時，RDB 比 AOF 具好更好的效能保證。
③、RDB 使用快照的形式來持久化整個 Redis 資料，而 AOF 只是將每次執行的命令追加到 AOF 檔案中，因此從理論上說，RDB 比 AOF 方式更健壯。官方文件也指出，AOF 的確也存在一些 BUG，這些 BUG 在 RDB 沒有存在。
那麼對於 AOF 和 RDB 兩種持久化方式，我們應該如何選擇呢？
如果可以忍受一小段時間內資料的丟失，毫無疑問使用 RDB 是最好的，定時生成 RDB 快照（snapshot）非常便於進行資料庫備份， 並且 RDB 恢復資料集的速度也要比 AOF 恢復的速度要快，而且使用 RDB 還可以避免 AOF 一些隱藏的 bug；否則就使用 AOF 重寫。但是一般情況下建議不要單獨使用某一種持久化機制，而是應該兩種一起用，在這種情況下,當redis重啟的時候會優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。Redis後期官方可能都有將兩種持久化方式整合為一種持久化模型。
回到頂部7、RDB-AOF混合持久化
這裡補充一個知識點，在Redis4.0之後，既上一篇文章介紹的RDB和這篇文章介紹的AOF兩種持久化方式，又新增了RDB-AOF混合持久化方式。
這種方式結合了RDB和AOF的優點，既能快速載入又能避免丟失過多的資料。
具體配置為：
aof-use-rdb-preamble
設定為yes表示開啟，設定為no表示禁用。
當開啟混合持久化時，主程序先fork出子程序將現有記憶體副本全量以RDB方式寫入aof檔案中，然後將緩衝區中的增量命令以AOF方式寫入aof檔案中，寫入完成後通知主程序更新相關資訊，並將新的含有 RDB和AOF兩種格式的aof檔案替換舊的aof檔案。
簡單來說：混合持久化方式產生的檔案一部分是RDB格式，一部分是AOF格式。
這種方式優點我們很好理解，缺點就是不能相容Redis4.0之前版本的備份檔案了。