[動圖演示]Redis 持久化 RDB/AOF 詳解與實踐

摘要： Redis 是一個開源（ BSD 許可）的，記憶體中的資料結構儲存系統，它可以用作資料庫、快取和訊息中介軟體。它支援的資料型別很豐富，如字串、連結串列、集 合、以及雜湊等，並且還支援多種排序功能。 用一句話可以將持久化概括為：將資料（如記憶體中的物件）儲存到可永久儲存的儲存裝置中。持久化的...

Redis 是一個開源（ BSD 許可）的，記憶體中的資料結構儲存系統，它可以用作資料庫、快取和訊息中介軟體。它支援的資料型別很豐富，如字串、連結串列、集 合、以及雜湊等，並且還支援多種排序功能。

用一句話可以將持久化概括為：將資料（如記憶體中的物件）儲存到可永久儲存的儲存裝置中。持久化的主要應用是將記憶體中的物件儲存在資料庫中，或者儲存在磁碟檔案中、 XML 資料檔案中等等。

從應用層與系統層理解持久化

同時，也可以從應用層和系統層這兩個層面來理解持久化：

應用層：如果關閉( Close )你的應用然後重新啟動則先前的資料依然存在。

系統層：如果關閉( Shutdown )你的系統（電腦）然後重新啟動則先前的資料依然存在。

Redis 為什麼要持久化？

Redis 中的資料型別都支援 push/pop、add/remove 及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，Redis 支援各種不同方式的排序。與 Memcached 一樣，為了保證效率，資料都是快取在記憶體中。

對，資料都是快取在記憶體中的，當你重啟系統或者關閉系統後，快取在記憶體中的資料都會消失殆盡，再也找不回來了。所以，為了讓資料能夠長期儲存，就要將 Redis 放在快取中的資料做持久化儲存。

Redis 怎麼實現持久化？

在設計之初，Redis 就已經考慮到了這個問題。官方提供了多種不同級別的資料持久化的方式：

1、RDB持久化方式能夠在指定的時間間隔能對你的資料進行快照儲存。

2、AOF持久化方式記錄每次對伺服器寫的操作,當伺服器重啟的時候會重新執行這些命令來恢復原始的資料,AOF命令以redis協議追加儲存每次寫的操作到檔案末尾.Redis還能對AOF檔案進行後臺重寫,使得AOF檔案的體積不至於過大。

3、如果你只希望你的資料在伺服器執行的時候存在,你也可以不使用任何持久化方式。

4、你也可以同時開啟兩種持久化方式, 在這種情況下, 當redis重啟的時候會優先載入AOF檔案來恢復原始的資料,因為在通常情況下AOF檔案儲存的資料集要比RDB檔案儲存的資料集要完整。

如果你不知道該選擇哪一個級別的持久化方式，那我們就先來了解一下 AOF 方式和 RDB 方式有什麼樣的區別，並且它們各自有何優劣，學習完之後，再來考慮該選擇哪一種級別。

RDB 方式與 AOF 方式的優勢對比

首先我們來看一看官方對於兩種方式的優點描述，並做個對比，然後再看一看兩種方式的缺點描述。

RDB 方式的優點

• RDB 是一個非常緊湊的檔案,它儲存了某個時間點的資料集,非常適用於資料集的備份,比如你可以在每個小時報儲存一下過去24小時內的資料,同時每天儲存過去30天的資料,這樣即使出了問題你也可以根據需求恢復到不同版本的資料集。

• RDB 是一個緊湊的單一檔案,很方便傳送到另一個遠端資料中心，非常適用於災難恢復。

• RDB 在儲存 RDB 檔案時父程序唯一需要做的就是 fork 出一個子程序,接下來的工作全部由子程序來做，父程序不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化 Redis 的效能。

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

當 Redis 需要儲存 dump.rdb 檔案時， 伺服器執行以下操作:

• Redis 呼叫forks. 同時擁有父程序和子程序。
• 子程序將資料集寫入到一個臨時 RDB 檔案中。
• 當子程序完成對新 RDB 檔案的寫入時，Redis 用新 RDB 檔案替換原來的 RDB 檔案，並刪除舊的 RDB 檔案。

這種工作方式使得 Redis 可以從寫時複製（ copy-on-write ）機制中獲益。

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 執行之前的狀態。

優點對比總結

RDB 方式可以儲存過去一段時間內的資料，並且儲存結果是一個單一的檔案，可以將檔案備份到其他伺服器，並且在回覆大量資料的時候，RDB 方式的速度會比 AOF 方式的回覆速度要快。

AOF 方式預設每秒鐘備份1次，頻率很高，它的操作方式是以追加的方式記錄日誌而不是資料，並且它的重寫過程是按順序進行追加，所以它的檔案內容非常容易讀懂。可以在某些需要的時候開啟 AOF 檔案對其編輯，增加或刪除某些記錄，最後再執行恢復操作。

RDB 方式與 AOF 方式的缺點對比

RDB 方式的缺點

• 如果你希望在 Redis 意外停止工作（例如電源中斷）的情況下丟失的資料最少的話，那麼 RDB 不適合你.雖然你可以配置不同的 save 時間點(例如每隔 5 分鐘並且對資料集有 100 個寫的操作),是 Redis 要完整的儲存整個資料集是一個比較繁重的工作,你通常會每隔5分鐘或者更久做一次完整的儲存,萬一在 Redis 意外宕機,你可能會丟失幾分鐘的資料。

• RDB 需要經常 fork 子程序來儲存資料集到硬碟上,當資料集比較大的時候, fork 的過程是非常耗時的,可能會導致 Redis 在一些毫秒級內不能響應客戶端的請求。如果資料集巨大並且 CPU 效能不是很好的情況下,這種情況會持續1秒, AOF 也需要 fork ,但是你可以調節重寫日誌檔案的頻率來提高資料集的耐久度。

AOF 方式的缺點

• 對於相同的資料集來說，AOF 檔案的體積通常要大於 RDB 檔案的體積。

• 根據所使用的 fsync 策略，AOF 的速度可能會慢於 RDB 。 在一般情況下， 每秒 fsync 的效能依然非常高， 而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快， 即使在高負荷之下也是如此。 不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間（ latency ）。

缺點對比總結

RDB 由於備份頻率不高，所以在回覆資料的時候有可能丟失一小段時間的資料，而且在資料集比較大的時候有可能對毫秒級的請求產生影響。

AOF 的檔案提及比較大，而且由於儲存頻率很高，所以整體的速度會比 RDB 慢一些，但是效能依舊很高。

工作原理

AOF 重寫和 RDB 建立快照一樣，都巧妙地利用了寫時複製機制:

• Redis 執行 fork() ，現在同時擁有父程序和子程序。
• 子程序開始將新 AOF 檔案的內容寫入到臨時檔案。
• 對於所有新執行的寫入命令，父程序一邊將它們累積到一個記憶體快取中，一邊將這些改動追加到現有 AOF 檔案的末尾,這樣樣即使在重寫的中途發生停機，現有的 AOF 檔案也還是安全的。
• 當子程序完成重寫工作時，它給父程序傳送一個訊號，父程序在接收到訊號之後，將記憶體快取中的所有資料追加到新 AOF 檔案的末尾。
• 現在 Redis 原子地用新檔案替換舊檔案，之後所有命令都會直接追加到新 AOF 檔案的末尾。

付諸實踐，RDB 與 AOF 的實現

RDB 方式持久化的開啟與配置

Redis 預設的持久化方式是 RDB ，並且預設是開啟的。RDB 的儲存有方式分為主動儲存與被動儲存。主動儲存可以在 redis-cli 中輸入 save 即可；被動儲存需要滿足配置檔案中設定的觸發條件，目前官方預設的觸發條件可以在 redis.conf 中看到：

save 900 1
save 300 10
save 60 10000
複製程式碼

其含義為：

伺服器在900秒之內，對資料庫進行了至少1次修改
伺服器在300秒之內，對資料庫進行了至少10次修改。
伺服器在60秒之內，對資料庫進行了至少10000次修改。
複製程式碼

滿足觸發條件後，資料就會被儲存為快照，正是因為這樣才說 RDB 的資料完整性是比不上 AOF 的。

觸發儲存條件後，會在指定的目錄生成一個名為 dump.rdb 的檔案，等到下一次啟動 Redis 時，Redis 會去讀取該目錄下的 dump.rdb 檔案，將裡面的資料恢復到 Redis。

這個目錄在哪裡呢？

我們可以在客戶端中輸入命令 config get dir 檢視：

gannicus@$ src/redis-cli
127.0.0.1:6379> config get dir
1) "dir"
2) "/home/gannicus/Documents/redis-5.0.0"
127.0.0.1:6379> 
複製程式碼

返回結果中的 "/home/gannicus/Documents/redis-5.0.0" 就是存放 dump.rdb 的目錄。

Redis 版本說明

在測試之前，說明一下前提。 redis 是直接從官網下載的壓縮包，解壓後得到的 redis-x.x.x 資料夾，比如我的是 redis-5.0.0 ，然後進入資料夾，在 redis-5.0.0 專案根目錄使用 make 命令安裝。

RDB 被動觸發儲存測試

剛才提到它分為主動儲存與被動觸發，現在我們來測試一下被動觸發。首先啟動 redis-server ，然後再開啟客戶端 redis-cli ，先增添幾條記錄：

127.0.0.1:6379> set lca 1
OK
127.0.0.1:6379> set lcb 1
OK
127.0.0.1:6379> set lcc 1
OK
127.0.0.1:6379> set lcd 1
OK
127.0.0.1:6379> set lce 1
OK
127.0.0.1:6379> set lcf 1
OK
127.0.0.1:6379> set lcg 1
OK
127.0.0.1:6379> set lch 1
OK
127.0.0.1:6379> set lci 1
OK
127.0.0.1:6379> set lcj 1
OK
127.0.0.1:6379> set lck 1
OK
127.0.0.1:6379> set lcl 1
OK
127.0.0.1:6379> set lcm 1
OK
複製程式碼

可以看到，總共添加了 13 條記錄：

127.0.0.1:6379> keys *
 1) "lca"
 2) "lcd"
 3) "lcg"
 4) "lce"
 5) "lcb"
 6) "lcm"
 7) "lcf"
 8) "lci"
 9) "lcl"
10) "lcc"
11) "lck"
12) "lcj"
13) "lch"
127.0.0.1:6379> 
複製程式碼

然後發現 redis-server 端的日誌視窗中出現瞭如下的提示：

21971:M 21 Oct 2018 16:52:44.062 * 10 changes in 300 seconds. Saving...
21971:M 21 Oct 2018 16:52:44.063 * Background saving started by pid 22552
22552:C 21 Oct 2018 16:52:44.066 * DB saved on disk
21971:M 21 Oct 2018 16:52:44.165 * Background saving terminated with success
複製程式碼

從英文提示中可以大概讀懂這些內容，它檢測到 300 秒內有 10 條記錄被改動，剛才我們添加了 13 條資料記錄，滿足 redis.conf 中對於 RDB 資料儲存的條件，所以這裡執行資料儲存操作，並且提示開闢了一個 22552 的程序出來執行儲存操作，最後提示儲存成功。

並且在目錄內看到有 dump.rdb 檔案生成。

現在將redis程序kill，哪些資料會被儲存？

通過命令 kill -9 pid （ pid 是程序編號）模擬 Redis 異常關閉，然後再啟動 Redis ，我們來看一看，到底是隻儲存了 10 條記錄還是 13 條全都儲存下來了？

127.0.0.1:6379> keys *
 1) "lcb"
 2) "lcj"
 3) "lcd"
 4) "lch"
 5) "lci"
 6) "lcc"
 7) "lcf"
 8) "lce"
 9) "lca"
10) "lcg"
127.0.0.1:6379> 
複製程式碼

重啟後檢視記錄，發現 13 條記錄中只有 10 條記錄會被儲存，這也印證了之前所說，RDB 方式的資料完整性是不可靠的，除非斷掉的那一刻正好是滿足觸發條件的條數。

關閉 RDB

剛才提到了，它是預設啟用的，如果你不需要它可以在配置檔案中將這 3 個配置註釋掉，並新增 save "" 即可：

save ""
# save 900 1
# save 300 10
# save 60 10000
複製程式碼

儲存配置檔案後需要重新啟動 Redis 服務才會生效，然後繼續新增十幾條記錄：

127.0.0.1:6379> keys *
 1) "lcb"
...
23) "lca"
24) "lcg"
127.0.0.1:6379> 
複製程式碼

在之前已有 10 條的基礎上我再增加了 14 條記錄，這次同樣要通過 kill 來模擬 Redis 異常關閉，再啟動服務看一看，資料是否還被儲存：

127.0.0.1:6379> keys *
 1) "lcb"
 2) "lcj"
 3) "lcd"
 4) "lch"
 5) "lci"
 6) "lcc"
 7) "lcf"
 8) "lce"
 9) "lca"
10) "lcg"
127.0.0.1:6379> 
複製程式碼

發現後面新增的 14 條記錄並沒有被儲存，恢復資料的時候僅僅只是恢復了之前的 10 條。並且觀察 Redis 服務端視窗日誌，並未發現像之前一樣的觸發儲存的提示，證明 RDB 方式已經被關閉。

RDB 主動儲存測試

通過配置檔案關閉被動觸發，那麼主動關閉是否還會生效呢？

在 Redis 客戶端（ redis-cli ）通過 del 命令刪除幾條記錄，然後輸入 save 命令執行儲存操作：

127.0.0.1:6379> keys *
 1) "lcc"
 2) "lch"
 3) "lcb"
 4) "lci"
 5) "lce"
 6) "lcj"
 7) "lcg"
 8) "lca"
 9) "lcd"
10) "lcf"
127.0.0.1:6379> del lca lcb lcc
(integer) 3
127.0.0.1:6379> save
OK
127.0.0.1:6379> 
複製程式碼

可以看到 redis-server 的日誌有新的提示： 22598:M 21 Oct 2018 17:22:31.365 * DB saved on disk ，它告訴我們資料已經儲存。

那麼繼續模擬異常關閉，再開啟服務，看一看是否真的儲存了這些操作：

127.0.0.1:6379> keys *
1) "lci"
2) "lcj"
3) "lcd"
4) "lcg"
5) "lcf"
6) "lce"
7) "lch"
127.0.0.1:6379> 
複製程式碼

果不其然，這幾個刪除操作都被儲存了下來，恢復過來的資料中已經沒有那 3 條記錄了，證明主動關閉不受 配置檔案的影響。

除了 save 還有其他的儲存方式麼？

save 和 bgsave 儲存

有的，Redis 提供了 save 和 bgsave 這兩種不同的儲存方式,並且這兩個方式在執行的時候都會呼叫 rdbSave 函式，但它們呼叫的方式各有不同：

• save 直接呼叫 rdbSave 方法 ，阻塞 Redis 主程序，直到儲存完成為止。在主程序阻塞期間，伺服器不能處理客戶端的任何請求。

• bgsave 則 fork 出一個子程序，子程序負責呼叫 rdbSave ，並在儲存完成之後向主程序傳送訊號，通知儲存已完成。因為 rdbSave 在子程序被呼叫，所以 Redis 伺服器在 bgsave 執行期間仍然可以繼續處理客戶端的請求。

save 是同步操作， bgsave 是非同步操作。

bgsave 命令的使用方法和 save 命令的使用方法是一樣的：

127.0.0.1:6379> keys *
1) "lci"
2) "lcj"
3) "lcd"
4) "lcg"
5) "lcf"
6) "lce"
7) "lch"
127.0.0.1:6379> del lci lcj 
(integer) 2
127.0.0.1:6379> bgsave
Background saving started
127.0.0.1:6379> keys *
1) "lcd"
2) "lcg"
3) "lcf"
4) "lce"
5) "lch"
127.0.0.1:6379> 
複製程式碼

shutdown 儲存

事實上， shutdown 命令也是可以儲存資料的，驚不驚喜。它會在關閉前將資料儲存下來，意不意外?

127.0.0.1:6379> set app 1
OK
127.0.0.1:6379> set apps 1
OK
127.0.0.1:6379> keys *
1) "apps"
2) "lcd"
3) "lcg"
4) "lcf"
5) "app"
6) "lce"
7) "lch"
127.0.0.1:6379> shutdown
not connected> quit
gannicus@$ 
複製程式碼

然後 Redis 服務就被關閉掉了。我們需要重新啟動 Redis 服務，到客戶端中看一看是否生效：

gannicus@$ src/redis-cli
127.0.0.1:6379> keys *
1) "lce"
2) "lcf"
3) "lcd"
4) "lch"
5) "lcg"
複製程式碼

竟然沒有生效，刺不刺激？這是為什麼呢？明明官方文件之shutdown就說會儲存了才退出的，你騙人~

注意到，文件中有一句

恍然大悟，原來是要在持久化被開啟的情況下，通過 shutdown 命令關閉才不會丟失資料，那麼就到配置檔案中將那幾個 save 的配置項開啟吧：

#save ""
save 900 1
save 300 10
save 60 10000
複製程式碼

然後再開啟 Redis 服務，再嘗試一遍（過程為：新增 -> shutdown -> 重啟服務 -> 檢視）：

127.0.0.1:6379> set app 1
OK
127.0.0.1:6379> set apps 1
OK
127.0.0.1:6379> shutdown
not connected> quit
gannicus@$ src/redis-cli
127.0.0.1:6379> keys *
1) "lce"
2) "lch"
3) "app"
4) "lcf"
5) "apps"
6) "lcd"
7) "lcg"
127.0.0.1:6379> 
複製程式碼

這下終於弄明白了。

AOF 方式持久化的開啟與配置

開啟 AOF

預設是不開啟 AOF 的，如果想要啟用則需要到 redis.conf 配置檔案中開啟，開啟 redis.conf :

$ vim redis.conf
複製程式碼

然後在檔案中找到 appendonly 並將 no 改為 yes ：

appendonly yes
複製程式碼

即為開啟了 AOF 方式的持久化。

設定同步方式

AOF 還有支援幾種同步方式，它們分別是：

appendfsync always# 每次有資料修改發生時都會寫入AOF檔案（安全但是費時）。
appendfsync everysec# 每秒鐘同步一次，該策略為AOF的預設策略。
appendfsync no# 從不同步。高效但是資料不會被持久化。
複製程式碼

預設配置是 everysec ，你可以根據需求進行調整，這裡我將配置改成 always ：

appendfsync always
# appendfsync everysec
# appendfsync no
複製程式碼

自定義 AOF 記錄檔案的檔名

Redis 設定有預設的檔名，在配置中顯示為：

appendfilename "appendonly.aof"
複製程式碼

你可以讓其保持預設名字，也可以指定其他的檔名，比如：

appendfilename "RNGLetme.aof"
複製程式碼

將 appendonly 、 appendfsync 和 appendfilename

設定好並儲存。重新啟動 Redis 服務：

$./redis-server
複製程式碼

通過命令 ls 檢視本地檔案，可以看到新生成了一個名為 RNGLetme.aof 的檔案，可以使用:

$cat RNGLetme.aof
複製程式碼

來檢視裡面的內容，由於當前未進行資料的改動，所以是空白的。

然後開啟 Redis 的客戶端：

$./redis-cli
複製程式碼

並且新增幾條資料記錄：

127.0.0.1:6379> set rng lpl
OK
127.0.0.1:6379> set ig lpl
OK
127.0.0.1:6379> set edg lpl
OK
127.0.0.1:6379> keys *
1) "edg"
2) "rng"
3) "ig"
127.0.0.1:6379> 
複製程式碼

可以看到，成功添加了 rng 、 edg 、 ig 這三條記錄，然後開啟 RNGLetme.aof 檔案，看看裡面的記錄：

*2
$6
SELECT
$1
0
*3
$3
set
$3
rng
$3
lpl
*3
$3
set
$2
ig
$3
lpl
*3
$3
set
$3
edg
$3
lpl
複製程式碼

每一次的資料新增都被記錄下來了。

那如果是刪除操作呢，也會被記錄下來麼？

127.0.0.1:6379> del edg
(integer) 1
127.0.0.1:6379> keys *
1) "rng"
2) "ig"
127.0.0.1:6379> 
複製程式碼

執行完刪除操作後，再看一看 RNGLetme.aof 檔案中的記錄：

*2
$6
SELECT
$1
0
*3
$3
set
$3
rng
$3
lpl
*3
$3
set
$2
ig
$3
lpl
*3
$3
set
$3
edg
$3
lpl
*2
$3
del
$3
edg
複製程式碼

對比之前的記錄，新增了 del edg

的操作記錄。這就印證了之前對 AOF 的描述：以日誌的方式將資料變動記錄下來。

AOF 恢復測試

下面同樣是通過 kill 命令模擬 Redis 異常關閉：

gannicus@$ kill -9 22645
複製程式碼

然後再重新啟動 Redis 服務：

$ src/redis-server redis.conf
複製程式碼

接著通過客戶端看一看，那些資料是否都在：

$ src/redis-cli
127.0.0.1:6379> keys *
1) "ig"
2) "rng"
複製程式碼

可以看到， rng 和 ig

都還在，意味著持久化是生效的。

怎樣從RDB方式切換為AOF方式

在 Redis 2.2 或以上版本，可以在不重啟的情況下，從 RDB 切換到 AOF ：

為最新的 dump.rdb 檔案建立一個備份、將備份放到一個安全的地方。執行以下兩條命令:

redis-cli config set appendonly yes
redis-cli config set save “”
複製程式碼

確保寫命令會被正確地追加到 AOF 檔案的末尾。 執行的第一條命令開啟了 AOF 功能： Redis 會阻塞直到初始 AOF 檔案建立完成為止， 之後 Redis 會繼續處理命令請求， 並開始將寫入命令追加到 AOF 檔案末尾。

執行的第二條命令用於關閉 RDB 功能。 這一步是可選的， 如果你願意的話， 也可以同時使用 RDB 和 AOF 這兩種持久化功能。

重要：別忘了在 redis.conf 中開啟 AOF 功能！否則伺服器重啟後，之前通過 CONFIG SET 命令設定的配置就會被遺忘， 程式會按原來的配置來啟動伺服器。

優先選擇 RDB 還是 AOF 呢？

分析對比兩種方式並做了測試後，發現這是兩種不同風格的持久化方式，那麼應該如何選擇呢？

• 對於企業級的中大型應用，如果不想犧牲資料完整性但是又希望保持高效率，那麼你應該同時使用 RDB 和 AOF 兩種方式；
• 如果你不打算耗費精力在這個地方，只需要保證資料完整性，那麼優先考慮使用 AOF 方式；
• RDB 方式非常適合大規模的資料恢復，如果業務對資料完整性和一致性要求不高，RDB是很好的選擇。

備份redis資料的建議

確保你的資料有完整的備份，磁碟故障、節點失效等問題問題可能讓你的資料消失不見， 不進行備份是非常危險的。

Redis 對於資料備份是非常友好的， 因為你可以在伺服器執行的時候對 RDB 檔案進行復制： RDB 檔案一旦被建立， 就不會進行任何修改。 當伺服器要建立一個新的 RDB 檔案時， 它先將檔案的內容儲存在一個臨時檔案裡面， 當臨時檔案寫入完畢時， 程式才使用 rename(2) 原子地用臨時檔案替換原來的 RDB 檔案。

這也就是說，無論何時，複製 RDB 檔案都是絕對安全的。

• 建立一個定期任務（ cron job ）， 每小時將一個 RDB 檔案備份到一個資料夾， 並且每天將一個 RDB 檔案備份到另一個資料夾。

• 確保快照的備份都帶有相應的日期和時間資訊， 每次執行定期任務指令碼時， 使用 find 命令來刪除過期的快照： 比如說， 你可以保留最近 48 小時內的每小時快照， 還可以保留最近一兩個月的每日快照。

• 至少每天一次， 將 RDB 備份到你的資料中心之外， 或者至少是備份到你執行 Redis 伺服器的物理機器之外。

Redis 密碼持久化

在 Redis 中資料需要持久化，密碼也要持久化。在客戶端通過命令：

config set requirepass zxc9527
複製程式碼

可以為 Redis 設定值為 zxc9527 的密碼，但是當 Redis 關閉並重新啟動後，許可權驗證功能就會失效，再也不需要密碼。所以，密碼也需要在 redis.conf 中持久化。開啟 redis.conf 找到 requirepass 配置項，取消其註釋並在後面設定密碼：

requirepass zxc9527
複製程式碼

儲存後重啟 Redis 服務，密碼持久化即生效。