RDB的弊端
解決思路
一、AOF的概念
二、AOF寫數據的過程
客戶端發出指令給服務端，服務端並沒有馬上記錄，而是放到AOF寫命令刷新緩存區，到一定時間之后將命令同步到AOF文件中。
AOF寫數據三種策略
always(每次)
每次寫入操作均同步到AOF文件中，數據零誤差，性能較低，如果不是對數據非常嚴格不建議使用
everysec(每秒)
每秒將緩沖區中的指令同步到AOF文件中，數據准確性較高，性能較高，建議使用，也是默認配置。在系統突然宕機的情況下丟失1秒內的數據
no(系統控制)
由操作系統控制每次同步到AOF文件的周期，整體過程不可控
AOF功能開啟
兩個配置： appendonly yes|no #配置是否開啟AOF持久化功能，默認為不開啟狀態 appendfsync always|everysec|no #AOF寫數據策略
注意：數據如果有修改了才會寫入.aof文件，只是查詢（get）的話不會寫入文件
AOF相關配置
兩個配置： appendfilename filename #AOF持久化文件名，默認文件名為appendonly.aof,建議配置為appendonly-端口號.aof dir #AOF持久化文件保存路徑，與RDB持久化文件保持一致即可
三、AOF寫數據遇到的問題
AOF重寫問題
AOF重寫規則
四、AOF重寫方式
手動重寫 bgrewriteaof #在客戶端輸入
自動重寫觸發的條件設置 auto-aof-rewrite-min-size size #設置觸發aof的最小尺寸 auto-aof-rewrite-percentage percent #達到重寫的百分比 自動重寫觸發對比參數（運行指令info 在Persistence獲取具體信息） aof_current_size aof_base_size
五、AOF重寫流程
非重寫流程（always/everysec）
重寫流程
六、RDB與AOF的區別
RDB與AOF的選擇
七、Redis持久化的總結
1.什么是持久化 2.RDB save bgsave 配置 3.AOF 持久化寫策略（三種） 重寫