因為 redis是一個內存資料庫，所有數據都存儲在內存中，而且內存中的數據非常容易丟失，所以 redis的數據持久化就變得非常重要， redis提供了兩種數據持久化方法，分別用於 RDB和 AOF，而 redis默認用於 RDB的數據持久化方法。
一、RDB持久性方案簡介
RDB方案簡介：
Redis將定期將數據快照保存到 rdb文件中，並在啟動時自動裝入 rdb文件，以恢復之前保存的數據。可將 Redis配置為在配置文件中保存快照。
save [seconds] [changes]
意思是[seconds]秒內如果發生了[changes]次數據修改，則進行一次RDB快照保存，例如：
save 60 100
每隔60秒 Redis就會檢查一次數據更改，如果發生了100次或更多的數據更改，將保存 RDB快照。多個 save指令可以進行配置， Redis可以執行多層快照保存策略。默認打開 RDB快照。RDB快照保存還可以通過 SAVE或 BGSAVE命令手動觸發。
在 SAVE和 BGSAVE命令中， rdbSave函數都被調用，但是它們以不同的方式調用：
1、在保存完成之前， SAVE直接調用 rdbSave來阻塞 Redis主進程。伺服器無法在主進程阻塞期間處理客戶機的任何請求。
2、而 BGSAVE則把子進程 fork出來，該進程負責調用 rdbSave，並在保存完成後向主進程發出通知，告知保存完成。在 BGSAVE執行過程中， Redis伺服器仍可繼續處理客戶機請求。
RDB方案好處：
1、最低限度的性能影響。如前所述，當保存 RDB快照時， Redis將對 fork出子進程執行，這幾乎不會影響 Redis處理客戶機請求的效率。
2、每一張快照都會產生一個完整的數據快照文件，因此可以用其他方法來同時保存多個時間點的快照(例如將每天0點的快照備份到其他存儲介質)，作為非常可靠的災難恢復方法。
3、與 AOF相比，使用 RDB文件的數據恢復更快
RDB模式缺陷：
1、快照是定期生成的，因此當使用 Redis crash時，數據的一部分或多或少會丟失。
2、當數據集非常大， CPU不夠強時(例如單核 CPU), Redis可能會花費相對較長的 fork子進程時間，從而影響 Redis外部服務的提供。
RDB方案配置：
修改redis的配置文件：
重啟 redis Service每生成一個新的 dump. rdb，就覆蓋以前的舊快照
二、AOF持久化方案簡介
1、AOF方案簡介：
AOF (append only file)持久化：將每個寫入命令以獨立日誌的方式記錄下來，重啟後再重新執行 AOF文件中的命令，以實現數據恢復。AOF的主要功能是處理數據持久的實時性，目前， AOF已成為 Redis持久性的主流方式。了解掌握 AOF的持久性機制對於我們處理數據安全和性能方面非常有幫助。
2、運用AOF：
打開 AOF功能要求進行設置配置： appendonlyyes，默認不啟用。通過 appendfilename配置設置 AOF文件名，默認的文件名是appendonly.ao f。通過 dir配置指定，保存路徑與 RDB持久化方式一致。AOF工作流程操作 ：命令寫入(append)，文件同步(sync)，文件重寫(rewrite)，重新啟動裝載(load)，如圖所示。
執行流程：
1、所有的寫入命令會追加到aof_buf（緩衝區）中。
2、根據相應的策略， AOF緩衝區對硬碟進行同步操作。
3、當 AOF文件變得更大時，需要定期重寫 AOF文件，以實現壓縮。
4、重啟 Redis伺服器後，可以加載用於數據恢復的 AOF文件。
3、文件同步：
Redis提供了多種 AOF緩衝同步文件策略，這些策略由 appendfsync參數控制，圖中顯示了不同值的含義。
3.1、當配置為 always時，每次寫入都會同步 AOF文件，而在普通 SATA硬碟上， Redis只支持大約數百 TPS寫入，這顯然與 Redis的高性能特性背道而馳，因此不推薦使用。
3.2、配置為 no，因為作業系統對 AOF文件的每一次同步都是不可控制的周期，並且會增加每一次同步硬碟的數據量，雖然提高了性能，但是數據安全沒有保障。
3.3、配置為everysec，建議採用同步策略和默認策略，以兼顧性能和數據安全。
4、重寫機制：
AOF會隨著命令的執行而變大，為了解決這個問題， Redis引入了 AOF覆蓋機制來壓縮文件。AOF文件覆蓋是將 Redis進程中的數據轉換成寫入命令，使其與新 AOF文件同步的過程。
為什麼覆蓋了 AOF的文件可以變小？原因如下：
1、已在進程中超時的數據不再寫入文件。
2、以前的 AOF文件中包含諸如 delkey1, hdelkey2, srem keys,seta111, seta222等等無效命令。覆蓋直接使用進程中的數據生成，因此新的 AOF文件只保存最終數據的寫入命令。
3、可以將多個寫命令合併成一個，例如： lpush list a,、lpush list b、lpush list c可轉換為： lpush list a b c 。為避免單個命令太大導致客戶端緩衝區溢出，對於 list, set, hash, zset之類的類型操作，將多個元素分割成64個界限。
AOF重寫減少了文件佔用空間，除此之外，還有另外一個目的： Redis可以更快地加載更小的 AOF文件。
可手動或自動觸發 AOF重寫過程：
手動觸發：直接調用命令 bgrewriteaof。
自動觸發：Auto-aof-rewrite-min-size和Auto-aof-rewrite-percentage參數決定了自動觸發的時間點。
解釋：
1、auto-aof-rewrite-min-size：表示在運行 AOF覆蓋時，文件的最小體積，默認值為64 MB。
2、auto-aof-rewrite-percentage：表示 AOF文件空間(aof_current_size)與上次重寫後的 AOF文件空間之間的比值。
3、自動觸發時機=aof_current_size>auto-aof-rewrite-min-size&&(aof_current_size-aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage
AOF場景配置：
1、在 redis中， aof的持久化機制默認關閉2、AOF持久化默認為關閉的 ，RDB持久化默認為打開
3、appendonly yes，能夠打開 AOF持久機制，在生產環境中，通常 AOF都會被打開，除非你不介意數據被隨意丟失幾分鐘
4、在打開 AOF持久化機制後， redis每次收到寫命令時，都會將其寫入日誌文件，當然是先寫入 os cache，然後每隔一段時間再進行 fsync5、當 AOF和 RDB都打開並且 redis重新啟動時，優先使用 AOF恢復數據，因為 aof數據比較完整
AOF的 fsync策略可以進行配置，有三種策略可供選擇：
1、一種是每次寫入數據時都執行一次 fsync。
2、另一種是每隔一秒執行一次 fsync。
3、另一種是不主動執行 fsync。
always：每寫一次，就把相應於該數據的寫日誌 fsync放到磁碟上，性能非常糟糕，吞吐量也很低；要確保說 redis中的一個數據不會丟失，只能這樣。redis中的默認 AOF持久性機制全部關閉
Redis的AOF持久化機制配置：
重新啟動 redis實例，並在執行簡單操作後關閉該實例，重新啟動 redis實例。
三、重啟加載流程：
如果覺得對你有所幫助。記得收藏和關注呦！（每日更新各種大數據框架）如需轉載請註明出處（創作不易請見諒）和巨嬰程序猿一起成長。讓自己變得更優秀想了解更多精彩內容，快來關注跟著巨嬰去逆襲我最近一直在思考（大數據通俗講解）的問題，你的看法是什麼呢？關注我快說出來一起交流一下吧~