本文轉自互聯網
本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裏查看
喜歡的話麻煩點下Star哈
文章首發於我的個人博客：
www.how2playlife.com
本文是微信公衆號【Java技術江湖】的《探索Redis設計與實現》其中一篇，本文部分內容來源於網絡，爲了把本文主題講得清晰透徹，也整合了很多我認爲不錯的技術博客內容，引用其中了一些比較好的博客文章，如有侵權，請聯繫作者。
該系列博文會告訴你如何從入門到進階，Redis基本的使用方法，Redis的基本數據結構，以及一些進階的使用方法，同時也需要進一步瞭解Redis的底層數據結構，再接着，還會帶來Redis主從複製、集羣、分佈式鎖等方面的相關內容，以及作爲緩存的一些使用方法和注意事項，以便讓你更完整地瞭解整個Redis相關的技術體系，形成自己的知識框架。
如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公衆號【Java技術江湖】聯繫作者，歡迎你參與本系列博文的創作和修訂。
轉自https://blog.csdn.net/xlgen157387/article/details/61925524
前言
我們知道Redis是一款內存服務器，就算我們對自己的服務器足夠的信任，不會出現任何軟件或者硬件的故障，但也會有可能出現突然斷電等情況，造成Redis服務器中的數據失效。因此，我們需要向傳統的關係型數據庫一樣對數據進行備份，將Redis在內存中的數據持久化到硬盤等非易失性介質中，來保證數據的可靠性。
將Redis內存服務器中的數據持久化到硬盤等介質中的一個好處就是，使得我們的服務器在重啓之後還可以重用以前的數據，或者是爲了防止系統出現故障而將數據備份到一個遠程的位置。
還有一些場景，例如：
對於一些需要進行大量計算而得到的數據，放置在Redis服務器，我們就有必要對其進行數據的持久化，如果需要對數據進行恢復的時候，我們就不需進行重新的計算，只需要簡單的將這臺機器上的數據複製到另一臺需要恢復的Redis服務器就可以了。Redis給我們提供了兩種不同方式的持久化方法：快照（Snapshotting） 和 只追加文件（append-only-file）。
（1）名詞簡介
快照（RDB）：就是我們俗稱的備份，他可以在定期內對數據進行備份，將Redis服務器中的數據持久化到硬盤中；
只追加文件（AOF）：他會在執行寫命令的時候，將執行的寫命令複製到硬盤裏面，後期恢復的時候，只需要重新執行一下這個寫命令就可以了。類似於我們的MySQL數據庫在進行主從複製的時候，使用的是binlog二進制文件，同樣的是執行一遍寫命令；
（2）快照持久化通用的配置：
save 60 1000 #60秒時間內有1000次寫入操作的時候執行快照的創建stop-writes-on-bgsave-error no #創建快照失敗的時候是否仍然繼續執行寫命令rdbcompression yes #是否對快照文件進行壓縮dbfilename dump.rdb #如何命名硬盤上的快照文件dir ./ #快照所保存的位置（3）AOP持久化配置：
appendonly no #是否使用AOF持久化appendfsync everysec #多久執行一次將寫入內容同步到硬盤上no-appendfsync-on-rewrite no #對AOF進行壓縮的時候能否執行同步操作auto-aof-rewrite-percentage 100 #多久執行一次AOF壓縮auto-aof-rewrite-min-size 64mb #多久執行一次AOF壓縮dir ./ #AOF所保存的位置需要注意的是：這兩種持久化的方式既可以單獨的使用，也可以同時使用，具體選擇哪種方式需要根據具體的情況進行選擇。
快照持久化
快照就是我們所說的備份。用戶可以將Redis內存中的數據在某一個時間點進行備份，在創建快照之後，用戶可以對快照進行備份。通常情況下，爲了防止單臺服務器出現故障造成所有數據的丟失，我們還可以將快照複製到其他服務器，創建具有相同數據的數據副本，這樣的話，數據恢復的時候或者服務器重啓的時候就可以使用這些快照信息進行數據的恢復，也可以防止單臺服務器出現故障的時候造成數據的丟失。
但是，沒我們還需要注意的是，創建快照的方式，並不能完全保證我們的數據不丟失，這個大家可以很好的理解，因爲快照的創建時定時的，並不是每一次更新操作都會創建一個快照的。系統發生崩潰的時候，用戶將丟失最近一次生成快照之後更改的所有數據。因此，快照持久化的方式只適合於數據不經常修改或者丟失部分數據影響不大的場景。
一、創建快照的方式：
（1）客戶端通過向Redis發送BGSAVE 命令來創建快照。
使用BGSAVE的時候，Redis會調用fork來創建一個子進程，然後子進程負責將快照寫到硬盤中，而父進程則繼續處理命令請求。
使用場景：
如果用戶使用了save設置，例如：save 60 1000 ,那麼從Redis最近一次創建快照之後開始計算，當“60秒之內有1000次寫入操作”這個條件滿足的時候，Redis就會自動觸發BGSAVE命令。
如果用戶使用了多個save設置，那麼當任意一個save配置滿足條件的時候，Redis都會觸發一次BGSAVE命令。
（2）客戶端通過向Redis發送SAVE 命令來創建快照。
接收到SAVE命令的Redis服務器在快照創建完畢之前將不再響應任何其他命令的請求。SAVE命令並不常用，我們通常只在沒有足夠的內存去執行BGSAVE命令的時候纔會使用SAVE命令，或者即使等待持久化操作執行完畢也無所謂的情況下，纔會使用這個命令；
使用場景：
當Redis通過SHUTDOWN命令接收到關閉服務器的請求時，或者接收到標準的TERM信號時，會執行一次SAVE命令，阻塞所有的客戶端，不再執行客戶端發送的任何命令，並且在執行完SAVE命令之後關閉服務器。
二、使用快照持久化注意事項：
我們在使用快照的方式來保存數據的時候，如果Redis服務器中的數據量比較小的話，例如只有幾個GB的時候。Redis會創建子進程並將數據保存到硬盤裏邊，生成快照所需的時間比讀取數據所需要的時間還要短。
但是，隨着數據的增大，Redis佔用的內存越來越大的時候，BGSAVE在創建子進程的時候消耗的時間也會越來越多，如果Redis服務器所剩下的內存不多的時候，這行BGSAVE命令會使得系統長時間地停頓，還有可能導致服務器無法使用。
各虛擬機類別，創建子線程所耗時間：
因此，爲了防止Redis因爲創建子進程的時候出現停頓，我們可以考慮關閉自動保存，轉而通過手動的方式發送BGSAVE或者SAVE來進行持久化，
手動的方式發送BGSAVE也會出現停頓的現象，但是我們可以控制發送該命令的時間來控制出現停頓的時候不影響具體的業務請求。
另外，值得注意的是，在使用SAVE命令的時候，雖然會一直阻塞Redis直到快照生成完畢，但是其不需要創建子進程，所以不會向BGSAVE一樣，因爲創建子進程而導致Redis停頓。也正因爲如此，SAVE創建快照的速度要比BGSAVE創建快照的速度更快一些。
創建快照的時候，我們可以在業務請求，比較少的時候，比如凌晨三、四點，通過手寫腳本的方式，定時執行。
AOF持久化
AOF持久化會將被執行的寫命令寫到AOF文件的末尾，以此來記錄數據發生的變化。這樣，我們在恢復數據的時候，只需要從頭到尾的執行一下AOF文件即可恢復數據。
一、打開AOF持久化選項
我們可以通過使用如下命令打開AOF：
appendonly yes我們，通過如下命令來配置AOF文件的同步頻率：
appendfsync everysec/always/no二、appendfsync同步頻率的區別
appendfsync同步頻率的區別如下圖：
（1）always的方式固然可以對沒一條數據進行很好的保存，但是這種同步策略需要對硬盤進行大量的寫操作，所以Redis處理命令的速度會受到硬盤性能的限制。
普通的硬盤每秒鐘只能處理大約200個寫命令，使用固態硬盤SSD每秒可以處理幾萬個寫命令，但是每次只寫一個命令，這種只能怪不斷地寫入很少量的數據的做法有可能引發嚴重的寫入放大問題，這種情況下降嚴重影響固態硬盤的使用壽命。
（2）everysec的方式，Redis以每秒一次的頻率大隊AOF文件進行同步。這樣的話既可以兼顧數據安全也可以兼顧寫入性能。
Redis以每秒同步一次AOF文件的性能和不使用任何持久化特性時的性能相差無幾，使用每秒更新一次 的方式，可以保證，即使出現故障，丟失的數據也在一秒之內產生的數據。
（3）no的方式，Redis將不對AOF文件執行任何顯示的同步操作，而是由操作系統來決定應該何時對AOF文件進行同步。
這個命令一般不會對Redis的性能造成多大的影響，但是當系統出現故障的時候使用這種選項的Redis服務器丟失不定數量的數據。
另外，當用戶的硬盤處理寫入操作的速度不夠快的話，那麼緩衝區被等待寫入硬盤的數據填滿時，Redis的寫入操作將被阻塞，並導致Redis處理命令請求的速度變慢，因爲這個原因，一般不推薦使用這個選項。
三、重寫/壓縮AOF文件
隨着數據量的增大，AOF的文件可能會很大，這樣在每次進行數據恢復的時候就會進行很長的時間，爲了解決日益增大的AOF文件，用戶可以向Redis發送BGREWRITEAOF 命令，這個命令會通過移除AOF文件中的冗餘命令來重寫AOF文件，是AOF文件的體檢變得儘可能的小。
BGREWRITEAOF的工作原理和BGSAVE的原理很像：Redis會創建一個子進程，然後由子進程負責對AOF文件的重寫操作。
因爲AOF文件重寫的時候匯創建子進程，所以快照持久化因爲創建子進程而導致的性能和內存佔用問題同樣會出現在AOF文件重寫的 時候。
四、觸發重寫/壓縮AOF文件條件設定
AOF通過設置auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 選項來自動執行BGREWRITEAOF。
其具體含義，通過實例可以看出，如下配置：
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb表示當前AOF的文件體積大於64MB，並且AOF文件的體積比上一次重寫之後的體積變大了至少一倍（100%）的時候，Redis將執行重寫BGREWRITEAOF命令。
如果AOF重寫執行的過於頻繁的話，可以將auto-aof-rewrite-percentage 選項的值設置爲100以上，這種最偶發就可以讓Redis在AOF文件的體積變得更大之後才執行重寫操作，不過，這也使得在進行數據恢復的時候執行的時間變得更加長一些。
驗證快照文件和AOF文件
無論使用哪種方式進行持久化，我們在進行恢復數據的時候，Redis提供了兩個命令行程序：
redis-check-aofredis-check-dump他們可以再系統發生故障的時候，檢查快照和AOF文件的狀態，並對有需要的情況對文件進行修復。
如果用戶在運行redis-check-aof命令的時候，指定了--fix 參數，那麼程序將對AOF文件進行修復。
程序修復AOF文件的方法很簡單：他會掃描給定的AOF文件，尋找不正確或者不完整的命令，當發現第一個出現錯誤命令的時候，程序會刪除出錯命令以及出錯命令之後的所有命令，只保留那些位於出錯命令之前的正確命令。大部分情況，被刪除的都是AOF文件末尾的不完整的寫命令。
總結
上述，一起學習了兩種支持持久化的方式，一方面我們需要通過快照或者AOF的方式對數據進行持久化，另一方面，我們還需要將持久化所得到的文件進行備份，備份到不同的服務器上，這樣纔可以儘可能的減少數據丟失的損失。
參考文章：
1、Redis in Action - [美] Josiah L.Carlsono