在生產環境中我們需要保證 Redis 實例中數據的可靠性，防止數據丟失。為此需要了解Redis的持久化方式。本文主要介紹Redis提供的持久化方式。
- RDB 在指定時間間隔內生成時間點的數據快照（point-in-time snapshot）。
- AOF（append-only file）記錄服務器執行的所有寫操作命令，并在服務器啟動時，通過重新執行這些命令來還原數據集。 AOF 文件中的命令全部以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。 Redis 還可以在后臺對 AOF 文件進行重寫（rewrite），使得 AOF 文件的體積不會超出保存數據集狀態所需的實際大小。
- 同時使用RDB、AOF 兩種方式。 在這種情況下， 當 Redis 重啟時， 它會優先使用 AOF 文件來還原數據集， 因為 AOF 文件保存的數據集通常比 RDB 文件所保存的數據集更完整。
Redis 官方推薦同時使用 RDB 和 AOF 兩種持久化方式。官方在未來可能會將兩種持久化方式整合成單個持久化模型。
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 的優點
可以指定不同的fsync策略，不會發生數據丟失
- 使用 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 的缺點
備份速度慢于RDB，備份文件體積大于RDB。
- 對于相同的數據集來說，AOF 文件的體積通常要大于 RDB 文件的體積。
- 根據所使用的 fsync 策略，AOF 的速度可能會慢于 RDB 。 在一般情況下， 每秒 fsync 的性能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（latency）。
- AOF 在過去曾經發生過這樣的 bug ： 因為個別命令的原因，導致 AOF 文件在重新載入時，無法將數據集恢復成保存時的原樣。 （舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug 。） 測試套件里為這種情況添加了測試： 它們會自動生成隨機的、復雜的數據集， 并通過重新載入這些數據來確保一切正常。 雖然這種 bug 在 AOF 文件中并不常見， 但是對比來說， RDB 幾乎是不可能出現這種 bug 的。
本文內容大部分來源于以下兩篇文章：
