Redis的AOF持久化分析

這篇文章主要講解了“Redis的AOF持久化分析”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Redis的AOF持久化分析”吧！

AOF持久化

與快照持久化不同，AOF持久化是將被執行的命令寫到aof文件末尾，在恢復時只需要從頭到尾執行一遍寫命令即可恢復數據，AOF在redis中默認也是沒有開啟的，需要我們手動開啟，開啟方式如下：

打開redis.conf配置文件，修改appendonly屬性值為yes，如下：

appendonly yes

另外幾個和AOF相關的屬性如下：

appendfilename "appendonly.aof"
# appendfsync always
appendfsync everysec
# appendfsync no
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

這幾個屬性的含義分別如下：

1.appendfilename表示生成的AOF備份文件的文件名。
2.appendfsync表示備份的時機，always表示每執行一個命令就備份一次，everysec表示每秒備份一次，no表示將備份時機交給操作系統。
3.no-appendfsync-on-rewrite表示在對aof文件進行壓縮時，是否執行同步操作。
4.最后兩行配置表示AOF文件的壓縮時機，這個我們一會再細說。

同時為了避免快照備份的影響，我們將快照備份關閉，關閉方式如下：

save ""
# save 900 1
# save 300 10
# save 60 10000

此時，當我們在redis中進行數據操作時，就會自動生成AOF的配置文件appendonly.aof，如下：

注意此時沒有dump.rdb文件，這時我們將redis關閉并重啟，會發現之前的數據都還在，這就是AOF備份的結果。

AOF備份的幾個關鍵點

1.通過上面的介紹，小伙伴們了解到appendfsync的取值一共有三種，我們在項目中首選everysec，always選項會嚴重降低redis性能。
2.使用everysec，最壞的情況下我們可能丟失1秒的數據。

AOF文件的重寫與壓縮

AOF備份有很多明顯的優勢，當然也有劣勢，那就是文件大小。隨著系統的運行，AOF的文件會越來越大，甚至把整個電腦的硬盤填滿，AOF文件的重寫與壓縮機制可以在一定程度上緩解這個問題。
當AOF的備份文件過大時，我們可以向redis發送一條bgrewriteaof命令進行文件重寫，如下：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
(0.71s)

bgrewriteaof的執行原理和我們上文說的bgsave的原理一致，這里我就不再贅述，因此bgsave執行過程中存在的問題在這里也一樣存在。

bgrewriteaof也可以自動執行，自動執行時間則依賴于auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置，auto-aof-rewrite-percentage 100表示當目前aof文件大小超過上一次重寫時的aof文件大小的百分之多少時會再次進行重寫，如果之前沒有重寫，則以啟動時的aof文件大小為依據，同時還要求AOF文件的大小至少要大于64M(auto-aof-rewrite-min-size 64mb)。

最佳實踐

1.如果redis只做緩存服務器，那么可以不使用任何持久化方式。
2.同時開啟兩種持久化方式，在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據, 因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整；RDB的數據不完整時，同時使用兩者時服務器重啟也只會找AOF文件。那要不要只使用AOF呢？ 作者建議不要，因為RDB更適合用于備份數據庫(AOF在不斷變化不好備份)， 快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。
3.因為RDB文件只用作后備用途，建議只在slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規則。
4.如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只load自己的AOF文件就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最后將rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上。默認超過原大小100%大小時重寫可以改到適當的數值。
5.如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個。

感謝各位的閱讀，以上就是“Redis的AOF持久化分析”的內容了，經過本文的學習后，相信大家對Redis的AOF持久化分析這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！