>[info] AOF AOF（append only file）持久化：與RDB存儲某個時刻的快照不同，AOF持久化方式會記錄客戶端 對服務器的每一次寫操作命令到日志當中，并將這些寫操作以 Redis協議追加保存到以后綴為aof文件末尾。 >[info] 使用AOF 開啟 AOF 功能需要設置配置：**appendonly yes**，默認不開啟。AOF 文件名通過 appendfilename 配置設置，默認文件名 appendonly.aof。保存路徑同 RDB 持久化方式一致，通過 dir 配置指定。 >[info] 持久化配置 **啟用aof持久化方式：appendonly yes** 當AOF持久化功能處于打開狀態時，服務器在執行完一個寫命令之后，會以協議格式將被執行的寫命令追加到 服務器狀態的aofbuf緩沖區的末尾。 ***** **appendfsync always：** 每次收到寫命令就立即強制寫入磁盤，最慢的大概只有幾百的TPS，但是保證完全 的持久化，**不推薦使用** 。 ***** **appendfsync everysec：** 每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，**推薦** 。 ***** **appendfsync no：** 完全依賴os，性能最好,持久化沒保證，Redis不會主動調用fsync去將AOF日志內容同 步到磁盤，所以這一切就完全依賴于操作系統。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖 區中的數據寫到磁盤上。 ***** **文件的寫入和同步：** * 為了提高文件的寫入效率，在現代操作系統中，當用戶調用write函數，將一些、數據寫入到文件的時候， 操作系統通常會將寫入數據暫時保存在一個內存緩沖區里面。等到緩沖區的空間被填滿、或者超過了指定的時限之后，才真正地將緩沖區中的數據寫入到磁盤里面。 * 這種做法雖然提高了效率，但也為寫入數據帶來了安全問題，因為如果計算機發生停機，那么保存在內存緩 沖區里面的寫入數據將會丟失。為此，系統提供了fsync和fdatasync兩個同步函數，它們可以強制讓操作系 統立即將緩沖區中的數據寫入到硬盤里面，從而確保寫入數據的安全性。  **說明：** 1）所有的寫入命令會追加到aof_buf（緩沖區）中。 2）AOF緩沖區根據對應的策略向硬盤做同步操作。 3）隨著AOF文件越來越大，需要定期對AOF文件進行重寫，達到壓縮的目的。 4）當Redis服務器重啟時，可以加載AOF文件進行數據恢復。 >[info] 重寫機制說明 * AOF將客戶端的每一個寫操作都追加到aof文件末尾，隨著命令不斷寫入 AOF，文件會越來越大，為了解決這 個問題，Redis引入AOF 重寫機制壓縮文件體積。= * AOF 文件重寫是把 Redis 進程內的數據轉化為寫命令同步到新 AOF 文件的過程。 **比如：** 多條寫命令可以合并為一個，如：lpush list a、lpush list b、lpush list c 可以轉化為：lpush list a b c。 ***** **AOF 重寫降低了文件占用空間，除此之外，另一個目的是：更小的 AOF 文件可以更快地被Redis加載。** >[info] 觸發機制 ### **AOF 重寫過程可以手動觸發 和 自動觸發：** **1. 手動觸發：** 直接調用 bgrewriteaof 命令。 **2. 自動觸發：** 根據 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 參數確定自動觸發時機。 ``` # 表示運行 AOF 重寫時文件最小體積，默認為 64MB。 auto-aof-rewrite-min-size # 代表當前 AOF 文件空間（aof_current_size）和上一次重寫后 AOF 文件空間（aof_base_size）的比值。 auto-aof-rewrite-percentage ``` **示例：** ``` # 默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發 auto-aof-rewrite-percentage：100 auto-aof-rewrite-min-size：64mb ``` >[info] AOF追加阻塞 當開啟AOF持久化時，常用的同步硬盤的策略是everysec，用于平衡性能和數據安全性。對于這種方式， Redis使用另一條線程每秒執行fsync同步 硬盤。當系統硬盤資源繁忙時，會造成Redis主線程阻塞。  **阻塞流程分析：** 1）主線程負責寫入AOF緩沖區。 2）AOF線程負責每秒執行一次同步磁盤操作，并記錄最近一次同步時間。 3）主線程負責對比上次AOF同步時間： ·如果距上次同步成功時間在2秒內，主線程直接返回。 ·如果距上次同步成功時間超過2秒，主線程將會阻塞，直到同步操作完成。 通過對AOF阻塞流程可以發現兩個問題： 1）everysec配置最多可能丟失2秒數據，不是1秒。 2）如果系統fsync緩慢，將會導致Redis主線程阻塞影響效率 >[info] AOF注意事項 **AOF文件損壞：** 在寫入aof日志文件時，如果Redis服務器宕機，則aof日志文件文件會出格式錯誤，在重啟Redis服務器 時，Redis服務器會拒絕載入這個aof文件， 可以通過命令修復aof并恢復數據。 ``` redis-check-aof-fix file.aof ``` >[info] AOF的優缺點 **AOF的優點：** 1. AOF可以設置 完全不同步、每秒同步、每次操作同，默認是每秒同步。因為AOF是操作指令的追加，所以可以頻繁的大量的同步。 2. AOF文件是一個值追加日志的文件，即使服務宕機為寫入完整的命令，也可以通過redis-check-aof工具修復這些問題。 3. 如果AOF文件過大，Redis會在后臺自動地重寫AOF文件。重寫后會使AOF文件壓縮到最小所需的指令集。 4. AOF文件是有序保存數據庫的所有寫入操作，易讀，易分析。即使如果不小心誤操作數據庫，也很容易找出錯誤指令，恢復到某個數據節點。例如不小心FLUSHALL，可以非常容易恢復到執行命令之前。 **AOF的缺點：** 1. 相同數據量下，AOF的文件通常體積會比RDB大。因為AOF是存指令的，而RDB是所有指令的結果快照。但 AOF在日志重寫后會壓縮一些空間。 2、在大量寫入和載入的時候，AOF的效率會比RDB低。因為大量寫入， AOF會執行更多的保存命令，載入的時候也需要大量的重執行命令來得到最后的結果。 RDB對此更有優勢。 >[info] AOF常用配置總結 ``` appendonly no：是否開啟AOF appendfilename "appendonly.aof"：AOF文件名 dir ./：RDB文件和AOF文件所在目錄 appendfsync everysec：fsync持久化策略 no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕文件重寫時CPU和硬盤的負載（尤其是硬盤），但是可能會丟失 AOF重寫期間的數據；需要在負載和安全性之間進行平衡 auto-aof-rewrite-percentage 100：文件重寫觸發條件之一 auto-aof-rewrite-min-size 64mb：文件重寫觸發提交之一 aof-load-truncated yes：如果AOF文件結尾損壞，Redis啟動時是否仍載入AOF文件 ```