小編給大家分享一下redis中AOF持久化的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

成都創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供萊陽網(wǎng)站建設(shè)、萊陽做網(wǎng)站、萊陽網(wǎng)站設(shè)計(jì)、萊陽網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、萊陽企業(yè)網(wǎng)站模板建站服務(wù)，10多年萊陽做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

1、AOF簡介

Redis的持久化方式之一RDB是通過保存數(shù)據(jù)庫中的鍵值對來記錄數(shù)據(jù)庫的狀態(tài)。而另一種持久化方式 AOF 則是通過保存Redis服務(wù)器所執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)。

比如對于如下命令：

RDB 持久化方式就是將 str1,str2,str3 這三個鍵值對保存到 RDB文件中，而 AOF 持久化則是將執(zhí)行的 set,sadd,lpush 三個命令保存到 AOF 文件中。

2、AOF 配置

在 redis.conf 配置文件的 APPEND ONLY MODE 下：

①、appendonly：默認(rèn)值為no，也就是說redis 默認(rèn)使用的是rdb方式持久化，如果想要開啟 AOF 持久化方式，需要將 appendonly 修改為 yes。

②、appendfilename：aof文件名，默認(rèn)是"appendonly.aof"

③、appendfsync：aof持久化策略的配置；

no表示不執(zhí)行fsync，由操作系統(tǒng)保證數(shù)據(jù)同步到磁盤，速度最快，但是不太安全；

always表示每次寫入都執(zhí)行fsync，以保證數(shù)據(jù)同步到磁盤，效率很低；

everysec表示每秒執(zhí)行一次fsync，可能會導(dǎo)致丟失這1s數(shù)據(jù)。通常選擇 everysec ，兼顧安全性和效率。

④、no-appendfsync-on-rewrite：在aof重寫或者寫入rdb文件的時候，會執(zhí)行大量IO，此時對于everysec和always的aof模式來說，執(zhí)行fsync會造成阻塞過長時間，no-appendfsync-on-rewrite字段設(shè)置為默認(rèn)設(shè)置為no。如果對延遲要求很高的應(yīng)用，這個字段可以設(shè)置為yes，否則還是設(shè)置為no，這樣對持久化特性來說這是更安全的選擇。   設(shè)置為yes表示rewrite期間對新寫操作不fsync,暫時存在內(nèi)存中,等rewrite完成后再寫入，默認(rèn)為no，建議yes。Linux的默認(rèn)fsync策略是30秒。可能丟失30秒數(shù)據(jù)。默認(rèn)值為no。

⑤、auto-aof-rewrite-percentage：默認(rèn)值為100。aof自動重寫配置，當(dāng)目前aof文件大小超過上一次重寫的aof文件大小的百分之多少進(jìn)行重寫，即當(dāng)aof文件增長到一定大小的時候，Redis能夠調(diào)用bgrewriteaof對日志文件進(jìn)行重寫。當(dāng)前AOF文件大小是上次日志重寫得到AOF文件大小的二倍（設(shè)置為100）時，自動啟動新的日志重寫過程。

⑥、auto-aof-rewrite-min-size：64mb。設(shè)置允許重寫的最小aof文件大小，避免了達(dá)到約定百分比但尺寸仍然很小的情況還要重寫。

⑦、aof-load-truncated：aof文件可能在尾部是不完整的，當(dāng)redis啟動的時候，aof文件的數(shù)據(jù)被載入內(nèi)存。重啟可能發(fā)生在redis所在的主機(jī)操作系統(tǒng)宕機(jī)后，尤其在ext4文件系統(tǒng)沒有加上data=ordered選項(xiàng)，出現(xiàn)這種現(xiàn)象  redis宕機(jī)或者異常終止不會造成尾部不完整現(xiàn)象，可以選擇讓redis退出，或者導(dǎo)入盡可能多的數(shù)據(jù)。如果選擇的是yes，當(dāng)截?cái)嗟腶of文件被導(dǎo)入的時候，會自動發(fā)布一個log給客戶端然后load。如果是no，用戶必須手動redis-check-aof修復(fù)AOF文件才可以。默認(rèn)值為 yes。

3、開啟 AOF

將 redis.conf 的 appendonly 配置改為 yes 即可。

AOF 保存文件的位置和 RDB 保存文件的位置一樣，都是通過 redis.conf 配置文件的 dir 配置：

可以通過 config get dir 命令獲取保存的路徑。

4、AOF 文件恢復(fù)

重啟 Redis 之后就會進(jìn)行 AOF 文件的載入。

異常修復(fù)命令：redis-check-aof --fix 進(jìn)行修復(fù)

5、 AOF 重寫

由于AOF持久化是Redis不斷將寫命令記錄到 AOF 文件中，隨著Redis不斷的進(jìn)行，AOF 的文件會越來越大，文件越大，占用服務(wù)器內(nèi)存越大以及 AOF 恢復(fù)要求時間越長。為了解決這個問題，Redis新增了重寫機(jī)制，當(dāng)AOF文件的大小超過所設(shè)定的閾值時，Redis就會啟動AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集。可以使用命令 bgrewriteaof 來重新。

比如對于如下命令：

如果不進(jìn)行 AOF 文件重寫，那么 AOF 文件將保存四條 SADD 命令，如果使用AOF 重寫，那么AOF 文件中將只會保留下面一條命令：

也就是說 AOF 文件重寫并不是對原文件進(jìn)行重新整理，而是直接讀取服務(wù)器現(xiàn)有的鍵值對，然后用一條命令去代替之前記錄這個鍵值對的多條命令，生成一個新的文件后去替換原來的 AOF 文件。

 　　AOF 文件重寫觸發(fā)機(jī)制：通過 redis.conf 配置文件中的 auto-aof-rewrite-percentage：默認(rèn)值為100，以及auto-aof-rewrite-min-size：64mb 配置，也就是說默認(rèn)Redis會記錄上次重寫時的AOF大小，默認(rèn)配置是當(dāng)AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發(fā)。

　　這里再提一下，我們知道 Redis 是單線程工作，如果 重寫 AOF 需要比較長的時間，那么在重寫 AOF 期間，Redis將長時間無法處理其他的命令，這顯然是不能忍受的。Redis為了克服這個問題，解決辦法是將 AOF 重寫程序放到子程序中進(jìn)行，這樣有兩個好處：

①、子進(jìn)程進(jìn)行 AOF 重寫期間，服務(wù)器進(jìn)程（父進(jìn)程）可以繼續(xù)處理其他命令。

②、子進(jìn)程帶有父進(jìn)程的數(shù)據(jù)副本，使用子進(jìn)程而不是線程，可以在避免使用鎖的情況下，保證數(shù)據(jù)的安全性。

使用子進(jìn)程解決了上面的問題，但是新問題也產(chǎn)生了：因?yàn)樽舆M(jìn)程在進(jìn)行 AOF 重寫期間，服務(wù)器進(jìn)程依然在處理其它命令，這新的命令有可能也對數(shù)據(jù)庫進(jìn)行了修改操作，使得當(dāng)前數(shù)據(jù)庫狀態(tài)和重寫后的 AOF 文件狀態(tài)不一致。

為了解決這個數(shù)據(jù)狀態(tài)不一致的問題，Redis 服務(wù)器設(shè)置了一個 AOF 重寫緩沖區(qū)，這個緩沖區(qū)是在創(chuàng)建子進(jìn)程后開始使用，當(dāng)Redis服務(wù)器執(zhí)行一個寫命令之后，就會將這個寫命令也發(fā)送到 AOF 重寫緩沖區(qū)。當(dāng)子進(jìn)程完成 AOF 重寫之后，就會給父進(jìn)程發(fā)送一個信號，父進(jìn)程接收此信號后，就會調(diào)用函數(shù)將 AOF 重寫緩沖區(qū)的內(nèi)容都寫到新的 AOF 文件中。

這樣將 AOF 重寫對服務(wù)器造成的影響降到了最低。

6、AOF的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

①、AOF 持久化的方法提供了多種的同步頻率，即使使用默認(rèn)的同步頻率每秒同步一次，Redis 最多也就丟失 1 秒的數(shù)據(jù)而已。

②、AOF 文件使用 Redis 命令追加的形式來構(gòu)造，因此，即使 Redis 只能向 AOF 文件寫入命令的片斷，使用 redis-check-aof 工具也很容易修正 AOF 文件。

③、AOF 文件的格式可讀性較強(qiáng)，這也為使用者提供了更靈活的處理方式。例如，如果我們不小心錯用了 FLUSHALL 命令，在重寫還沒進(jìn)行時，我們可以手工將最后的 FLUSHALL 命令去掉，然后再使用 AOF 來恢復(fù)數(shù)據(jù)。

缺點(diǎn)：

①、對于具有相同數(shù)據(jù)的的 Redis，AOF 文件通常會比 RDF 文件體積更大。

②、雖然 AOF 提供了多種同步的頻率，默認(rèn)情況下，每秒同步一次的頻率也具有較高的性能。但在 Redis 的負(fù)載較高時，RDB 比 AOF 具好更好的性能保證。

③、RDB 使用快照的形式來持久化整個 Redis 數(shù)據(jù)，而 AOF 只是將每次執(zhí)行的命令追加到 AOF 文件中，因此從理論上說，RDB 比 AOF 方式更健壯。官方文檔也指出，AOF 的確也存在一些 BUG，這些 BUG 在 RDB 沒有存在。

 　　那么對于 AOF 和 RDB 兩種持久化方式，我們應(yīng)該如何選擇呢？

如果可以忍受一小段時間內(nèi)數(shù)據(jù)的丟失，毫無疑問使用 RDB 是最好的，定時生成 RDB 快照（snapshot）非常便于進(jìn)行數(shù)據(jù)庫備份， 并且 RDB 恢復(fù)數(shù)據(jù)集的速度也要比 AOF 恢復(fù)的速度要快，而且使用 RDB 還可以避免 AOF 一些隱藏的 bug；否則就使用 AOF 重寫。但是一般情況下建議不要單獨(dú)使用某一種持久化機(jī)制，而是應(yīng)該兩種一起用，在這種情況下,當(dāng)redis重啟的時候會優(yōu)先載入AOF文件來恢復(fù)原始的數(shù)據(jù)，因?yàn)樵谕ǔＧ闆r下AOF文件保存的數(shù)據(jù)集要比RDB文件保存的數(shù)據(jù)集要完整。Redis后期官方可能都有將兩種持久化方式整合為一種持久化模型。

以上是“Redis中AOF持久化的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！