redis 持久化 AOF RDB

標籤：redis   aof   rdb   

Redis的AOF持久化策略是將發送到redis服務端的每一條命令都記錄下來，並且儲存到硬碟中的AOF檔案中，類似打記錄檔，來一條命令就記錄一條。

AOF設定

AOF檔案的位置和RDB檔案的位置相同，都是通過dir參數設定，預設的檔案名稱是appendonly.aof，可以通過appendfilename參數來修改。

AOF測試

當用戶端向伺服器發送一些redis命令時，Redis會將所執行的命令記錄到aof檔案中，如下所示：

650) this.width=650;" src="http://img.blog.csdn.net/20160630175152955" alt="這裡寫圖片描述" title="" style="border:none;" />

當redis伺服器重啟後，會將執行該aof檔案，達到資料恢複的目的。

AOF檔案重寫

為什麼要重寫？重寫可以去除資料的中間執行過程，直接保留最終資料命令。

舉個栗子：比如在redis用戶端對key執行了一系列命令

set count 1 //初始值為1 
incr count // 加1 
incr count //加1 
decr count //減1

這個時候結果為

get count 
“2”

如果不進行AOF重寫的話，進行AOF檔案恢複的時候，Redis會執行AOF檔案中的每一條命令,並最終得到 count 為2 。

進行AOF重寫後，相當於把中間的計算過程略去。直接把計算得到的結果設定進redis，相當於僅執行了一條命令 set count 2。

可以使用BGREWRITEAOF命令來重寫AOF檔案。

重寫策略

重寫策略的參數設定：

auto-aof-rewrite-percentage 100

當前的AOF檔案大小超過上一次重寫時的AOF檔案大小的百分之多少時，會再次進行重寫，如果之前沒有重寫過，則以啟動時的AOF檔案大小為依據。

auto-aof-rewrite-min-size 64mb

限制了允許重寫的最小AOF檔案大小，通常在AOF檔案很小的時候，即使其中有些冗餘的命令也是可以忽略的。

Redis優秀的效能是由於其將所有的資料都儲存在記憶體中，同樣memcached也是這樣做的，但是為什麼redis能夠脫穎而出呢，很大程度上是因為Redis有出色的持久化機制，能夠保證伺服器重啟後，資料不會丟失。下面來看看Redis是如何持久化的。

Redis支援兩種方式的持久化，一種是RDB方式，一種是AOF方式。這兩種方式可以單獨使用其中一種，或者混合使用。 

RDB方式介紹

RDB方式是通過快照完成的，當符合一定條件時Redis會自動將記憶體中的所有資料進行快照，並且儲存到硬碟上。就像拍照一樣，將這一瞬間的所有東西都儲存下來。進行快照的條件在設定檔中指定。主要有兩個參數構成：時間和改動的索引值的個數，即當在指定時間內被更改的鍵的個數大於執行數值時，就會進行快照。RDB是Redis的預設持久化方式。 

RDB方式配置

找到Redis的設定檔：redis.conf

1） 設定觸發條件：

650) this.width=650;" src="http://img.blog.csdn.net/20160630161447993" alt="這裡寫圖片描述" title="" style="border:none;" /> 

650) this.width=650;" src="http://img.blog.csdn.net/20160630161530791" alt="這裡寫圖片描述" title="" style="border:none;" />

2) 設定rdb檔案路徑

預設rdb檔案存放路徑是目前的目錄，檔案名稱是：dump.rdb。可以在設定檔中修改路徑和檔案名稱，分別是dir和dbfilename

650) this.width=650;" src="http://img.blog.csdn.net/20160630161844807" alt="這裡寫圖片描述" title="" style="border:none;" />

Redis啟動後會讀取RDB快照檔案，將資料從硬碟載入到記憶體，一般情況下1GB的快照檔案載入到記憶體的時間大約20-30分鐘。

RDB如何進行快照

RDB的快照過程：

1） Redis使用fork函數複製一份當前進程（父進程）的副本；

2） 父進程繼續接受並處理用戶端發來的命令，而子進程開始將記憶體中的資料寫入到硬碟中的臨時檔案；

3） 當子進程寫入完成所有資料後會用該臨時檔案替換舊的RDB檔案。

手動快照：

如果沒有觸發自動快照，可以對redis進行手動快照操作，SAVE和BGSAVE都可以執行手動快照，兩個命令的區別是前者是由主進程進行快照操作，會阻塞其他請求；而後者是通過fork子進程進行快照操作。

注意：

由於redis使用fork來複製一份當前進程，那麼子進程就會佔有和主進程一樣的記憶體資源，比如說主進程8G記憶體，那麼在備份的時候必須保證有16G記憶體，要不然會啟用虛擬記憶體，效能非常差。

RDB檔案的壓縮

RDB檔案過大時，是可以壓縮的，Redis預設開啟壓縮，當然也可以通過配置rdbcompression參數來禁用壓縮。

650) this.width=650;" src="http://img.blog.csdn.net/20160630173614310" alt="這裡寫圖片描述" title="" style="border:none;" />

壓縮和不壓縮的優缺點：

壓縮：

優點：減少磁碟儲存空間
缺點：消耗CPU資源

不壓縮：

優點：不消耗CPU資源
缺點：佔用磁碟空間多

RDB 優點
RDB 是一種表示某個即時點的 Redis 資料的緊湊檔案。RDB 檔案適合用於備份。例如，你可能想要每小時歸檔最近 24 小時的 RDB 檔案，每天儲存近 30 天的 RDB 快照集。這允許你很容易的恢複不同版本的資料集以容災。
RDB 非常適合於災難恢複，作為一個緊湊的單一檔案，可以被傳輸到遠端資料中心，或者是 Amazon S3(可能得加密)。
RDB 最大化了 Redis 的效能，因為 Redis 父進程持久化時唯一需要做的是啟動(fork)一個子進程，由子進程完成所有剩餘工作。父進程執行個體不需要執行像磁碟 IO 這樣的操作。
RDB 在重啟儲存了大資料集的執行個體時比 AOF 要快。
RDB 缺點
當你需要在 Redis 停止工作(例如停電)時最小化資料丟失，RDB 可能不太好。你可以配置不同的儲存點。然而，你通常每隔 5 分鐘或更久建立一個 RDB 快照集，所以一旦 Redis 因為任何原因沒有正確關閉而停止工作，你就得做好最近幾分鐘資料丟失的準備了。
RDB 需要經常調用 fork()子進程來持久化到磁碟。如果資料集很大的話，fork()比較耗時，結果就是，當資料集非常大並且 CPU 效能不夠強大的話，Redis 會停止服務用戶端幾毫秒甚至一秒。AOF 也需要 fork()，但是你可以調整多久頻率重寫日誌而不會有損(trade-off)持久性(durability)。
AOF 優點
使用 AOF Redis 會更具有可持久性(durable)：你可以有很多不同的 fsync 策略：沒有 fsync，每秒 fsync，每次請求時 fsync。使用預設的每秒 fsync 策略，寫效能也仍然很不錯(fsync 是由後台線程完成的，主線程繼續努力地執行寫請求)，即便你也就僅僅只損失一秒鐘的寫資料。
AOF 日誌是一個追加檔案，所以不需要定位，在斷電時也沒有損壞問題。即使由於某種原因檔案末尾是一個寫到一半的命令(磁碟滿或者其他原因),redis-check-aof 工具也可以很輕易的修複。
AOF 檔案裡麵包含一個接一個的操作，以易於理解和解析的格式儲存。你也可以輕易的匯出一個 AOF 檔案。例如，即使你不小心錯誤地使用 FLUSHALL 命令清空一切，如果此時並沒有執行重寫，你仍然可以儲存你的資料集，你只要停止伺服器，刪除最後一條命令，然後重啟 Redis 就可以。
AOF 缺點
對同樣的資料集，AOF 檔案通常要大於等價的 RDB 檔案。
AOF 可能比 RDB 慢，這取決於準確的 fsync 策略。通常 fsync 設定為每秒一次的話效能仍然很高，如果關閉 fsync，即使在很高的負載下也和 RDB 一樣的快。不過，即使在很大的寫負載情況下，RDB 還是能提供能好的最大延遲保證。

RDB和AOF如何取捨
通常來說，你應該同時使用這兩種持久化方法，以達到和 PostgreSQL 提供的一樣的資料安全程度。
如果你很關注你的資料，但是仍然可以接受災難時有幾分鐘的資料丟失，你可以只單獨使用 RDB。
有很多使用者單獨使用 AOF，但是我們並不鼓勵這樣，因為時常進行 RDB 快照集非常方便於Database Backup，啟動速度也較之快，還避免了 AOF 引擎的 bug。

如何選擇？ 那就需要看需求、看伺服器資源情況了。

本文出自 “夢想照進現實” 部落格，請務必保留此出處http://lookingdream.blog.51cto.com/5177800/1941715

redis 持久化 AOF RDB