文章目錄

• • 1 AOF（append only file）
  • • 1.1 AOF是什么
    • 1.2 AOF 持久化流程
    • 1.3 AOF 默認(rèn)不開(kāi)啟
    • 1.4 AOF 和RDB同時(shí)開(kāi)啟聽(tīng)誰(shuí)的
    • 1.5 AOF啟動(dòng)修復(fù)恢復(fù)
    • 1.6 AOF 同步頻率
    • 1.7 Rewrite壓縮
    • 1.8 優(yōu)勢(shì)
    • 1.9 劣勢(shì)
  • 2 小總結(jié)（which one）

1 AOF（append only file）

1.1 AOF是什么

以日志的形式來(lái)記錄每個(gè)寫(xiě)操作（增量保存），將redis 執(zhí)行過(guò)的所有寫(xiě)指令記錄下來(lái)（讀操作不記錄），只允許追加文件但不可以改寫(xiě)文件，reids 啟動(dòng)之初會(huì)讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，redis重啟的話(huà)就根據(jù)日志文件的內(nèi)容將寫(xiě)指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作

1.2 AOF 持久化流程

客戶(hù)端的請(qǐng)求寫(xiě)命令會(huì)被append追加到aof 緩沖區(qū)內(nèi)；

aof 緩沖區(qū)根據(jù)aof持久化策略（always，everysec，no）將操作sync同步到磁盤(pán)的aof文件中；

aof文件大小超過(guò)重寫(xiě)策略或手動(dòng)重寫(xiě)時(shí)，會(huì)對(duì)aof文件rewrite重寫(xiě)，壓縮aof文件容量

redis 服務(wù)重啟時(shí)，會(huì)重新load加載aof文件中的寫(xiě)操作達(dá)到數(shù)據(jù)恢復(fù)的目的；

1.3 AOF 默認(rèn)不開(kāi)啟

可以在redis.conf中配置文件名稱(chēng)，默認(rèn)為appendonly.aof
AOF文件的保存路徑，同RDB路徑一致

appendonly no# The name of the append only file (default: "appendonly.aof")appendfilename "appendonly.aof"

1.4 AOF 和RDB同時(shí)開(kāi)啟聽(tīng)誰(shuí)的

AOF 和RDB同時(shí)開(kāi)啟，redis 會(huì)默認(rèn)取AOF的數(shù)據(jù)（數(shù)據(jù)不會(huì)丟失）

1.5 AOF啟動(dòng)修復(fù)恢復(fù)

aof的備份機(jī)制和性能雖然和rdb不同，但是備份和恢復(fù)的操作同rdb一樣，都是拷貝備份文件，需要恢復(fù)時(shí)再拷貝到redis工作目錄，啟動(dòng)系統(tǒng)即加載

正常恢復(fù)
修改默認(rèn)的appendonly no 改為yes
將有數(shù)據(jù)的aof文件復(fù)制一份保存到對(duì)應(yīng)的目錄（查看目錄：config get dir）

恢復(fù)
重啟reids然后重新加載

異常恢復(fù)
修改默認(rèn)的appendonly no 改為yes
如果遇到aof文件損壞，通過(guò)/usr/loacal/bin/redis-check-aof --fix appendonly.aof 進(jìn)行恢復(fù)
備份被寫(xiě)壞的aof文件
恢復(fù)：重啟redis，然后重新加載

# redis-check-aof --fix appendonly.aof

1.6 AOF 同步頻率

始終同步，每次redis的寫(xiě)入都會(huì)立刻記入日志，性能較差但數(shù)據(jù)完整性較好

# appendfsync always

每秒同步，每秒記入日志一次，如果宕機(jī)，本秒的數(shù)據(jù)可能丟失

appendfsync everysec

redis不主動(dòng)同步，把同步時(shí)機(jī)交給操作系統(tǒng)

# appendfsync no

1.7 Rewrite壓縮

aof采用文件追加方式，文件會(huì)越來(lái)越大，為避免出現(xiàn)此種情況，新增了重寫(xiě)機(jī)制，當(dāng)aof文件的大小超過(guò)所設(shè)定的閾值時(shí)，redis就會(huì)啟動(dòng)aof文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集，可以使用命令bgrewriteaof

重寫(xiě)原理
aof文件持續(xù)增長(zhǎng)而過(guò)大時(shí)，會(huì)fork出一條新進(jìn)程來(lái)將文件重寫(xiě)（也是先寫(xiě)臨時(shí)文件最后再rename），reids4.0版本后的重寫(xiě)，是把rdb的快照，以二進(jìn)制的形式附在新的aof頭部，作為已有的歷史數(shù)據(jù)，替換原來(lái)的流水賬操作

no-appendfsync-on-rewrite no

觸發(fā)機(jī)制
redis會(huì)記錄上次重寫(xiě)時(shí)的aof大小，默認(rèn)配置是當(dāng)aof文件大小是上次rewrite后大小的一倍且文件大于64M時(shí)觸發(fā)

重寫(xiě)雖然可以節(jié)約大量磁盤(pán)空間，減少恢復(fù)時(shí)間，但是每次重寫(xiě)還是有一定的負(fù)擔(dān)，因此設(shè)定redis要滿(mǎn)足一定條件才會(huì)進(jìn)行重寫(xiě)

auto-aof-rewrite-percentage 設(shè)置重寫(xiě)的基準(zhǔn)值，文件達(dá)到100%時(shí)開(kāi)始重寫(xiě)（文件是原來(lái)重寫(xiě)后文件的兩倍時(shí)觸發(fā)）

auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

重寫(xiě)流程
bgrewriteaof觸發(fā)重寫(xiě)，判斷是否當(dāng)前有bgsave或bgrewriteaof在運(yùn)行，如果有，則等待該命令結(jié)束后再繼續(xù)執(zhí)行。

主進(jìn)程fork出子進(jìn)程執(zhí)行重寫(xiě)操作，保證主進(jìn)程不會(huì)阻塞

子進(jìn)程遍歷redis內(nèi)存中數(shù)據(jù)到臨時(shí)文件，客戶(hù)端的寫(xiě)請(qǐng)求同時(shí)寫(xiě)入aof_buf
緩沖區(qū)和aof_rewrite_buf重寫(xiě)緩沖區(qū)保證原aof文件完整以及新aof文件生成期間的新的數(shù)據(jù)修改動(dòng)作不會(huì)丟失

子進(jìn)程寫(xiě)完新的aof文件后，向主進(jìn)程發(fā)信號(hào)，父進(jìn)程更新統(tǒng)計(jì)信息，
主進(jìn)程把a(bǔ)of_rewrite_buf中的數(shù)據(jù)寫(xiě)入到新的aof文件

使用新的aof文件覆蓋舊的aof文件，完成aof重寫(xiě)

1.8 優(yōu)勢(shì)

備份機(jī)制更穩(wěn)健，丟失數(shù)據(jù)概率更低

可讀的日志文本，通過(guò)操作aof文件，可以處理誤操作

1.9 劣勢(shì)

比起RDB占用更多的磁盤(pán)空間
恢復(fù)備份速度慢
每次讀寫(xiě)同步的話(huà)，有一定的性能壓力
存在個(gè)別bug，造成不會(huì)恢復(fù)

2 小總結(jié)（which one）

官方推薦兩個(gè)都啟用
如果對(duì)數(shù)據(jù)不敏感，可以單獨(dú)選用RDB
不建議單獨(dú)用aof，因?yàn)榭赡軙?huì)出現(xiàn)bug
如果只是做純內(nèi)存緩存，可以都不用

總結(jié)

以上是生活随笔為你收集整理的9 Redis 持久化AOF的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。