AOF日志持久化
rdb是快照，整個內存的快照（缺點幾分鐘才照一次，如果在下一次照之前突然宕機了，那么上一次快照到下一次快照之間的數(shù)據(jù)就損失了）。而aof是日志。
aof(append of file)的配置
appendonly no #是否打開aof日志功能
appendfsync always* #每一個命令，都立即同步到aof。安全，對redis操作的速度慢
appendfsync everysec#折衷方案，每秒寫1次
appendfsync no #日志寫入磁盤的工作交給操作系統(tǒng)，由操作系統(tǒng)判斷緩沖區(qū)大小，統(tǒng)一寫到aof日志中（根據(jù)操作系統(tǒng)的規(guī)則），對redis操作的速度快，但同步效率低
**no-appendfsync-no-rewrite yes **#正在導出rdb快照的過程中，要不要停止同步aof( aof一般設成每秒一次，rdb生成快照的時候，由于幾分鐘才執(zhí)行一次，數(shù)據(jù)量大，所以執(zhí)行時間肯定不止一秒，在這個過程中默認aof肯定要執(zhí)行。但這個時候應該就讓rdb一個進程執(zhí)行就行了，減輕對磁盤的IO)
**auto-aof-rewrite-percentage 100 **#aof文件大小比起上次重寫時的大小，增長率100%時，重寫。
appendfilename appendonly.aof#這個是用來配置其aof日志文件名的，默認是appendonly.aof
**aof日志文件保存的目錄和之前rdb設置的目錄一樣，因為他們都是用dir設置的 **
aof的工作原理
客戶端對服務端主進程不斷發(fā)送命令，服務端的aof子進程就將你執(zhí)行的每條命令立即寫到文本文件中。
好處：我們就可以用寫到那個文本文件中的日志對數(shù)據(jù)進行恢復
缺點：redis圖的是內存的快，但如果每次將命令寫如文本文件中，則對磁盤的IO會降低內存所帶來的效率。所以我們一般要設置成一段時間才對磁盤進行IO,降低磁盤IO所帶來的效率的損失。
問題
同一個key,才操作100次，redis（內存中）只有一個具體值。而aof則會有100次操作，導致缺點是afo文件過大，另外從aof恢復數(shù)據(jù)的時候會過慢，因為它也會操作100次。
解決：所有的key在內存中只有一個具體的狀態(tài)。我把內存中的key/value逆化成相關的命令。比如：
set age=0
incr age
……
……incr age
age=100
set age 100
這就是重寫，重寫是什么呢？重寫就是把內存中當下數(shù)據(jù)的具體值，寫入到aof日志里，以解決aof日志過大的問題。aof重寫會先刪除距離上次重寫增長的內容
。
aof重寫相關配置
auto-aof-rewrite-percentage 100#aof文件大小比起上次重寫時的大小增長100%時，就重寫
auto-aof-rewrite-min-size 64mb#因為最開始aof文件很小，可能導致寫一個兩個命令就重寫，這樣前期的重寫密度過大，所以設置一個最小值。只有超過這個值才開始重寫。
注意：一般開啟aof，redis命令執(zhí)行的效率就下降了
如果rdb和aof文件都存在，優(yōu)先用誰來恢復數(shù)據(jù)？
答：aof
rdb和aof是否可以同時啟用？
答：可以
恢復時rdb和aof哪個恢復的快？
答：rdb快。因為rdb是數(shù)據(jù)的內存映射。直接載入到內存的，而aof是命令，需要逐條執(zhí)行
bgrewriteaof
不滿足那些個條件時都會重寫
