Redis中AOF持久化的範例分析

1、AOF簡介

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，以保證資料同步fsync，以保證資料同步fsync，以保證資料都執行fsync，以保證資料同步使用到磁碟，效率很低；

一秒執行一次fsync的選項"everysec"可能會導致資料在這1秒內遺失。通常選擇 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檔案的大小達到上次進行日誌重寫時的兩倍（設定為100）時，將自動啟動新的日誌重寫過程。

auto-aof-rewrite-min-size設定為64MB。為了避免在達到了約定百分比時仍需要進行重寫，可以設定最小的aof檔案大小。

　　⑦、aof-load-truncated：aof檔案可能在尾部是不完整的，當redis啟動的時候，aof檔案的資料被載入記憶體。重啟可能發生在redis所在的主機作業系統宕機後，尤其在ext4檔案系統沒有加上data=ordered選項，出現這種現象  redis宕機或異常終止不會造成尾部不完整現象，可以選擇讓redis退出，或導入盡可能多的數據。一旦選擇了yes選項，在截斷的aof檔案被匯入時，將自動向客戶端發送日誌並進行載入。若答案是否定的，使用者需手動執行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 存在著一些 RDB 沒有的 BUG。

 　　那麼對於 AOF 和 RDB 兩種持久化方式，我們該如何選擇呢？

　　如果可以忍受一小段時間內資料的遺失，毫無疑問使用RDB 是最好的，定時產生RDB 快照（snapshot）非常便於進行資料庫備份， 並且RDB 還原資料集的速度也要比AOF 恢復的速度要快，使用RDB 還可以避免AOF 一些隱藏的bug；否則就使用AOF 重寫。但一般情況下建議不要單獨使用某一種持久化機制，而是應該兩種一起用，在這種情況下,當redis重啟的時候會優先載入AOF檔來恢復原始的數據，因為在通常情況下AOF檔案保存的資料集比RDB檔案保存的資料集要完整。或許在未來，Redis官方會將兩種持久化方式合併成持久化模式。

以上是Redis中AOF持久化的範例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！