AOF持久化跟RDB不同，它是將寫命令記錄到日誌中，並將這些寫操作保存到aof文件中
使用AOF
開啓aof需要開啓配置：appendonly yes ，默認不開啓，aof文件名通過appendfilename 配置，默認文件名 APPendonly.aof ；保存路徑跟RDB相同，通過 dir 配置
持久化配置
#啓用aof持久化方式
appendonly yes
#每次收到寫命令就立即強制寫入磁盤， 最慢的大概只有幾百的TPS， 但是保證完全的持久化， 不推薦使用
appendfsync always
#每秒鐘強制寫入磁盤一次， 在性能和持久化方面做了很好的折中， 推薦
appendfsync everysec
#完全依賴os 性能最好,持久化沒保證，Redis不會主動調用fsync去將AOF日誌內容同步到磁盤，所以這一切就完全依賴於操作系統的 對大多數Linux操作系統是每30秒進行一次fsync，將緩衝區中的數據寫到磁盤上。
appendfsync no，
工作流程
- 所有的寫入命令都會寫入到緩存區
- aof緩衝區根據對應的策略向硬盤做同步操作
- 隨着文件越來愈大需要定期對aof文件重寫，達到壓縮的目的
- 當redis重啓時，可以通過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加載
觸發機制
aof重寫可以手動觸發跟自動觸發
手動觸發 ：調用bgrewriteaof 命令。
自動觸發：根據auto-aof-rewrite-min-size和 auto-aof-rewrite-percentage參數確定自動觸發時機
auto-aof-rewrite-min-size： 表示運行 AOF 重寫時文件最小體積， 默認爲 64MB。
auto-aof-rewrite-percentage： 代表當前 AOF 文件空間（aof_current_size） 和上一次重寫後 AOF 文件空間（aof_base_size） 的比值
示例：
auto-aof-rewrite-percentage： 100
auto-aof-rewrite-min-size： 64mb
默認配置是當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發
重寫運行流程
- 1.開始重寫
- 2.父進程執行 fork 創建子進程， 開銷等同於 bgsave 過程
- 3.1 主進程 fork 操作完成後， 繼續響應其他命令。 所有修改命令依然寫入 AOF 緩衝區並根據 appendfsync 策略同步到硬盤，保證原有 AOF 機制正確性。.
- 3.2 由於 fork 操作運用寫時複製技術， 子進程只能共享 fork 操作時的內存數據。 由於父進程依然響應命令， Redis 使用“AOF 重寫緩衝區”保存這部分新數據， 防止新 AOF 文件生成期間丟失這部分數據
- 4. 子進程根據內存快照， 按照命令合併規則寫入到新的 AOF 文件。 每次批量寫入硬盤數據量由配置 aof-rewrite-incremental-fsync 控制， 默認爲 32MB， 防止單次刷盤數據過多造成硬盤阻塞。
- 4.1） 新 AOF 文件寫入完成後， 子進程發送信號給父進程， 父進程更新統計信息， 具體見 info persistence 下的 aof_*相關統計。
4.2） 父進程把 AOF 重寫緩衝區的數據寫入到新的 AOF 文件。
4.3） 使用新 AOF 文件替換老文件， 完成 AOF 重寫。
AOF注意事項
在寫入aof日誌文件時， 如果Redis服務器宕機， 則aof日誌文件文件會出格式錯誤， 在重啓Redis服務器時， Redis服務器會拒絕載入這個aof文件，可以通過命令修復aof並恢復數據
redis-check-aof -fix file.aof
AOF的優點
- 可以設置完全不同步，每秒同步，每次同步，默認每秒，因爲aod是寫操作的追加，所以可以頻繁的大量的的同步
- aof是日誌追加的文件，所以服務器宕機也可以通過redis-check-aof工具修復
- 如果aof文件過大，redis會在後臺自動重寫aof文件。壓縮到最小指令集
- AOF文件是有序保存數據庫的所有寫入操作， 易讀， 易分析。 即使如果不小心誤操作數據庫， 也很容易找出錯誤指令， 恢復到某個數據節點。 例如不小心FLUSHALL， 可以非常容易恢復到執行命令之前。
AOF的缺點
- 相同數據量下，aof文件通常回避rdb大，因爲aof存的是指令，而rdb存的是數據快照。
- 在大量寫入跟載入的時候rdb會比aof快很多，因爲大量寫入。aof會執行更多的保存命令，載入也需要大量執行命令來得到結果
持久化的選擇
在實際生產環境中， 根據數據量、 應用對數據的安全要求、 預算限制等不同情況， 會有各種各樣的持久化策略； 如完全不使用任何持久化、 使用RDB或AOF的一種， 或同時開啓RDB和AOF持久化等。 此外， 持久化的選擇必須與Redis的主從策略一起考慮， 因爲主從複製與持久化同樣具有數據備份的功能，而且主機master和從機slave可以獨立的選擇持久化方案。面分場景來討論持久化策略的選擇， 下面的討論也只是作爲參考， 實際方案可能更復雜更具多樣性。
1） 如果Redis中的數據完全丟棄也沒有關係（如Redis完全用作DB層數據的cache） ， 那麼無論是單機，
還是主從架構， 都可以不進行任何持久化。
2） 在單機環境下（對於個人開發者， 這種情況可能比較常見） ， 如果可以接受十幾分鍾或更多的數據丟失， 選擇RDB對Redis的性能更加有利；如果只能接受秒級別的數據丟失， 應該選擇AOF。
3） 但在多數情況下， 我們都會配置主從環境， slave的存在既可以實現數據的熱備， 也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務。在這種情況下的做法是：
master： 完全關閉持久化（包括RDB和AOF） ， 這樣可以讓master的性能達到最好；
slave： 關閉RDB， 開啓AOF（如果對數據安全要求不高， 開啓RDB關閉AOF也可以） ， 並定時對持久化文件進行備份（如備份到其他文件夾， 並標記好備份的時間） ；然後關閉AOF的自動重寫， 然後添加定時任務， 在每天Redis閒時（如凌晨12點） 調用bgrewriteaof。
這裏需要解釋一下， 爲什麼開啓了主從複製， 可以實現數據的熱備份， 還需要設置持久化呢？ 因爲在一些特殊情況下， 主從複製仍然不足以保證數
據的安全， 例如：
- master和slave進程同時停止： 考慮這樣一種場景， 如果master和slave在同一個機房， 則一次停電事故就可能導致master和slave機器同時關機，
- Redis進程停止； 如果沒有持久化， 則面臨的是數據的完全丟失。
- master誤重啓： 考慮這樣一種場景， master服務因爲故障宕掉了， 如果系統中有自動拉起機制（即檢測到服務停止後重啓該服務） 將master自動重啓， 由於沒有持久化文件， 那麼master重啓後數據是空的，
- slave同步數據也變成了空的； 如果master和slave都沒有持久化， 同樣會面臨數據的完全丟失。 需要注意的是， 即便是使用了哨兵進行自動的主從切換，也有可能在哨兵輪詢到master之前， 便被自動拉起機制重啓了。 因此， 應儘量避免“自動拉起機制”和“不做持久化”同時出現。
4） 異地災備： 上述討論的幾種持久化策略， 針對的都是一般的系統故障， 如進程異常退出、 宕機、 斷電等， 這些故障不會損壞硬盤。 但是對於一些可能導致硬盤損壞的災難情況， 如火災地震， 就需要進行異地災備。
例如對於單機的情形， 可以定時將RDB文件或重寫後的AOF文件， 通過scp拷貝到遠程機器， 如阿里雲； 對於主從的情形， 可以定時在master上執行bgsave， 然後將RDB文件拷貝到遠程機器，或者在slave上執行bgrewriteaof重寫AOF文件後， 將AOF文件拷貝到遠程機器上。一般來說， 由於RDB文件文件小、 恢復快， 因此災難恢復常用RDB文件； 異地備份的頻率根據數據安全性的需要及其它條件來確定， 但最好不要低於一天一次。
持久化配置方案
1、 企業級的持久化的配置策略
save 60 10000： 如果你希望儘可能確保說， RDB最多丟1分鐘的數據， 那麼儘量就是每隔1分鐘都生成一個快照， 低峯期， 數據量很少， 也沒必要
10000->生成RDB， 1000->RDB， 這個根據你自己的應用和業務的數據量， 你自己去決定
AOF一定要打開， fsync， everysec
auto-aof-rewrite-percentage 100: 就是當前AOF大小膨脹到超過上次100%， 上次的兩倍
auto-aof-rewrite-min-size 64mb: 根據你的數據量來定， 16mb， 32mb
2、 數據備份方案
RDB非常適合做冷備， 每次生成之後， 就不會再有修改了
數據備份方案
（1） 寫crontab定時調度腳本去做數據備份
（2） 每小時都copy一份rdb的備份， 到一個目錄中去， 僅僅保留最近48小時的備份
（3） 每天都保留一份當日的rdb的備份， 到一個目錄中去， 僅僅保留最近1個月的備份
（4） 每次copy備份的時候， 都把太舊的備份給刪了
（5） 每天晚上將當前服務器上所有的數據備份， 發送一份到遠程的雲服務上去【crontab】
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文件