1. 程式人生 > >【redis】redis之持久化機制

【redis】redis之持久化機制

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檢視:

[email protected]$ 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 提供了savebgsave這兩種不同的儲存方式,並且這兩個方式在執行的時候都會呼叫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
[email protected]$ 
複製程式碼

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

[email protected]$ 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
[email protected]$ 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"
複製程式碼

appendonlyappendfsyncappendfilename設定好並儲存。重新啟動 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> 
複製程式碼

可以看到,成功添加了 rngedgig 這三條記錄,然後開啟 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 異常關閉:

[email protected]$ kill -9 22645
複製程式碼

然後再重新啟動 Redis 服務:

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

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

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

可以看到,rngig都還在,意味著持久化是生效的。

怎樣從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 服務,密碼持久化即生效。

轉自:https://juejin.im/post/5bcab6f46fb9a05d3c802ea6