九. Redis 持久化-AOF(詳細講解說明，一個配置一個說明分析，步步講解到位 2)

---

1. Redis 持久化 AOF 概述

Redis 持久化-AOF 官方文檔地址： https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

?

AOF 是什么？

1. AOF(Append Only File)
2. 以日志的形式來記錄每個寫 操作(增量保存) ，將 Redis 執行過的所有寫指令記錄下來(比如 set/del 操作會記錄)，讀操作 get 不記錄）
3. 只許追加文件但不可以改寫文件
4. Redis 啟動之初會讀取文件重新構建數據
5. redis 重啟的話就根據日志文件的內容將寫指令從前到后執行一次，以完成對數據的恢復工作。

2. AOF 持久化流程

上流程圖解讀：

1. 客戶端的請求寫命令會被 append 追加到 AOF 緩沖區內
2. AOF 緩沖區根據 AOF 持久化策略(always，everysec，no) 將操作 sync 同步到磁盤的 AOF 文件中
3. AOF 文件大小超過重寫策略或手動重寫時，會對 AOF 文件 rewrite 重寫，壓縮 AOF 文件容量
4. Redis 服務重啟時，會重新 load 加載 AOF 文件中的寫操作達到數據恢復的目的。

3. AOF 的配置

關于 AOF 的配置和 RDB 的配置都是一樣的，都是在 /etc/redis.conf 文件當中配置的。

在 redis.conf 中配置文件名稱，默認為 appendonly.aof 文件，作為備份快照文件的。

設置為 no 將 AOF 持久化開啟。

appendonly yes

需要將 Redis 服務器關閉，再重新啟動 Redis 服務器，配置才會生效。

[root@localhost ~]# redis-server /etc/redis.conf
[root@localhost ~]# redis-cli

重點：

• AOF 文件的保存路徑，同 RDB 的路徑是一致的配置，都是存儲到同一個地方的。RDB 配置的路徑是在哪里 ,AOF 配置的路徑也就是在哪里。
• AOF 和 RDB 同時開啟，系統默認取 AOF 的數據 。當開啟 AOF 后，Redis 從 AOF 文件取數據。

AOF 演示：

**AOF ** 只對 set[添加/修改] 和 del 操作記錄下來了。

get[讀]操作，并沒有記錄下來。

4. AOF 啟動/修復/恢復

基本說明：

AOF 的備份機制和性能雖然和 RDB 不同，但是備份和恢復的操作同 RDB 一樣，都是拷貝備份文件，需要恢復時再拷貝到 Redis 工作目錄下，啟動系統即加載。

正常恢復：

1. 修改默認的 appendonly no ,改為 yes
2. 將有數據的 aof 文件定時備份，需要恢復時，復制一份保存到對應目錄(查看目錄: config get dir )
3. 恢復：重啟 Redis 然后重新加載。
4. 這里就演示了，和前面的 RDB 備份/恢復是一樣的，大家可以移步至🌟🌟🌟

[root@localhost ~]# cp appendonly.aof appendonly.aof.bak # 復制拷貝

異常恢復：

1. 如遇到 AOF 文件損壞，通過/usr/local/bin/redis-check-aof --fix appendonly.aof 進行恢復
2. 建議先: 備份被寫壞的 AOF 文件
3. 恢復：重啟 redis，然后重新加載

演示異常恢復：

這里我們將 appendonly.aof 文件進行一個刻意的修改，造成數據的異常。

[root@localhost ~]# redis-check-aof --fix /root/appendonly.aof # 修復文件（已經是在root 目錄下了）
[root@localhost ~]# ./redis-check-aof --fix appendonly.aof # 修復文件（已經是在root 目錄下了，所以不用使用 /root 指定位置）

同步頻率設置：

配置位置：

appendfsync everysec 配置說明：

1. appendfsync always 始終同步，每次 Redis 的寫入都會立刻計入日志；性能較差但數據完整性比較好。
2. appendfsync everysec 每秒同步，每秒記入日志一次，如果宕機，本秒的數據可能會丟失。
3. appendfsync no 表示 Redis 不主動進行同步，把同步時機交給操作系統。更多詳細內容https://baijiahao.baidu.com/s?id=1740774723808931509&wfr=spider&for=pc

5. Rewrite 壓縮

1. AOF 文件越來越大，需要定期對 AOF 文件進行重寫達到壓縮。
2. 舊的 AOF 文件含有無效命令被忽略，保留最新的數據命令，比如 ：set a a1；set a b1；set a c1； 保留最后一條指令就可以了。
3. 多條寫命令可以合并為一個，比如 ： set a c1 b b1 c c1
4. AOF 重寫降低了文件占用空間
5. 更小的 AOF 文件可以更快的被 Redis 加載。

重寫觸發配置：

1. 手動觸發：

直接調用 bgrewriteaof 命令：

127.0.0.1:6379> bgrewriteaof

2. 自動觸發：

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

auto-aof-rewrite-min-size : AOF 文件最小重寫大小，只有當 AOF 文件大小大于 該值的時候才能重寫，默認配置 64MB。

auto-aof-rewrite-percentage ：當前 AOF 文件大小和最后一次重寫的大小之間的比率等于或者大于指定的增長百分比，比如 100 代表當前 AOF 文件時上次重寫的兩倍時候才重寫。

注意：

• 系統載入時或者上次重寫完畢時，Redis 會記錄此時 AOF 大小，設為 base_size
• 如果 Redis 的AOF當前大小 >= base_size+base_size * 100%(默認) 當前大小 >= 64mb(默認) 的情況下，Redis 會對 AOF 進行重寫。

6. AOF 持久化小結(優勢 & 劣勢)

優勢：

1. 備份機制更穩健，丟失數據概率更低。
2. 可讀的日志文本，通過操作 AOF 穩健，可以處理誤操作 。

劣勢：

1. 比起 RDB 占用更多的磁盤空間(會記錄數據和指令)
2. 恢復備份速度比 RDB 更慢(因為每次恢復數據是重新執行我們備份在appendonly.aof 文件當中的指令，而 RDB 是存儲了數據，直接拿出來，所以比 RDB 更慢一些)。
3. 每次讀寫都同步的話，有一定的性能壓力。

7. 選擇 RDB 還是 AOF ?

選擇 RDB 還是 AOF，官方文檔說明： https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

• 官方推薦兩個都啟用
• 如果只做緩存：如果你只希望你的數據在服務器運行的時候存在, 你也可以不使用任何持久化方式

8. 最后：

“在這個最后的篇章中，我要表達我對每一位讀者的感激之情。你們的關注和回復是我創作的動力源泉，我從你們身上吸取了無盡的靈感與勇氣。我會將你們的鼓勵留在心底，繼續在其他的領域奮斗。感謝你們，我們總會在某個時刻再次相遇。”