#### 1.使用場景 ``` RDB會丟失最后一次備份的rdb文件，但是其實也無所謂，其實也可以忽略不計，畢竟是緩存，丟了就丟了， 但是如果追求數據的完整性，那就的考慮使用AOF了。 ``` #### 2.優點 ``` 1. AOF更加耐用，可以以秒級別為單位備份，如果發生問題，也只會丟失最后一秒的數據，大大增加了可靠性和數據完整性。所以AOF可以每秒備份一次，使用fsync操作。 2. 以log日志形式追加，如果磁盤滿了，會執行 redis-check-aof 工具 3. 當數據太大的時候，redis可以在后臺自動重寫aof。當redis繼續把日志追加到老的文件中去時，重寫也是非常安全的，不會影響客戶端的讀寫操作。 4. AOF 日志包含的所有寫操作，會更加便于redis的解析恢復。 ``` #### 3.缺點 ``` 1. 相同的數據，同一份數據，AOF比RDB大 2. 針對不同的同步機制，AOF會比RDB慢，因為AOF每秒都會備份做寫操作，這樣相對與RDB來說就略低。 每秒備份fsync沒毛病，但是如果客戶端的每次寫入就做一次備份fsync的話，那么redis的性能就會下降。 3. AOF發生過bug，就是數據恢復的時候數據不完整，這樣顯得AOF會比較脆弱，容易出現bug，因為AOF 沒有RDB那么簡單，但是呢為了防止bug的產生，AOF就不會根據舊的指令去重構，而是根據當時緩存中存 在的數據指令去做重構，這樣就更加健壯和可靠了 ``` #### 4. AOF的配置 ``` * AOF 默認關閉，yes可以開啟 appendonly no * AOF 的文件名 appendfilename "appendonly.aof" * no：不同步 *everysec：每秒備份，推薦使用 * always：每次操作都會備份，安全并且數據完整，但是慢性能差 appendfsync everysec * 重寫的時候是否要同步，no可以保證數據安全 no-appendfsync-on-rewrite no * 重寫機制：避免文件越來越大，自動優化壓縮指令，會fork一個新的進程去完成重寫動作， 新進程里的內存數據會被重寫，此時舊的aof文件不會被讀取使用，類似rdb * 當前AOF文件的大小是上次AOF大小的100% 并且文件體積達到64m，滿足兩者則觸發重寫 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb ``` #### 5.如何使用 ``` 1. 如果你能接受一段時間的緩存丟失，那么可以使用RDB 2. 如果你對實時性的數據比較care，那么就用AOF 3. 使用RDB和AOF結合一起做持久化，RDB做冷備，可以在不同時期對不同版本做恢復，AOF做熱備， 保證數據僅僅只有1秒的損失。當AOF破損不可用了，那么再用RDB恢復，這樣就做到了兩者的相互結 合，也就是說Redis恢復會先加載AOF，如果AOF有問題會再加載RDB，這樣就達到冷熱備份的目的了。 ```