Redis詳解（二）——AOF 前言 RDB 持久化存在一個缺點是一定時間內做一次備份，如果redis意外down掉的話，就會丟失最後一次快照後的所有修改(數據有丟失)。對於數據完整性要求很嚴格的需求，怎麼解決呢？ 本篇博客接著來介紹Redis的另一種持久化方式——AOF。 1、AOF簡介 Redi ...
Redis詳解（二）——AOF
前言
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 文件中將只會保留下麵一條命令：
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 VS AOF
