Redis持久化

redis雖然是一種記憶體型資料庫，但也提供持久化方案，將記憶體中的資料儲存到磁碟中，避免資料丟失。

redis支援兩種持久化方案：

• RDB：在指定的時間間隔內生成資料集的時間點快照（point-in-time snapshot）。

• AOF：記錄每次對redis伺服器寫的操作，當伺服器重啟時會重新執行這些命令來恢復原始資料。

Redis 還支援同時使用 AOF 持久化和 RDB 持久化。 在這種情況下， 當 Redis 重啟時， 它會優先使用 AOF 檔案來還原資料集， 因為 AOF 檔案儲存的資料集通常比 RDB 檔案所儲存的資料集更完整。

RDB持久化

在預設情況下， Redis 將資料庫快照儲存在名字為 dump.rdb

RDB命令

RDB檔案可以通過兩個命令建立：

• SAVE： 執行一個同步儲存操作（會阻塞redis的服務程序），將當前 Redis 例項的所有資料快照(snapshot)以 RDB 檔案的形式儲存到硬碟。
• BGSAVE：主程序fork一個子程序來建立新的RDB檔案，記錄接收到的BGSAVE時刻的資料庫狀態，父程序繼續處理接收到的命令。當子程序完成寫臨時檔案後，用新 RDB 檔案替換原來的 RDB 檔案，並刪除舊的 RDB 檔案。

一般來說，在生產環境很少執行 SAVE 操作，因為它會阻塞所有客戶端，儲存資料庫的任務通常由 BGSAVE 命令非同步地執行。然而，如果負責儲存資料的後臺子程序不幸出現問題時，

優點

• RDB 檔案是經過壓縮的二進位制檔案，佔用的空間會小於記憶體中的資料，更加利於傳輸，非常適合用於進行備份。
• RDB 在恢復大資料集時的速度比 AOF 的恢復速度要快。

缺點

• 使用 RDB 方式實現持久化，一旦 Redis 異常退出，就會丟失最後一次快照以後更改的所有資料。這個時候我們就需要根據具體的應用場景，通過組合設定自動快照條件的方式來將可能發生的資料損失控制在能夠接受範圍。

AOF持久化

快照功能並不是非常耐久（durable）： 如果 Redis 因為某些原因而造成故障停機， 那麼伺服器將丟失最近寫入、且仍未儲存到快照中的那些資料。從 1.1 版本開始， Redis 增加了一種完全耐久的持久化方式： AOF（append-only file） 持久化。

具體來說，RDB持久化相當於備份資料庫狀態，而AOF持久化是備份資料庫接收到的命令，所有被寫入AOF的命令都是以redis的協議格式來儲存的。

AOF檔案重寫機制

AOF（append-only file）的運作方式是不斷地將命令追加到檔案的末尾， 所以隨著寫入命令的不斷增加， AOF 檔案的體積也會變得越來越大。但AOF 檔案體積變得過大時，Redis自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 檔案包含了恢復當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在建立新 AOF 檔案的過程中，會繼續將命令追加到現有的 AOF 檔案裡面，即使重寫過程中發生停機，現有的 AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢，Redis 就會從舊 AOF 檔案切換到新 AOF 檔案，並開始對新 AOF 檔案進行追加操作。

AOF檔案修復機制

伺服器可能在程式正在對 AOF 檔案進行寫入時停機， 如果停機造成了 AOF 檔案出錯（corrupt）， 那麼 Redis 在重啟時會拒絕載入這個 AOF 檔案， 從而確保資料的一致性不會被破壞。

當發生這種情況時， 可以用以下方法來修復出錯的 AOF 檔案：

1. 為現有的 AOF 檔案建立一個備份。

2. 使用 Redis 附帶的 redis-check-aof 程式，對原來的 AOF 檔案進行修復。

   $ redis-check-aof --fix
   

3. （可選）使用 diff -u 對比修復後的 AOF 檔案和原始 AOF 檔案的備份，檢視兩個檔案之間的不同之處。

4. 重啟 Redis 伺服器，等待伺服器載入修復後的 AOF 檔案，並進行資料恢復。

優點

• 使用 AOF 的優點是會讓 Redis 變得非常耐久。可以設定不同的 fsync 策略，AOF的預設策略是每秒鐘 fsync 一次，在這種配置下，就算髮生故障停機，也最多丟失一秒鐘的資料。
• AOF 檔案有序地儲存了對資料庫執行的所有寫入操作， 這些寫入操作以 Redis 協議的格式儲存， 因此 AOF 檔案的內容非常容易被人讀懂， 對檔案進行分析（parse）也很輕鬆。

缺點

• AOF 檔案的體積通常要大於 RDB 檔案的體積。
• 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的效能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。

RDB 和 AOF ，我應該用哪一個?

一般來說， 如果想達到足以媲美 PostgreSQL 的資料安全性， 你應該同時使用兩種持久化功能。

如果你非常關心你的資料， 但仍然可以承受數分鐘以內的資料丟失， 那麼你可以只使用 RDB 持久化。

有很多使用者都只使用 AOF 持久化， 但我們並不推薦這種方式： 因為定時生成 RDB 快照（snapshot）非常便於進行資料庫備份， 並且 RDB 恢復資料集的速度也要比 AOF 恢復的速度要快， 除此之外， 使用 RDB 還可以避免之前提到的 AOF 程式的 bug

效能與實踐

通過上面的分析，我們都知道RDB的快照、AOF的重寫都需要fork，這是一個重量級操作，會對Redis造成阻塞。因此為了不影響Redis主程序響應，我們需要儘可能降低阻塞。

1. 降低fork的頻率，比如可以手動來觸發RDB生成快照、與AOF重寫；

2. 控制Redis最大使用記憶體，防止fork耗時過長；

3. 升級硬體裝置，如更快的記憶體、ssd硬碟；

4. 結合業務特點搭建不同的redis服務：

   • 對資料永續性要求不高的業務，如資料庫的資料快取，搭建不需要持久化的redis服務
   • 對資料永續性和安全性要求高的，如將redis當資料庫使用或者訊息佇列，搭建需要持久化的redis服務

5. 搭建redis叢集，啟用主從模式。

總結

資料來源

文章材料摘抄自：

http://oldblog.antirez.com/post/redis-persistence-demystified.html

http://redisdoc.com/topic/persistence.html

http://redis.io/topics/persistence