AOF 被稱為追加模式，或日志模式，是 Redis 提供的另一種持久化策略，它能夠存儲(chǔ) Redis 服務(wù)器已經(jīng)執(zhí)行過的的命令，并且只記錄對內(nèi)存有過修改的命令，這種數(shù)據(jù)記錄方法，被叫做“增量復(fù)制”，其默認(rèn)存儲(chǔ)文件為
appendonly.aof。

成都創(chuàng)新互聯(lián)專注于網(wǎng)站建設(shè)|網(wǎng)站建設(shè)維護(hù)|優(yōu)化|托管以及網(wǎng)絡(luò)推廣，積累了大量的網(wǎng)站設(shè)計(jì)與制作經(jīng)驗(yàn)，為許多企業(yè)提供了網(wǎng)站定制設(shè)計(jì)服務(wù)，案例作品覆蓋成都陽光房等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷售的產(chǎn)品，結(jié)合品牌形象的塑造，量身制作品質(zhì)網(wǎng)站。

開啟AOF持久化

AOF 機(jī)制默認(rèn)處于未開啟狀態(tài)，可以通過修改 Redis 配置文件開啟 AOF，如下所示：

1) Windows系統(tǒng)

執(zhí)行如下操作：

#修改配置文件，把no改為 yes
appendonly yes
#確定存儲(chǔ)文件名是否正確
appendfilename "appendonly.aof"
#重啟服務(wù)器
redis-server --service-stop
redis-server --service-start

2) Linux系統(tǒng)

執(zhí)行如下操作：

#修改配置文件：
vim /etc/redis/redis.conf
appendonly yes # 把 no 改為 yes
#確定存儲(chǔ)文件名是否正確
appendfilename "appendonly.aof"
#重啟服務(wù)：
sudo /etc/init.d/redis-server restart

提示：本節(jié)建議在您在 Linux 系統(tǒng)上操作 Redis，否則一些 AOF 的性能無法體現(xiàn)。

AOF持久化機(jī)制

每當(dāng)有一個(gè)修改數(shù)據(jù)庫的命令被執(zhí)行時(shí)，服務(wù)器就將命令寫入到 appendonly.aof 文件中，該文件存儲(chǔ)了服務(wù)器執(zhí)行過的所有修改命令，因此，只要服務(wù)器重新執(zhí)行一次 .aof 文件，就可以實(shí)現(xiàn)還原數(shù)據(jù)的目的，這個(gè)過程被形象地稱之為“
命令重演”。

1) 寫入機(jī)制

Redis 在收到客戶端修改命令后，先進(jìn)行相應(yīng)的校驗(yàn)，如果沒問題，就立即將該命令存追加到 .aof 文件中，也就是先存到磁盤中，然后服務(wù)器再執(zhí)行命令。這樣就算遇到了突發(fā)的宕機(jī)情況情況，也只需將存儲(chǔ)到  .aof 文件中的命令，進(jìn)行一次“命令重演”就可以恢復(fù)到宕機(jī)前的狀態(tài)。

在上述執(zhí)行過程中，有一個(gè)很重要的環(huán)節(jié)就是命令的寫入，這是一個(gè) IO 操作。Redis 為了提升寫入效率，它不會(huì)將內(nèi)容直接寫入到磁盤中，而是將其放到一個(gè)內(nèi)存緩存區(qū)（buffer）中，等到緩存區(qū)被填滿時(shí)才真正將緩存區(qū)中的內(nèi)容寫入到磁盤里。

2) 重寫機(jī)制

Redis 在長期運(yùn)行的過程中，aof 文件會(huì)越變越長。如果機(jī)器宕機(jī)重啟，“重演”整個(gè) aof 文件會(huì)非常耗時(shí)，導(dǎo)致長時(shí)間 Redis 無法對外提供服務(wù)。因此就需要對 aof 文件做一下“瘦身”運(yùn)動(dòng)。

為了讓 aof 文件的大小控制在合理的范圍內(nèi)，Redis 提供了 AOF 重寫機(jī)制，手動(dòng)執(zhí)行
BGREWRITEAOF命令，開始重寫 aof 文件，如下所示：

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

通過上述操作后，服務(wù)器會(huì)生成一個(gè)新的 aof 文件，該文件具有以下特點(diǎn)：

• 新的 aof 文件記錄的數(shù)據(jù)庫數(shù)據(jù)和原 aof 文件記錄的數(shù)據(jù)庫數(shù)據(jù)完全一致；
• 新的 aof 文件會(huì)使用盡可能少的命令來記錄數(shù)據(jù)庫數(shù)據(jù)，因此新的 aof 文件的體積會(huì)小很多；
• AOF 重寫期間，服務(wù)器不會(huì)被阻塞，它可以正常處理客戶端發(fā)送的命令。

下表對原有 aof 文件和新生成的 aof 文件做了對比，如下所示：

重寫機(jī)制AOF文件對比

原有aof文件	重寫后aof文件
select 0	SELECT 0
sadd myset Jack	SADD myset Jack Helen JJ Lisa
sadd myset Helen	SET msg 'hello tarena'
sadd myset JJ	RPUSH num 4 6 8
sadd myset Lisa
INCR number
INCR number
DEL number
SET message 'www.baidu.com'
SET message 'www.biancheng.net'
RPUSH num 2 4 6
RPUSH num 8
LPOP num

從上表可以看出，新生成的 aof 文件中，它的命令格式做了很大程度的簡化。

3) 自動(dòng)觸發(fā)AOF重寫

Redis 為自動(dòng)觸發(fā) AOF 重寫功能，提供了相應(yīng)的配置策略。如下所示：修改 Redis 配置文件，讓服務(wù)器自動(dòng)執(zhí)行 BGREWRITEAOF 命令。

#默認(rèn)配置項(xiàng)
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb #表示觸發(fā)AOF重寫的最小文件體積,大于或等于64MB自動(dòng)觸發(fā)。

該配置項(xiàng)表示：觸發(fā)重寫所需要的 aof 文件體積百分比，只有當(dāng) aof 文件的增量大于 100% 時(shí)才進(jìn)行重寫，也就是大一倍。比如，第一次重寫時(shí)文件大小為 64M，那么第二次觸發(fā)重寫的體積為 128M，第三次重寫為 256M，以此類推。如果將百分比值設(shè)置為 0 就表示關(guān)閉 AOF 自動(dòng)重寫功能。

AOF策略配置

在上述介紹寫入機(jī)制的過程中，如果遇到宕機(jī)前，緩存內(nèi)的數(shù)據(jù)未能寫入到磁盤中，那么數(shù)據(jù)仍然會(huì)有丟失的風(fēng)險(xiǎn)。服務(wù)器宕機(jī)時(shí)，丟失命令的數(shù)量，取決于命令被寫入磁盤的時(shí)間，越早地把命令寫入到磁盤中，發(fā)生意外時(shí)丟失的數(shù)據(jù)就會(huì)越少，否則越多。

Redis 為數(shù)據(jù)的安全性考慮，同樣為 AOF 持久化提供了策略配置，打開 Redis 配置文件，如下圖所示：

上述配置策略說明如下：

• Always：服務(wù)器每寫入一個(gè)命令，就調(diào)用一次 fsync 函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務(wù)器出現(xiàn)故障，也不會(huì)丟失任何已經(jīng)成功執(zhí)行的命令數(shù)據(jù)，但是其執(zhí)行速度較慢；
• Everysec（默認(rèn)）：服務(wù)器每一秒調(diào)用一次 fsync 函數(shù)，將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務(wù)器出現(xiàn)故障，最多只丟失一秒鐘內(nèi)的執(zhí)行的命令數(shù)據(jù)，通常都使用它作為 AOF 配置策略；
• No：服務(wù)器不主動(dòng)調(diào)用 fsync 函數(shù)，由操作系統(tǒng)決定何時(shí)將緩沖區(qū)里面的命令寫入到硬盤。這種模式下，服務(wù)器遭遇意外停機(jī)時(shí)，丟失命令的數(shù)量是不確定的，所以這種策略，不確定性較大，不安全。

注意：Linux 系統(tǒng)的 fsync() 函數(shù)可以將指定文件的內(nèi)容從內(nèi)核緩存刷到硬盤中。

由于是 fsync 是磁盤 IO 操作，所以它很慢！如果 Redis 執(zhí)行一條指令就要 fsync 一次（Always），那么 Redis 高性能將嚴(yán)重受到影響。

在生產(chǎn)環(huán)境的服務(wù)器中，Redis 通常是每隔 1s 左右執(zhí)行一次 fsync 操作（ Everysec），這樣既保持了高性能，也讓數(shù)據(jù)盡可能的少丟失。最后一種策略（No），讓操作系統(tǒng)來決定何時(shí)將數(shù)據(jù)同步到磁盤，這種策略存在許多不確定性，所以不建議使用。

從三種策略的運(yùn)行速度來看，Always 的速度最慢，而 Everysec 和 No 都很快。

AOF和RDB對比

RDB與AOF持久化對比

RDB持久化	AOF持久化
全量備份，一次保存整個(gè)數(shù)據(jù)庫。	增量備份，一次只保存一個(gè)修改數(shù)據(jù)庫的命令。
每次執(zhí)行持久化操作的間隔時(shí)間較長。	保存的間隔默認(rèn)為一秒鐘（Everysec）
數(shù)據(jù)保存為二進(jìn)制格式，其還原速度快。	使用文本格式還原數(shù)據(jù)，所以數(shù)據(jù)還原速度一般。
執(zhí)行 SAVE 命令時(shí)會(huì)阻塞服務(wù)器，但手動(dòng)或者自動(dòng)觸發(fā)的 BGSAVE 不會(huì)阻塞服務(wù)器	AOF持久化無論何時(shí)都不會(huì)阻塞服務(wù)器。

如果進(jìn)行數(shù)據(jù)恢復(fù)時(shí)，既有 dump.rdb文件，又有 appendonly.aof 文件，您應(yīng)該先通過 appendonly.aof 恢復(fù)數(shù)據(jù)，這能最大程度地保證數(shù)據(jù)的安全性。