為什么需要AOF?

使用 RDB 持久化有一個風(fēng)險，它可能會造成最新數(shù)據(jù)丟失的風(fēng)險。因為 RDB 的持久化有一定的時間間隔，在這個時間段內(nèi)如果 Redis 服務(wù)意外終止的話，就會造成最新的數(shù)據(jù)全部丟失。

可能會操作 Redis 服務(wù)意外終止的條件：

• 安裝 Redis 的機器停止運行，藍屏或者系統(tǒng)崩潰；
• 安裝 Redis 的機器出現(xiàn)電源故障，例如突然斷電；
• 使用 kill -9 Redis_PID 等。

那么如何解決以上的這些問題呢？Redis 為我們提供了另一種持久化的方案——AOF。

概念

AOF（Append Only File）中文是附加到文件，顧名思義 AOF 可以把 Redis 每個鍵值對操作都記錄到文件（appendonly.aof）中。

持久化查詢和設(shè)置

1. 查詢AOF啟動狀態(tài)

使用 config get appendonly命令，如下圖所示：

其中，第一行為 AOF 文件的名稱，而最后一行表示 AOF 啟動的狀態(tài)，yes 表示已啟動，no 表示未啟動。

2. 開啟AOF持久化

Redis 默認是關(guān)閉 AOF 持久化的，想要開啟 AOF 持久化，有以下兩種方式：

• 通過命令行的方式；
• 通過修改配置文件的方式（redis.conf）。

下面分別來看以上兩種方式的實現(xiàn)。

2.1 命令行啟動AOF

命令行啟動 AOF，使用 config set appendonly yes 命令，如下圖所示：

命令行啟動 AOF 的優(yōu)缺點：命令行啟動優(yōu)點是無需重啟 Redis 服務(wù)，缺點是如果 Redis 服務(wù)重啟，則之前使用命令行設(shè)置的配置就會失效。

2.2 配置文件啟動 AOF

Redis 的配置文件在它的根路徑下的 redis.conf 文件中，獲取 Redis 的根目錄可以使用命令 config get dir 獲取，如下圖所示：

![在這里插入圖片描述](https://img-blog.csdnimg.cn/direct/7de3d3dc7bee430ea213231bd7da1f71.png

只需要在配置文件中設(shè)置 appendonly yes 即可，默認 appendonly no 表示關(guān)閉 AOF 持久化。 配置文件啟動 AOF 的優(yōu)缺點：修改配置文件的缺點是每次修改配置文件都要重啟 Redis 服務(wù)才能生效，優(yōu)點是無論重啟多少次 Redis 服務(wù)，配置文件中設(shè)置的配置信息都不會失效。

3. 觸發(fā)持久化

AOF 持久化開啟之后，只要滿足一定條件，就會觸發(fā) AOF 持久化。AOF 的觸發(fā)條件分為兩種：自動觸發(fā)和手動觸發(fā)。

3.1 自動觸發(fā)

有兩種情況可以自動觸發(fā) AOF 持久化，分為是：滿足 AOF 設(shè)置的策略觸發(fā)和滿足 AOF 重寫觸發(fā)。其中，AOF 重寫觸發(fā)會在本文的后半部分詳細介紹，這里重點來說 AOF 持久化策略都有哪些。 AOF 持久化策略，分為以下三種：

• always：每條 Redis 操作命令都會寫入磁盤，最多丟失一條數(shù)據(jù)；
• everysec：每秒鐘寫入一次磁盤，最多丟失一秒的數(shù)據(jù)；
• no：不設(shè)置寫入磁盤的規(guī)則，根據(jù)當(dāng)前操作系統(tǒng)來決定何時寫入磁盤，Linux 默認 30s 寫入一次數(shù)據(jù)至磁盤。

這三種配置可以在 Redis 的配置文件（redis.conf）中設(shè)置，如下代碼所示：

# 開啟每秒寫入一次的持久化策略
appendfsync everysec

小貼士：因為每次寫入磁盤都會對 Redis 的性能造成一定的影響，所以要根據(jù)用戶的實際情況設(shè)置相應(yīng)的策略，一般設(shè)置每秒寫入一次磁盤的頻率就可以滿足大部分的使用場景了。

觸發(fā)自動持久化的兩種情況，如下圖所示：

3.3 手動觸發(fā)

在客戶端執(zhí)行 bgrewriteaof 命令就可以手動觸發(fā) AOF 持久化，如下圖所示：

可以看出執(zhí)行完 bgrewriteaof 命令之后，AOF 持久化就會被觸發(fā)。

4. AOF 文件重寫

AOF 是通過記錄 Redis 的執(zhí)行命令來持久化（保存）數(shù)據(jù)的，所以隨著時間的流逝 AOF 文件會越來越多，這樣不僅增加了服務(wù)器的存儲壓力，也會造成 Redis 重啟速度變慢，為了解決這個問題 Redis 提供了 AOF 重寫的功能。

4.1 什么是AOF重寫？

AOF 重寫指的是它會直接讀取 Redis 服務(wù)器當(dāng)前的狀態(tài)，并壓縮保存為 AOF 文件。例如，我們增加了一個計數(shù)器，并對它做了 99 次修改，如果不做 AOF 重寫的話，那么持久化文件中就會有 100 條記錄執(zhí)行命令的信息，而 AOF 重寫之后，之后記錄一條此計數(shù)器最終的結(jié)果信息，這樣就去除了所有的無效信息。

4.2 AOF 重寫實現(xiàn)

觸發(fā) AOF 文件重寫，要滿足兩個條件，這兩個條件也是配置在 Redis 配置文件中的，它們分別：

• auto-aof-rewrite-min-size：允許 AOF 重寫的最小文件容量，默認是 64mb 。
• auto-aof-rewrite-percentage：AOF 文件重寫的大小比例，默認值是 100，表示 100%，也就是只有當(dāng)前 AOF 文件，比最后一次（上次）的 AOF 文件大一倍時，才會啟動 AOF 文件重寫。

查詢 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 的值，可使用 config get xxx 命令，如下圖所示：

小貼士：只有同時滿足 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 設(shè)置的條件，才會觸發(fā) AOF 文件重寫。

注意：使用 bgrewriteaof 命令，可以自動觸發(fā) AOF 文件重寫。

4.3 AOF 重寫流程

AOF 文件重寫是生成一個全新的文件，并把當(dāng)前數(shù)據(jù)的最少操作命令保存到新文件上，當(dāng)把所有的數(shù)據(jù)都保存至新文件之后，Redis 會交換兩個文件，并把最新的持久化操作命令追加到新文件上。

5. 配置說明

合理的設(shè)置 AOF 的配置，可以保障 Redis 高效且穩(wěn)定的運行，以下是 AOF 的全部配置信息和說明。

AOF 的配置參數(shù)在 Redis 的配置文件中，也就是 Redis 根路徑下的 redis.conf 文件中，配置參數(shù)和說明如下：

# 是否開啟 AOF，yes 為開啟，默認是關(guān)閉
appendonly no# AOF 默認文件名
appendfilename "appendonly.aof"# AOF 持久化策略配置
# appendfsync always
appendfsync everysec
# appendfsync no# AOF 文件重寫的大小比例，默認值是 100，表示 100%，也就是只有當(dāng)前 AOF 文件，比最后一次的 AOF 文件大一倍時，才會啟動 AOF 文件重寫。
auto-aof-rewrite-percentage 100# 允許 AOF 重寫的最小文件容量
auto-aof-rewrite-min-size 64mb# 是否開啟啟動時加載 AOF 文件效驗，默認值是 yes，表示盡可能的加載 AOF 文件，忽略錯誤部分信息，并啟動 Redis 服務(wù)。
# 如果值為 no，則表示，停止啟動 Redis，用戶必須手動修復(fù) AOF 文件才能正常啟動 Redis 服務(wù)。
aof-load-truncated yes

其中比較重要的是 appendfsync 參數(shù)，用它來設(shè)置 AOF 的持久化策略，可以選擇按時間間隔或者操作次數(shù)來存儲 AOF 文件，這個參數(shù)的三個值在文章開頭有說明，這里就不再復(fù)述了。

6. 數(shù)據(jù)恢復(fù)

6.1 正常數(shù)據(jù)恢復(fù)

正常情況下，只要開啟了 AOF 持久化，并且提供了正常的 appendonly.aof 文件，在 Redis 啟動時就會自定加載 AOF 文件并啟動，執(zhí)行如下圖所示：

其中 DB loaded from append only file...... 表示 Redis 服務(wù)器在啟動時，先去加載了 AOF 持久化文件。

小貼士：默認情況下 appendonly.aof 文件保存在 Redis 的根目錄下。

持久化文件加載規(guī)則

• 如果只開啟了 AOF 持久化，Redis 啟動時只會加載 AOF 文件（appendonly.aof），進行數(shù)據(jù)恢復(fù)；
• 如果只開啟了 RDB 持久化，Redis 啟動時只會加載 RDB 文件（dump.rdb），進行數(shù)據(jù)恢復(fù)；
• 如果同時開啟了 RDB 和 AOF 持久化，Redis 啟動時只會加載 AOF 文件（appendonly.aof），進行數(shù)據(jù)恢復(fù)。

在 AOF 開啟的情況下，即使 AOF 文件不存在，只有 RDB 文件，也不會加載 RDB 文件。 AOF 和 RDB 的加載流程如下圖所示：

6.2 簡單異常數(shù)據(jù)恢復(fù)

在 AOF 寫入文件時如果服務(wù)器崩潰，或者是 AOF 存儲已滿的情況下，AOF 的最后一條命令可能被截斷，這就是異常的 AOF 文件。

在 AOF 文件異常的情況下，如果為修改 Redis 的配置文件，也就是使用 aof-load-truncated 等于 yes 的配置，Redis 在啟動時會忽略最后一條命令，并順利啟動 Redis，執(zhí)行結(jié)果如下：

* Reading RDB preamble from AOF file...
* Reading the remaining AOF tail...
# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 439 !!!
# AOF loaded anyway because aof-load-truncated is enabled

6.3 復(fù)雜異常數(shù)據(jù)恢復(fù)

AOF 文件可能出現(xiàn)更糟糕的情況，當(dāng) AOF 文件不僅被截斷，而且中間的命令也被破壞，這個時候再啟動 Redis 會提示錯誤信息并中止運行，錯誤信息如下：

* Reading the remaining AOF tail...
# Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix <filename>

出現(xiàn)此類問題的解決方案如下：

1. 首先使用 AOF 修復(fù)工具，檢測出現(xiàn)的問題，在命令行中輸入 redis-check-aof 命令，它會跳轉(zhuǎn)到出現(xiàn)問題的命令行，這個時候可以嘗試手動修復(fù)此文件；
2. 如果無法手動修復(fù)，我們可以使用 redis-check-aof --fix 自動修復(fù) AOF 異常文件，不過執(zhí)行此命令，可能會導(dǎo)致異常部分至文件末尾的數(shù)據(jù)全部被丟棄。

7. 優(yōu)缺點

優(yōu)點

• AOF 持久化保存的數(shù)據(jù)更加完整，AOF 提供了三種保存策略：每次操作保存、每秒鐘保存一次、跟隨系統(tǒng)的持久化策略保存，其中每秒保存一次，從數(shù)據(jù)的安全性和性能兩方面考慮是一個不錯的選擇，也是 AOF 默認的策略，即使發(fā)生了意外情況，最多只會丟失 1s 鐘的數(shù)據(jù)；
• AOF 采用的是命令追加的寫入方式，所以不會出現(xiàn)文件損壞的問題，即使由于某些意外原因，導(dǎo)致了最后操作的持久化數(shù)據(jù)寫入了一半，也可以通過 redis-check-aof 工具輕松的修復(fù)；
• AOF 持久化文件，非常容易理解和解析，它是把所有 Redis 鍵值操作命令，以文件的方式存入了磁盤。即使不小心使用 flushall 命令刪除了所有鍵值信息，只要使用 AOF 文件，刪除最后的 flushall 命令，重啟 Redis 即可恢復(fù)之前誤刪的數(shù)據(jù)。

缺點

• 對于相同的數(shù)據(jù)集來說，AOF 文件要大于 RDB 文件；
• 在 Redis 負載比較高的情況下，RDB 比 AOF 性能更好；
• RDB 使用快照的形式來持久化整個 Redis 數(shù)據(jù)，而 AOF 只是將每次執(zhí)行的命令追加到 AOF 文件中，因此從理論上說，RDB 比 AOF 更健壯。