一、redis持久化----兩種方式
1、redis提供了兩種持久化的方式，分別是RDB（Redis DataBase）和AOF（Append Only File）。
2、RDB，簡而言之，就是在不同的時間點，將redis存儲的數據生成快照並存儲到磁盤等介質上；
3、AOF，則是換了一個角度來實現持久化，那就是將redis執行過的所有寫指令記錄下來，在下次redis重新啓動時，只要把這些寫指令從前到後再重複執行一遍，就可以實現數據恢復了。
4、其實RDB和AOF兩種方式也可以同時使用，在這種情況下，如果redis重啓的話，則會優先採用AOF方式來進行數據恢復，這是因爲AOF方式的數據恢復完整度更高。
5、如果你沒有數據持久化的需求，也完全可以關閉RDB和AOF方式，這樣的話，redis將變成一個純內存數據庫，就像memcache一樣。
二、redis持久化----RDB
1、RDB方式，是將redis某一時刻的數據持久化到磁盤中，是一種快照式的持久化方法。
2、redis在進行數據持久化的過程中，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，纔會用這個臨時文件替換上次持久化好的文件。正是這種特性，讓我們可以隨時來進行備份，因爲快照文件總是完整可用的。
3、對於RDB方式，redis會單獨創建（fork）一個子進程來進行持久化，而主進程是不會進行任何IO操作的，這樣就確保了redis極高的性能。
4、如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
5、雖然RDB有不少優點，但它的缺點也是不容忽視的。如果你對數據的完整性非常敏感，那麼RDB方式就不太適合你，因爲即使你每5分鐘都持久化一次，當redis故障時，仍然會有近5分鐘的數據丟失。所以，redis還提供了另一種持久化方式，那就是AOF。
三、redis持久化----AOF
1、AOF，英文是Append Only File，即只允許追加不允許改寫的文件。
2、如前面介紹的，AOF方式是將執行過的寫指令記錄下來，在數據恢復時按照從前到後的順序再將指令都執行一遍，就這麼簡單。
3、我們通過配置redis.conf中的appendonly yes就可以打開AOF功能。如果有寫操作（如SET等），redis就會被追加到AOF文件的末尾。
4、默認的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），因爲在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數據。
5如果在追加日誌時，恰好遇到磁盤空間滿、inode滿或斷電等情況導致日誌寫入不完整，也沒有關係，redis提供了redis-check-aof工具，可以用來進行日誌修復。
6、因爲採用了追加方式，如果不做任何處理的話，AOF文件會變得越來越大，爲此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所設定的閾值時，redis就會啓動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集。舉個例子或許更形象，假如我們調用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，完全可以把這100條指令合併成一條SET指令，這就是重寫機制的原理。
7、在進行AOF重寫時，仍然是採用先寫臨時文件，全部完成後再替換的流程，所以斷電、磁盤滿等問題都不會影響AOF文件的可用性，這點大家可以放心。
8、AOF方式的另一個好處，我們通過一個“場景再現”來說明。某同學在操作redis時，不小心執行了FLUSHALL，導致redis內存中的數據全部被清空了，這是很悲劇的事情。不過這也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件還沒有被重寫（rewrite），我們就可以用最快的速度暫停redis並編輯AOF文件，將最後一行的FLUSHALL命令刪除，然後重啓redis，就可以恢復redis的所有數據到FLUSHALL之前的狀態了。是不是很神奇，這就是AOF持久化方式的好處之一。但是如果AOF文件已經被重寫了，那就無法通過這種方法來恢復數據了。
9、雖然優點多多，但AOF方式也同樣存在缺陷，比如在同樣數據規模的情況下，AOF文件要比RDB文件的體積大。而且，AOF方式的恢復速度也要慢於RDB方式。
如果你直接執行BGREWRITEAOF命令，那麼redis會生成一個全新的AOF文件，其中便包括了可以恢復現有數據的最少的命令集。
10、如果運氣比較差，AOF文件出現了被寫壞的情況，也不必過分擔憂，redis並不會貿然加載這個有問題的AOF文件，而是報錯退出。這時可以通過以下步驟來修復出錯的文件：
1.備份被寫壞的AOF文件
2.運行redis-check-aof –fix進行修復
3.用diff -u來看下兩個文件的差異，確認問題點
4.重啓redis，加載修復後的AOF文件
AOF持久化策略：
AOF_FSYNC_NO ：每次都會把aof_buf中的內容寫入到磁盤，但是不會調用fsync函數；
AOF_FSYNC_ALWAYS ：每次都會把aof_buf中的內容寫入到磁盤，同時調用fsync函數；
AOF_FSYNC_EVERYSEC
由於AOF_FSYNC_ALWAYS每次都寫入文件都會調用fsync，所以這種flush策略可以保證數據的完整性，缺點就是性能太差（因爲fysnc是個同步調用，會阻塞主進程對客戶端請求的處理），而AOF_FSYNC_NO由於依賴於操作系統自動sync，因此不能保證數據的完整性；
那有沒有一種折中的方式：既能不過分降低系統的性能，又能最大程度上的保證數據的完整性，答案就是：AOF_FSYNC_EVERYSEC，AOF_FSYNC_EVERYSEC的flush策略是：定期（至少1s）去調用fsync，並且該操作是放到一個異步隊列中（線程）去執行，因此不會阻塞主進程
AOF 後臺執行的方式和 RDB 有類似的地方，fork 一個子進程，主進程仍進行服務，子進程執行 AOF 持久化，數據被 dump 到磁盤上。與 RDB 不同的是，後臺子進程持久化過程中，主進程會記錄期間的所有數據變更（主進程還在服務），並存儲在 server.aof_rewrite_buf_blocks 中；後臺子進程結束後，redis 更新緩存追加到 AOF 文件中，是 RDB 持久化所不具備的.
四、redis持久化----AOF重寫
1、AOF重寫的內部運行原理，我們有必要了解一下。
2、在重寫即將開始之際，redis會創建（fork）一個“重寫子進程”，這個子進程會首先讀取現有的AOF文件，並將其包含的指令進行分析壓縮並寫入到一個臨時文件中。
3、與此同時，主工作進程會將新接收到的寫指令一邊累積到內存緩衝區中，一邊繼續寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過程中出現意外。
4、當“重寫子進程”完成重寫工作後，它會給父進程發一個信號，父進程收到信號後就會將內存中緩存的寫指令追加到新AOF文件中。
5、當追加結束後，redis就會用新AOF文件來代替舊AOF文件，之後再有新的寫指令，就都會追加到新的AOF文件中了。
五、redis持久化----如何選擇RDB和AOF
1、對於我們應該選擇RDB還是AOF，官方的建議是兩個同時使用。這樣可以提供更可靠的持久化方案。
2、redis的備份和還原，可以藉助第三方的工具redis-dump。
六、Redis的兩種持久化方式也有明顯的缺點
1、RDB需要定時持久化，風險是可能會丟兩次持久之間的數據，量可能很大。
2、AOF每秒fsync一次指令硬盤，如果硬盤IO慢，會阻塞父進程；風險是會丟失1秒多的數據；在Rewrite過程中，主進程把指令存到mem-buffer中，最後寫盤時會阻塞主進程。
參考文檔：
https://blog.csdn.net/ljheee/article/details/76284082
https://blog.csdn.net/Erica_1230/article/details/51305552