AOF
AOF概念
AOF（append only file）持久化：以獨立日誌的方式記錄每次寫命令，重啟時再重新執行AOF檔案中命令達到恢復資料的目的。與RDB相比可以簡單描述為改記錄資料為記錄資料產生的過程
AOF的主要作用是解決了資料持久化的實時性，目前已經是Redis持久化的主流方式
AOF寫資料過程
AOF寫資料三種策略（appendfsync）
always（每次）
每次寫入操作均同步到AOF檔案中，資料零誤差，效能較低，不建議使用。everysec（每秒）
每秒將緩衝區中的指令同步到AOF檔案中，資料準確性較高，效能較高，建議使用，也是預設配置
在系統突然當機的情況下丟失1秒內的資料no（系統控制）
由作業系統控制每次同步到AOF檔案的週期，整體過程不可控
AOF功能啟動
配置
appendonly yes｜no
作用：是否 開啟AOF持久化功能，預設為不開啟狀態appendfsync always｜everysec｜no
作用：AOF寫資料策略appendfilename filename
作用：AOF持久化檔名，預設檔名為appendonly.aof，建議配置為appendonly-埠號.aofdir
作用：AOF持久化檔案儲存路徑，與RDB持久化檔案保持一致即可
AOF寫資料遇到的問題
如果連續執行如下指令該如何處理
AOF重寫
隨著命令不斷寫入AOF，檔案會越來越大，為了解決這個問題，Redis引入了AOF重寫機制壓縮檔案體積。AOF檔案重寫是將Redis程式內的資料轉化為寫命令同步到新AOF檔案的過程。簡單說就是將對同一個資料的若干條命令執行結果轉化成最終結果資料對應的指令進行記錄。
AOF重寫作用
- 降低磁碟佔用量，提高磁碟利用率。
- 提高持久化效率，降低持久化寫時間，提高IO效能
- 降低資料恢復用時，提高資料恢復效率
AOF重寫規則
- 程式內超時的資料不再寫入檔案
- 忽略無效指令，重寫時使用程式內資料直接生成，這樣新的AOF檔案只保留最終資料的寫入命令
如del key1、hdel key2、srem key3、set key4 111等 - 對同一資料的多條寫命令合併為一條命令
如lpush list1 a、lpush list1 b、lpush list1 c 可以轉化為：lpush list1 a b c。
為防止數量過大導致客戶端緩衝區溢位，對list、set、hash、zset等型別，每條指令最多寫入64個元素
本作品採用《CC 協議》，轉載必須註明作者和本文連結