關於Redis說點什麼，目前都是使用Redis作為資料快取，快取的目標主要是那些需要經常訪問的資料，或計算複雜而耗時的資料。快取的效果就是減少了資料庫讀的次數，減少了複雜資料的計算次數，從而提高了伺服器的效能。

一、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檔案

四、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中，最後寫盤時會阻塞主程序。

3、這兩個缺點是個很大的痛點。為了解決這些痛點，GitHub的兩位工程師 Bryana Knight 和 Miguel Fernández 日前寫了一篇 文章 ，講述了將持久資料從Redis遷出的經驗：