深入理解Redis兩種持久化方式有助於你備份

Redis是一個開源，高級的鍵值存儲和一個適用的解決方案，用於構建高性能，可擴展的Web應用程序，使用到生產中做數據庫緩存。它有兩種持久化方式，我們一起來了解一下。

一：RDB

在RDB方式下，你有兩種選擇：

（1）手動執行持久化數據命令來讓redis進行一次數據快照，

（2）根據你配置的配置文件的策略，達到策略的某些條件時來自動持久化數據。

手動執行持久化命令，依然有兩種選擇，那就是save命令和bgsave命令。

save操作在Redis主線程中工作，因此會阻塞其他請求操作，對於業務量打的redis來說應該避免使用。.rdb文件持久化存放位置可以從配置文件中找出，名稱也可以通過dbfilename參數來指定。

默認下，持久化到dump.rdb文件，並且在redis重啟後，自動讀取其中文件，據悉，通常情況下一千萬的字符串類型鍵，1GB的快照文件，同步到內存中的 時間是20-30秒。

bgSave操作則是調用Fork,產生子進程，父進程繼續處理請求。子進程將數據寫入臨時文件，並在寫完後，替換原有的.rdb文件。Fork發生時，父子進程內存共享，所以為了不影響子進程做數據快照，在這期間修改的數據，將會被複制一份，而不進共享內存。所以說，RDB所持久化的數據，是Fork發生時的數據。在這樣的條件下進行持久化數據，必須是手動操作，如果因為某些情況宕機，則會丟失一段時間的數據。

如果你的實際情況對數據丟失沒那麼敏感，丟失的也可以從傳統數據庫中獲取或者說丟失部分也無所謂，那麼選擇RDB持久化方式非常不錯。

再談一下配置文件的策略，實際上它和bgsave命令持久化原理是相同的，所謂配置文件策略，當然是在配置文件中設置save的時間。

這是配置文件默認的策略，他們之間的關係是或，每隔900秒，在這期間變化了至少一個鍵值，做快照。或者每三百秒，變化了十個鍵值做快照。或者每六十秒，變化了至少一萬個鍵值，做快照。

二：AOF

aof 比快照方式有更好的持久化性，是由於在使用aof持久化方式時，redis會將每一個收到的寫命令都會追加到文件中。默認名稱是 appendonly.aof，也可以通過參數appendfilename來指定。

當redis重啟時會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。當然由於os會在內核中緩存 write做的修改，所以可能不是立即寫到磁盤上。這樣aof方式的持久化也還是有可能會丟失部分修改。不過我們可以通過配置文件告訴redis我們寫入到磁盤或AOF文件刷新的時機。有三種方式如下（默認是：每秒一次）

appendonly yes //啟用aof持久化方式，默認是no

# appendfsync always //每次收到寫命令就立即強制寫入磁盤，最慢的，但是保證完全的持久化，不推薦使用

appendfsync everysec //每秒鐘強制寫入磁盤一次，在性能和持久化方面做了很好的折中，推薦

# appendfsync no //完全依賴os，性能最好,持久化沒保證

如果由於系統原因導致了AOF損壞，redis無法再加載這個AOF，可以按照下面步驟來修復：首先做一個AOF文件的備份，複製到其他地方；修復原始AOF文件，執行：redis-check-aof --fix ;可以通過diff –u命令來查看修復前後文件不一致的地方；重啟redis服務之後會重新讀取aof文件。

aof 的方式也同時帶來了另一個問題。持久化文件會變的越來越大。例如我們插入key100次，文件中必須保存全部的100條命令，其實有99條都是多餘的。因為要恢復數據庫的狀態其實文件中保存一條set test 100就夠了。為了壓縮aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis將使用與快照類似的方式將內存中的數據 以命令的方式保存到臨時文件中，最後替換原來的文件。具體過程如下

1. redis調用fork ，會有父子兩個進程

2. 子進程根據內存中的數據庫快照，往臨時文件中寫入重建數據庫狀態的命令

3.父進程繼續處理client請求，除了把寫命令寫入到原來的aof文件中。同時把收到的寫命令緩存起來。這樣就能保證如果子進程重寫失敗的話並不會出問題。

4.當子進程把快照內容寫入已命令方式寫到臨時文件中後，子進程發信號通知父進程。然後父進程把緩存的寫命令也寫入到臨時文件。

5.現在父進程可以使用臨時文件替換老的aof文件，並重命名，後面收到的寫命令也開始往新的aof文件中追加。

需要注意到是重寫aof文件的操作，並沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件,這點和快照有點類似。觸發機制：Redis會記錄上次重寫時的AOF文件大小，默認配置時當AOF文件大小是上次rewrite後大小的一倍且文件大於64M時觸發

三：RDB與AOF的選擇：

　　做備份：當數據量大，且對恢復速度有要求，並且數據的一致性要求不高的話，可以只使用RDB

　　只做緩存：不用開啟任何的持久化方式

　　兩者都開啟的建議：RDB數據不實時，同時使用兩者時服務器只會找AOF文件，可不可以只使用AOF?作者建議不要，因為RDB更適合備份數據庫(AOF在不斷變化，不好備份)

快速重啟，而且不會又AOF可能潛在的BUG,留作萬一的手段。

我們現在只有單機，只是每天備份一下RDB，官方給的建議是每小時備份RDB文件，看你的策略了，並且會用腳本將相應的備份文件推送到備份服務器。

當redis服務器掛掉時，重啟時將按照以下優先級恢復數據到內存：

• 如果只配置AOF,重啟時加載AOF文件恢復數據；

• 如果同時 配置了RBD和AOF,啟動是隻加載AOF文件恢復數據;

• 如果只配置RBD,啟動是加載dump文件恢復數據。

恢復時需要注意，如果做了主從，要是主庫掛了不能直接重啟主庫，否則會直接覆蓋掉從庫的AOF文件，一定要確保要恢復的文件都正確才能啟動，否則會沖掉原來的文件。

四：小結：

Redis提供幾種持久化機制：

1、RDB（默認）

工作方式：根據上述配置文件中save參數指定的時間間隔和Key變化數量觸發快照（dump）到dump.rdb文件。

優勢 ：備份恢復簡單。RDB通過子進程完成快照工作，相對比AOF啟動效率高。

劣勢 ：服務器故障會丟失幾分鐘內的數據。

2、AOF

工作方式 ：所有更新操作以日誌的形式記錄到AOF日誌文件，在redis服務重新啟動時會讀取該日誌文件來重新構建數據庫，以保證啟動後數據完整性。

優勢 ：AOF提供兩種同步機制，一個是fsync always每次有數據變化就同步到日誌文件和fsync everysec每秒同步一次到日誌文件，最大限度保證數據完整性。

劣勢：日誌文件相對RDB快照文件要大的多。

AOF日誌重寫功能 ：AOF日誌文件過大，redis會自動重寫AOF日誌，append模式不斷的將更新記錄寫入到老日誌文件中，同時redis還會創建一個新的日誌文件用於追加後續的記錄。

3、同時應用RDB和AOF

對於數據安全性高的場景，可同時使用AOF和RDB，但是會降低性能。

4、無持久化

在不要求數據持久化的業務場景，應關閉持久化，這樣會提高很大性能。

關閉方式：在配置文件設置

appendonly no

save “”

5、不重啟redis服務從RDB切換到AOF方式

redis-cli> CONFIGSET appendonly yes #啟用AOF

redis-cli> CONFIGSET save "" #關閉RDB

5、AOF日誌文件出錯後，修復方法

redis-check-aof --fix appendonly.aof #--fix參數為修復日誌文件，不加則對日誌檢查。