Redis的AOF持久化分析

這篇文章主要講解了“Redis的AOF持久化分析”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“Redis的AOF持久化分析”吧！

AOF持久化

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

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

appendonly yes

另外幾個(gè)和AOF相關(guān)的屬性如下：

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

這幾個(gè)屬性的含義分別如下：

1.appendfilename表示生成的AOF備份文件的文件名。
2.appendfsync表示備份的時(shí)機(jī)，always表示每執(zhí)行一個(gè)命令就備份一次，everysec表示每秒備份一次，no表示將備份時(shí)機(jī)交給操作系統(tǒng)。
3.no-appendfsync-on-rewrite表示在對(duì)aof文件進(jìn)行壓縮時(shí)，是否執(zhí)行同步操作。
4.最后兩行配置表示AOF文件的壓縮時(shí)機(jī)，這個(gè)我們一會(huì)再細(xì)說(shuō)。

同時(shí)為了避免快照備份的影響，我們將快照備份關(guān)閉，關(guān)閉方式如下：

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

此時(shí)，當(dāng)我們?cè)趓edis中進(jìn)行數(shù)據(jù)操作時(shí)，就會(huì)自動(dòng)生成AOF的配置文件appendonly.aof，如下：

注意此時(shí)沒有dump.rdb文件，這時(shí)我們將redis關(guān)閉并重啟，會(huì)發(fā)現(xiàn)之前的數(shù)據(jù)都還在，這就是AOF備份的結(jié)果。

AOF備份的幾個(gè)關(guān)鍵點(diǎn)

1.通過(guò)上面的介紹，小伙伴們了解到appendfsync的取值一共有三種，我們?cè)陧?xiàng)目中首選everysec，always選項(xiàng)會(huì)嚴(yán)重降低redis性能。
2.使用everysec，最壞的情況下我們可能丟失1秒的數(shù)據(jù)。

AOF文件的重寫與壓縮

AOF備份有很多明顯的優(yōu)勢(shì)，當(dāng)然也有劣勢(shì)，那就是文件大小。隨著系統(tǒng)的運(yùn)行，AOF的文件會(huì)越來(lái)越大，甚至把整個(gè)電腦的硬盤填滿，AOF文件的重寫與壓縮機(jī)制可以在一定程度上緩解這個(gè)問題。
當(dāng)AOF的備份文件過(guò)大時(shí)，我們可以向redis發(fā)送一條bgrewriteaof命令進(jìn)行文件重寫，如下：

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

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

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

最佳實(shí)踐

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

感謝各位的閱讀，以上就是“Redis的AOF持久化分析”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)Redis的AOF持久化分析這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！