10. AOF（Append Only File）

將所有的命令都記錄下來，類似histrory的操作， 恢復的時候會將這個檔案全執行一遍

10.1 簡介

以日誌的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加檔案但不可以改寫檔案，redis啟動之初會讀取該檔案重新構建資料，換一種說法，redis重啟的話，就是根據日誌檔案的內容，將寫指令從前到後執行了一次，才完成了資料的恢復。

10.2 配置AOF

1. 首先修改配置檔案中的appendonly yes

2. 進入redis根目錄環境

   docker exec -it myredis /bin/bash
   

3. 執行以下命令

   # 開啟 AOF 功能
   redis-cli config set appendonly yes
   
   # 關閉 RDB 功能，這一步是可選的， 如果你願意， 也可以同時使用 RDB 和 AOF 這兩種持久化功能
   redis-cli config set save ""
   

4. 檢視設定的掛載目錄是否有appendonly,aof檔案
   

10.3 測試AOF

# 刪除配置檔案
[root@localhost data]# rm -rf appendonly.aof 

# 關閉redis服務
[root@localhost data]# docker exec -it myredis redis-cli
127.0.0.1:6379> shutdown

# 開啟容器
[root@localhost data]# docker start 2701a10233f7dd0b9aed288b19112f6098a771bbb4bbe41fe13773b6a0a4d70a
2701a10233f7dd0b9aed288b19112f6098a771bbb4bbe41fe13773b6a0a4d70a

# 進入redis執行環境，重新載入配置
[root@localhost data]# docker exec -it myredis /bin/bash
root@2701a10233f7:/data# redis-server /etc/redis.conf 
20:C 04 Oct 2020 17:08:06.347 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
20:C 04 Oct 2020 17:08:06.347 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=20, just started
20:C 04 Oct 2020 17:08:06.347 # Configuration loaded
20:M 04 Oct 2020 17:08:06.348 # Could not create server TCP listening socket 127.0.0.1:6379: bind: Address already in use
root@2701a10233f7:/data# redis-cli

127.0.0.1:6379> get k1
(nil)

刪除aof後，無法獲取之前儲存的資料

10.4 修復AOF檔案

# 進入測試環境，執行修復命令
[root@localhost data]# docker exec -it myredis /bin/bash
root@0d7c5ccd9ab8:/data# redis-check-aof --fix appendonly.aof 
0x              a4: Expected \r\n, got: 6571
AOF analyzed: size=173, ok_up_to=139, diff=34
This will shrink the AOF from 173 bytes, with 34 bytes, to 139 bytes
Continue? [y/N]: y
Successfully truncated AOF

# 關機使配置檔案生效
root@0d7c5ccd9ab8:/data# redis-cli
127.0.0.1:6379> shutdown

# 重新啟動
[root@localhost data]# docker start 0d7c5ccd9ab8ae1bd48200cfd7e89d011f45b0a9ff9a67587c31d4de98c90314
0d7c5ccd9ab8ae1bd48200cfd7e89d011f45b0a9ff9a67587c31d4de98c90314

# 重新進入測試環境查詢，發現異常資料被清除了，其他資料還保留著
[root@localhost data]# docker exec -it myredis redis-cli
127.0.0.1:6379> get k5
(nil)
127.0.0.1:6379> get k4
"v4"

如果是docker安裝的Redis，假如AOF檔案有錯誤，shutdown之後，將無法進入測試環境，無法修復。

10.5 重寫規則

aof 預設會讓檔案無限追加，檔案會越來越大

如果aof檔案大於64MB，redis會fork一個新的程式，來將檔案進行重寫。

10.6 優點、缺點

優點：

• 每一次修改都會同步，檔案的完整性更好
• 每秒同步一次，可能會丟失一秒的資料
• 從不同步，效率最高

缺點：

• 相對於資料檔案來說，aof遠遠大於rdb，修復的速度也比rdb慢！
• AOF執行效率也要比rdb慢，所以我們redis的配置就是rdb持久化

擴充套件：

1. RDB 持久化方式能夠在指定的時間間隔內對你的資料進行快照儲存
2. AOF 持久化方式記錄每次對伺服器寫的操作，當伺服器重啟的時候會重新執行這些命令來恢復原始的資料，AOF命令以Redis 協議追加儲存每次寫的操作到檔案末尾，Redis還能對AOF檔案進行後臺重寫，使得AOF檔案的體積不至於過大。
3. 只做快取，如果你只希望你的資料在伺服器執行的時候存在，你也可以不使用任何持久化
4. 同時開啟兩種持久化方式
   • 在這種情況下，當redis重啟的時候會優先載入AOF檔案來恢復原始的資料，因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。
   • RDB 的資料不實時，同時使用兩者時伺服器重啟也只會找AOF檔案，那要不要只使用AOF呢？作者建議不要，因為RDB更適合用於備份資料庫（AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段。
5. 效能建議
   • 因為RDB檔案只用作後備用途，建議只在Slave上持久化RDB檔案，而且只要15分鐘備份一次就夠了，只保留 save 900 1 這條規則。
   • 如果Enable AOF ，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻load自己的AOF檔案就可以了，代價一是帶來了持續的IO，二是AOF rewrite 的最後將 rewrite 過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上，預設超過原大小100%大小重寫可以改到適當的數值。
   • 如果不Enable AOF ，僅靠 Master-Slave Repllcation 實現高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動。代價是如果Master/Slave 同時當機，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個 Master/Slave 中的 RDB檔案，載入較新的那個，微博就是這種架構。