目錄
PS：小編另外一篇關於持久化快照的文章：https://blog.csdn.net/kzadmxz/article/details/75913259
Redis兩種持久化的方式：
RDB持久化可以在指定的時間間隔內生成數據集的時間點快照
AOF持久化記錄服務器執行的所有寫操作命令,並在服務器啓動時,通過重新執行這些命令來還原數據集,AOF文件中全部以redis協議的格式來保存,新命令會被追加到文件的末尾,redis還可以在後臺對AOF文件進行重寫,文件的體積不會超出保存數據集狀態所需要的實際大小。
兩種持久化方式可以單獨使用其中一種，也可以將這兩種方式結合使用。 同時使用時，當redis重啓時，它會優先使用AOF文件來還原數據集，因爲AOF文件保存的數據集通常比RDB文件所保存的數據集更加完整。
一、RDB方式
當符合一定條件時，Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，等到持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能。如果需要進行大規模數據的恢復，且對於數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最後一次持久化後的數據可能丟失
fork的作用是複製一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，但是是一個全新的進程，並作爲原進程的子進程
Redis會在以下幾種情況下對數據進行快照：
1、根據配置規則進行自動快照
Redis允許用戶自定義快照條件，當符合快照條件時，Redis會自動執行快照操作。快照的條件可以由用戶在配置文 件中配置。配置格式如下
save
第一個參數是時間窗口，第二個是鍵的個數，也就是說，在第一個時間參數配置範圍內被更改的鍵的個數大於後面 的changes時，即符合快照條件。redis默認配置了三個規則
save 900 1
save 300 10
save 60 10000
每條快照規則佔一行，每條規則之間是“或”的關係。 在900秒（15分）內有一個以上的鍵被更改則進行快照。
2、用戶執行SAVE或BGSAVE命令
除了讓Redis自動進行快照以外，當我們對服務進行重啓或者服務器遷移我們需要人工去幹預備份。
redis提供了兩 條命令來完成這個任務
（1）save命令
當執行save命令時，Redis同步做快照操作，在快照執行過程中會阻塞所有來自客戶端的請求。當redis內存中的數 據較多時，通過該命令將導致Redis較長時間的不響應。所以不建議在生產環境上使用這個命令，而是推薦使用bgsave命令
（2） bgsave命令
bgsave命令可以在後臺異步地進行快照操作，快照的同時服務器還可以繼續響應來自客戶端的請求。執行BGSAVE
後，Redis會立即返回ok表示開始執行快照操作。
通過LASTSAVE命令可以獲取最近一次成功執行快照的時間； （自動快照採用的是異步快照操作）
3、執行FLUSHALL命令
該命令在前面講過，會清除redis在內存中的所有數據。執行該命令後，只要redis中配置的快照規則不爲空，也就 是save 的規則存在。redis就會執行一次快照操作。不管規則是什麼樣的都會執行。如果沒有定義快照規則，就不會執行快照操作
4、執行復制時
該操作主要是在主從模式下，redis會在複製初始化時進行自動快照。這個會在後面講到；
這裏只需要瞭解當執行復制操作時，及時沒有定義自動快照規則，並且沒有手動執行過快照操作，它仍然會生成RDB快照文件。
RDB優點
RDB 是一個非常緊湊（compact）的文件，它保存了 Redis 在某個時間點上的數據集。 這種文件非常適合用於進行備份： 比如說，你可以在最近的 24 小時內，每小時備份一次 RDB 文件，並且在每個月的每一天，也備份一個 RDB 文件。 這樣的話，即使遇上問題，也可以隨時將數據集還原到不同的版本。
RDB 非常適用於災難恢復（disaster recovery）：它只有一個文件，並且內容都非常緊湊，可以（在加密後）將它傳送到別的數據中心，或者亞馬遜 S3 中。
RDB 可以最大化 Redis 的性能：父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然後這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁盤 I/O 操作。
RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快
RDB缺點
如果你需要儘量避免在服務器故障時丟失數據，那麼 RDB 不適合你。 雖然 Redis 允許你設置不同的保存點（save point）來控制保存 RDB 文件的頻率， 但是， 因爲RDB 文件需要保存整個數據集的狀態， 所以它並不是一個輕鬆的操作。 因此你可能會至少 5 分鐘才保存一次 RDB 文件。 在這種情況下， 一旦發生故障停機， 你就可能會丟失好幾分鐘的數據。
每次保存 RDB 的時候，Redis 都要 fork() 出一個子進程，並由子進程來進行實際的持久化工作。 在數據集比較龐大時， fork()可能會非常耗時，造成服務器在某某毫秒內停止處理客戶端； 如果數據集非常巨大，並且 CPU 時間非常緊張的話，那麼這種停止時間甚至可能會長達整整一秒。
雖然 AOF 重寫也需要進行 fork() ，但無論 AOF 重寫的執行間隔有多長，數據的耐久性都不會有任何損失。
二、AOF方式
當使用Redis存儲非臨時數據時，一般需要打開AOF持久化來降低進程終止導致的數據丟失。
AOF可以將Redis執行的每一條寫命令追加到硬盤文件中，這一過程會降低Redis的性能，但大部分情況下這個影響是能夠接受的，另外使用較快的硬盤可以提高AOF的性能。
開啓AOF
默認情況下Redis沒有開啓AOF（append only file）方式的持久化，可以通過appendonly參數啓用，在redis.conf中找appendonly yes
開啓AOF持久化後每執行一條會更改Redis中的數據的命令後，Redis就會將該命令寫入硬盤中的AOF文件。
AOF文件的保存位置和RDB文件的位置相同，都是通過dir參數設置的，默認的文件名是apendonly.aof. 可以在redis.conf 中的屬性 appendfilename appendonlyh.aof修改。
AOF的實現
AOF文件以純文本的形式記錄Redis執行的寫命令，例如 開啓AOF持久化 的情況下執行如下4條命令：
set foo 1
set foo 2
set foo 3 get
redis 會將前3條命令寫入AOF文件中，通過vim的方式可以看到aof文件中的內容
|
我們會發現AOF文件的內容正是Redis發送的原始通信協議的內容，從內容中我們發現Redis只記錄了3 條命令。然後這時有一個問題是前面2條命令其實是冗餘的，因爲這兩條的執行結果都會被第三條命令覆 蓋。隨着執行的命令越來越多，AOF文件的大小也會越來越大，其實內存中實際的數據可能沒有多少， 那這樣就會造成磁盤空間以及redis數據還原的過程比較長的問題。因此我們希望Redis可以自動優化 AOF文件，就上面這個例子來說，前面兩條是可以被刪除的。 而實際上Redis也考慮到了，可以配置一個條件，每當達到一定條件時Redis就會自動重寫AOF文件，這個條件的配置問 auto-aof-rewrite- percentage 100 auto-aof-rewrite-min-size 64mb |
auto-aof-rewrite-percentage 表示的是當目前的AOF文件大小超過上一次重寫時的AOF文件大小的百分之多少時會再次進行重寫，如果之前沒有重寫過，則以啓動時AOF文件大小爲依據
auto-aof-rewrite-min-size 表示限制了允許重寫的最小AOF文件大小，通常在AOF文件很小的情況下即使其中有很多冗餘的命令我們也並不太關心。
另外，還可以通過BGREWRITEAOF 命令手動執行AOF，執行完以後冗餘的命令已經被刪除了
在啓動時，Redis會逐個執行AOF文件中的命令來將硬盤中的數據載入到內存中，載入的速度相對於RDB會慢一些
AOF的重寫原理
Redis 可以在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。
重寫的流程是這樣，主進程會fork一個子進程出來進行AOF重寫，這個重寫過程並不是基於原有的aof文件來做的，而是有點類似於快照的方式，全量遍歷內存中的數據，然後逐個序列到aof文件中。在fork子進程這個過程中，服務端仍然可以對外提供服務，那這個時候重寫的aof文件的數據和redis內存數據不一致了怎麼辦？不用擔心，這個過程中，主進程的數據更新操作，會緩存到aof_rewrite_buf中，也就是單獨開闢一塊緩存來存儲重寫期間 收到的命令，當子進程重寫完以後再把緩存中的數據追加到新的aof文件。
當所有的數據全部追加到新的aof文件中後，把新的aof文件重命名爲，此後所有的操作都會被寫入新的aof文件。
如果在rewrite過程中出現故障，不會影響原來aof文件的正常工作，只有當rewrite完成後纔會切換文件。因此這個rewrite過程是比較可靠的。
AOF 優點
使用 AOF 持久化會讓 Redis 變得非常耐久（much more durable）：你可以設置不同的 fsync 策略，比如無 fsync ，每秒鐘一次 fsync ，或者每次執行寫入命令時 fsync 。
AOF 的默認策略爲每秒鐘 fsync 一次，在這種配置下，Redis仍然可以保持良好的性能，並且就算髮生故障停機，也最多隻會丟失一秒鐘的數據（ fsync 會在後臺線程執行，所以主線程可以繼續努力地處理命令請求）。
AOF 文件是一個只進行追加操作的日誌文件（append only log）， 因此對 AOF 文件的寫入不需要進行 seek ， 即使日誌因爲某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機，等等）， redis-check-aof 工具也可以輕易地修復這種問題。
Redis 可以在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。 整個重寫操作是絕對安全的，因爲 Redis 在創建新 AOF 文件的過程中，會繼續將命令追加到現有的 AOF 文件裏面，即使重寫過程中發生停機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操作。
AOF 文件有序地保存了對數據庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。
AOF 缺點
對於相同的數據集來說，AOF 文件的體積通常要大於 RDB 文件的體積。
根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。
AOF 在過去曾經發生過這樣的 bug ： 因爲個別命令的原因，導致 AOF 文件在重新載入時，無法將數據集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug 。） 測試套件裏爲這種情況添加了測試： 它們會自動生成隨機的、複雜的數據集， 並通過重新載入這些數據來確保一切正常。 雖然這種 bug 在 AOF 文件中並不常見， 但是對比來說， RDB 幾乎是不可能出現這種 bug 的。
PS：小編另外一篇關於持久化快照的文章：https://blog.csdn.net/kzadmxz/article/details/75913259