Redis中AOF持久化的示例分析

小編給大家分享一下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 文件中將只會保留下面一條命令：

　　也就是說 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后期官方可能都有將兩種持久化方式整合為一種持久化模型。

以上是“Redis中AOF持久化的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！