Redis的AOF持久化策略是將發送到redis服務端的每一條命令都記錄下來，並且保存到硬盤中的AOF文件中，類似打日誌文件，來一條命令就記錄一條。

AOF設置

AOF文件的位置和RDB文件的位置相同，都是通過dir參數設置，默認的文件名是appendonly.aof，可以通過appendfilename參數來修改。

AOF測試

當客戶端向服務器發送一些redis命令時，Redis會將所執行的命令記錄到aof文件中，如下所示：

當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） 設置觸發條件：

2) 設置rdb文件路徑

默認rdb文件存放路徑是當前目錄，文件名是：dump.rdb。可以在配置文件中修改路徑和文件名，分別是dir和dbfilename

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參數來禁用壓縮。

壓縮和不壓縮的優缺點：

壓縮：

優點：減少磁盤存儲空間
缺點：消耗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 快照非常方便於數據庫備份，啟動速度也較之快，還避免了 AOF 引擎的 bug。

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

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

redis 持久化 AOF RDB