redis 持久化介紹及選擇

 

Redis 提供了不一樣級別的持久化方式:

RDB持久化方式可以在指定的時間間隔能對你的數據進行快照存儲。

AOF持久化方式記錄每次對服務器寫的操做，當服務器重啓的時候會從新執行這些命令來恢復原始的數據，AOF命令以redis協議追加保存每次寫的操做到文件末尾，Redis還能對AOF文件進行後臺重寫，使得AOF文件的體積不至於過大。

RDB的優勢：

RDB是一個很是緊湊的文件，它保存了某個時間點得數據集,很是適用於數據集的備份，好比你能夠在每一個小時報保存一下過去24小時內的數據，同時天天保存過去30天的數據,這樣即便出了問題你也能夠根據需求恢復到不一樣版本的數據集。

RDB是一個緊湊的單一文件，很方便傳送到另外一個遠端數據中心，很是適用於災難恢復。

RDB在保存RDB文件時父進程惟一須要作的就是fork出一個子進程，接下來的工做所有由子進程來作，父進程不須要再作其餘IO操做，因此RDB持久化方式能夠最大化redis的性能。

與AOF相比,在恢復大的數據集的時候，RDB方式會更快一些。

RDB的缺點

若是你但願在redis意外中止工做（例如電源中斷）的狀況下丟失的數據最少的話，那麼RDB不適合你。雖然你能夠配置不一樣的save時間點(例如每隔5分鐘而且對數據集有100個寫的操做)，是Redis要完整的保存整個數據集是一個比較繁重的工做，你一般會每隔5分鐘或者更久作一次完整的保存，萬一在Redis意外宕機,你可能會丟失幾分鐘的數據。

RDB 須要常常fork子進程來保存數據集到硬盤上，當數據集比較大的時候，fork的過程是很是耗時的，可能會致使Redis在一些毫秒級內不能響應客戶端的請求。若是數據集巨大而且CPU性能不是很好的狀況下,這種狀況會持續1秒，AOF也須要fork，可是你能夠調節重寫日誌文件的頻率來提升數據集的耐久度。

AOF 優勢

使用AOF 會讓你的Redis更加耐久， 你可使用不一樣的fsync策略，無fsync，每秒fsync，每次寫的時候fsync，使用默認的每秒fsync策略，Redis的性能依然很好(fsync是由後臺線程進行處理的,主線程會盡力處理客戶端請求)，一旦出現故障，你最多丟失1秒的數據。

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）。

RDB 配置實例：

save 900 1 #900秒內1個key改動
save 300 10  #300秒內10個key改動
save 60 1000  #60秒內1000個key改動

表示知足上面三個條件的任何一條會進行一次持久化操做

AOF 配置：

首先要開啓aof配置

# appendfsync always  #每次有新命令追加到 AOF 文件時就執行一次 fsync ：很是慢，也很是安全
appendfsync everysec  #每秒 fsync 一次：足夠快（和使用 RDB 持久化差很少），而且在故障時只會丟失 1 秒鐘的數據。
# appendfsync no  #從不 fsync ：將數據交給操做系統來處理。更快，也更不安全的選擇。

 推薦選擇第二種方式

使用選擇：

另外須要主要的是在生產服務器上開啓持久話，每次進行持久化時會對redis服務形成一些影響，rdb寫入和aof文件重寫時對服務的IO和cpu都有影響，

嚴重狀況下在持久化時可能會形成redis阻塞，建議使用redis集羣或主從同步，在生產服務上關閉持久化，在slave上開啓持久化。

若是必須開啓持久化，也要兼顧效率，建議使用aof，採用每秒fsync一次的方式