Redis持久化（五）

Redis持久化

Redis 爲了內部數據的安全考慮，會把自己的數據以文件的形式保存到硬盤中一份，在服務器重啓後會自動把硬盤的數據恢復到內存(Redis)裏面

Redis持久化分爲：

• RDB 持久化方式

• AOF 持久化方式

兩種持久化能夠同時開啓

RDB(Redis DataBase)持久化方式

RDB 持久化是指在指定的時間間隔內將內存中的數據快照寫入磁盤，實際操做過程是 fork 一個子進程，先將數據寫入臨時文件，寫入成功後，再替換以前的文件，用二進制壓縮存儲

Redis 將數據庫快照保存在名字爲 dump.rdb 的二進制文件中

RDB 持久化快照名稱與路徑(redis.conf 文件)：

RDB持久化備份頻率：

$ save 900 1       #900秒內若是超過1個key被修改，則發起快照保存 
$ save 300 10      #300秒內若是超過10個key被修改，則發起快照保存 
$ save 60 10000    #60秒內若是超過10000個key被修改，則發起快照保存

優勢：

1. 很是適合於備份，好比你能夠在每一個小時保存一下過去24小時內的數據，同時天天保存過去30天的數據，這樣即便出了問題你也能夠根據需求恢復到不一樣版本的數據

2. 很方便傳送到遠端數據中心，很是適用於災難恢復

3. RDB 在保存 RDB 文件時父進程惟一須要作的就是 fork 出一個子進程，接下來的工做所有由子進程來作，父進程不須要再作其餘 IO 操做，因此 RDB 持久化方式能夠最大化 Redis 的性能
   4.與 AOF 相比，在恢復大的數據的時候，RDB 效率更高

缺點：

1. 若是你想保證數據的高可用性，即最大限度的避免數據丟失，那麼 RDB 將不是一個很好的選擇。由於系統一旦在定時持久化以前出現宕機現象，你可能會丟失幾分鐘的數據

2. 因爲 RDB 是經過 fork子進程來協助完成數據持久化工做的，所以，若是當數據較大時，可能會致使整個服務器中止服務幾百毫秒，甚至是1秒鐘

手動發起RDB持久化方式：
輸入 save

或者 bgsave (bgsave 是開啓單獨線程)

AOF(Append Only File)持久化方式

AOF 持久化以日誌的形式記錄服務器所處理的每個寫、刪除操做，查詢操做，當服務器重啓的時候會從新執行這些命令來恢復原始的數據

開啓 AOF 持久化(redis.conf)

注：重啓 Redis 才生效

AOF 持久化名稱與路徑：

AOF 持久化備份頻率：

# 每次有新命令追加到 AOF 文件時就執行一次同步 ：很是慢，也很是安全
$ always 

# 每秒同步一次：足夠快（和使用 RDB 持久化差很少），而且在故障時只會丟失 1 秒鐘的數據
# 推薦（而且也是默認）的措施爲每秒同步一次， 這種策略能夠兼顧速度和安全性
$ everysec

# 從不一樣步：將數據交給操做系統來處理。更快，也更不安全的選擇
$ no

AOF 持久化備份優化:
由於 AOF 的運做方式是不斷地將命令追加到文件的末尾， 因此隨着寫入命令的不斷增長， AOF 文件的體積也會變得愈來愈大
例如， 若是你對一個計數器調用了 100 次 INCR ， 那麼僅僅是爲了保存這個計數器的當前值， AOF 文件就須要使用 100 條記錄（entry）。然而在實際上， 只使用一條 SET 命令已經足以保存計數器的當前值了， 其他 99 條記錄實際上都是多餘的

輸入 bgrewriteaof 命令優化 AOF 文件

AOF 文件損壞：
服務器可能在程序正在對 AOF 文件進行寫入時宕機， 宕機會形成了 AOF 文件出錯（corrupt）， 那麼 Redis 在重啓時會拒絕載入這個 AOF 文件， 從而確保數據的一致性不會被破壞。

修復出錯的 AOF 文件：

• 爲現有的 AOF 文件建立一個備份

• 使用 Redis 附帶的 redis-check-aof 程序，對原來的 AOF 文件進行修復：

  $ redis-check-aof –fix

• 使用 diff -u 對比修復後的 AOF 文件和原始 AOF 文件的備份，查看兩個文件之間的不一樣之處

• 重啓 Redis 服務器，等待服務器載入修復後的 AOF 文件，並進行數據恢復

優勢：

1. AOF 持久化能夠帶來更高的數據安全性。Redis 中提供了3種同步策略，即每秒同步、每修改同步和不一樣步。使用默認的每秒同步其效率也是很是高的(同步是由後臺線程進行處理的，主線程會盡力處理客戶端請求)，一旦出現故障，你最多丟失1秒的數據

2. AOF 文件是一個只進行追加的日誌文件，因此不須要寫入 seek，即便因爲某些緣由(磁盤空間已滿，寫的過程當中宕機等等)未執行完整的寫入命令，你也也可以使用 redis-check-aof 工具修復這些問題

3. Redis 能夠在 AOF 文件體積變得過大時，自動地在後臺對 AOF 進行重寫： 重寫後的新 AOF 文件包含了恢復當前數據所需的最小命令集合。 整個重寫操做是絕對安全的，由於 Redis 在建立新 AOF 文件的過程當中，會繼續將命令追加到現有的 AOF 文件裏面，即便重寫過程當中發生宕機，現有的 AOF 文件也不會丟失。 而一旦新 AOF 文件建立完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，並開始對新 AOF 文件進行追加操做

4. AOF 文件有序地保存了對數據庫執行的全部寫入操做， 這些寫入操做以 Redis 協議的格式保存， 所以 AOF 文件的內容很是容易被人讀懂， 對文件進行分析（parse）也很輕鬆。 導出（export） AOF 文件也很是簡單： 舉個例子， 若是你不當心執行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那麼只要中止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 並重啓 Redis ， 就能夠將數據集恢復到 FLUSHALL 執行以前的狀態

缺點：

1. 對於相同的數據來講，AOF 文件一般要大於 RDB 文件

2. 根據同步策略的不一樣，AOF 的運行效率可能會慢於 RDB 。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和 RDB 同樣高效。不過在處理巨大的寫入載入時，RDB 能夠提供更有保證的最大延遲時間（latency）

從RDB方式切換爲AOF方式

在 Redis 2.2 或以上版本，能夠在不重啓的狀況下，從 RDB 切換到 AOF ：

• 爲最新的 dump.rdb 文件建立一個備份

• 將備份放到一個安全的地方

• 執行如下兩條命令：

# 開啓 AOF 功能，Redis 會阻塞直到初始 AOF 文件建立完成爲止 
# 以後 Redis 會繼續處理命令請求， 並開始將寫入命令追加到 AOF 文件末尾
$ redis-cli config set appendonly yes
# 關閉 RDB 功能
$ redis-cli config set save

• 確保寫命令會被正確地追加到 AOF 文件的末尾
  注： 在redis.conf 中打開 AOF 功能，不然服務器重啓以後， 以前經過 CONFIG SET 設置的配置就會被遺忘， 程序會按原來的配置來啓動服務器。

總結：

• 若是你對數據安全性很是重視的話，你應該同時使用兩種持久化功能

• 若是你承受數分鐘之內的數據丟失，你能夠只使用 RDB 持久化

兩者選擇的標準，就是看是否願意犧牲一些性能，換取更高的緩存一致性（AOF），仍是願意寫操做頻繁的時候，不啓用備份來換取更高的性能，待手動運行 save 的時候，再作備份（RDB）。
注： 將來 Redis 可能會將 AOF 和 RDB 整合成單個持久化模型.

---

相關文檔：
英文：https://redis.io/topics/persi...
中文：http://www.redis.cn/topics/pe...

---

相關連接：
Linux下PHP安裝Redis擴展（二）
Redis主從配置（三）
Redis集羣搭建與簡單使用（四）