它支持的數(shù)據(jù)類型很豐富，如字符串、鏈表、集合、以及散列等，并且還支持多種排序功能。

什么叫持久化?

用一句話可以將持久化概括為：將數(shù)據(jù)(如內(nèi)存中的對(duì)象)保存到可***保存的存儲(chǔ)設(shè)備中。

持久化的主要應(yīng)用是將內(nèi)存中的對(duì)象存儲(chǔ)在數(shù)據(jù)庫(kù)中，或者存儲(chǔ)在磁盤(pán)文件中、 XML 數(shù)據(jù)文件中等等。

也可以從如下兩個(gè)層面來(lái)理解持久化：

• 應(yīng)用層：如果關(guān)閉( Close )你的應(yīng)用，然后重新啟動(dòng)則先前的數(shù)據(jù)依然存在。
• 系統(tǒng)層：如果關(guān)閉( Shut Down )你的系統(tǒng)(電腦)，然后重新啟動(dòng)則先前的數(shù)據(jù)依然存在。

Redis 為什么要持久化?

Redis 中的數(shù)據(jù)類型都支持 Push/Pop、Add/Remove 及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。

在此基礎(chǔ)上，Redis 支持各種不同方式的排序。與 Memcached 一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中。

因?yàn)閿?shù)據(jù)都是緩存在內(nèi)存中的，當(dāng)你重啟系統(tǒng)或者關(guān)閉系統(tǒng)后，緩存在內(nèi)存中的數(shù)據(jù)都會(huì)消失殆盡，再也找不回來(lái)了。

所以，為了讓數(shù)據(jù)能夠長(zhǎng)期保存，就要將 Redis 放在緩存中的數(shù)據(jù)做持久化存儲(chǔ)。

[[250652]]

 

Redis 怎么實(shí)現(xiàn)持久化?

在設(shè)計(jì)之初，Redis 就已經(jīng)考慮到了這個(gè)問(wèn)題。官方提供了多種不同級(jí)別的數(shù)據(jù)持久化的方式：

• RDB 持久化方式能夠在指定的時(shí)間間隔對(duì)你的數(shù)據(jù)進(jìn)行快照存儲(chǔ)。
• AOF 持久化方式記錄每次對(duì)服務(wù)器寫(xiě)的操作，當(dāng)服務(wù)器重啟的時(shí)候會(huì)重新執(zhí)行這些命令來(lái)恢復(fù)原始的數(shù)據(jù)，AOF 命令以 Redis 協(xié)議追加保存每次寫(xiě)的操作到文件末尾。

Redis 還能對(duì) AOF 文件進(jìn)行后臺(tái)重寫(xiě)，使得 AOF 文件的體積不至于過(guò)大。

• 如果你只希望你的數(shù)據(jù)在服務(wù)器運(yùn)行的時(shí)候存在，你也可以不使用任何持久化方式。
• 你也可以同時(shí)開(kāi)啟兩種持久化方式，在這種情況下，當(dāng) Redis 重啟的時(shí)候會(huì)優(yōu)先載入 AOF 文件來(lái)恢復(fù)原始的數(shù)據(jù)，因?yàn)樵谕ǔＧ闆r下 AOF 文件保存的數(shù)據(jù)集要比 RDB 文件保存的數(shù)據(jù)集要完整。

如果你不知道該選擇哪一個(gè)級(jí)別的持久化方式，那我們就先來(lái)了解一下 AOF 方式和 RDB 方式有什么樣的區(qū)別，并且它們各自有何優(yōu)劣，學(xué)習(xí)完之后，再來(lái)考慮該選擇哪一種級(jí)別。

RDB 方式與 AOF 方式的優(yōu)勢(shì)對(duì)比

RDB 方式與 AOF 方式的優(yōu)點(diǎn)對(duì)比

首先我們來(lái)看一看官方對(duì)于兩種方式的優(yōu)點(diǎn)描述，并做個(gè)對(duì)比，然后再看一看兩種方式的缺點(diǎn)描述。

 

RDB 方式的優(yōu)點(diǎn)：

• RDB 是一個(gè)非常緊湊的文件,它保存了某個(gè)時(shí)間點(diǎn)的數(shù)據(jù)集，非常適用于數(shù)據(jù)集的備份。
• 比如你可以在每個(gè)小時(shí)保存一下過(guò)去 24 小時(shí)內(nèi)的數(shù)據(jù)，同時(shí)每天保存過(guò)去 30 天的數(shù)據(jù)，這樣即使出了問(wèn)題你也可以根據(jù)需求恢復(fù)到不同版本的數(shù)據(jù)集。
• RDB 是一個(gè)緊湊的單一文件，很方便傳送到另一個(gè)遠(yuǎn)端數(shù)據(jù)中心，非常適用于災(zāi)難恢復(fù)。
• RDB 在保存 RDB 文件時(shí)父進(jìn)程唯一需要做的就是 Fork 出一個(gè)子進(jìn)程，接下來(lái)的工作全部由子進(jìn)程來(lái)做，父進(jìn)程不需要再做其他 IO 操作，所以 RDB 持久化方式可以***化 Redis 的性能。
• 與 AOF 相比，在恢復(fù)大的數(shù)據(jù)集的時(shí)候，RDB 方式會(huì)更快一些。

當(dāng) Redis 需要保存 dump.rdb 文件時(shí)， 服務(wù)器執(zhí)行以下操作：

• Redis 調(diào)用 Forks，同時(shí)擁有父進(jìn)程和子進(jìn)程。
• 子進(jìn)程將數(shù)據(jù)集寫(xiě)入到一個(gè)臨時(shí) RDB 文件中。
• 當(dāng)子進(jìn)程完成對(duì)新 RDB 文件的寫(xiě)入時(shí)，Redis 用新 RDB 文件替換原來(lái)的 RDB 文件，并刪除舊的 RDB 文件。

這種工作方式使得 Redis 可以從寫(xiě)時(shí)復(fù)制(copy-on-write)機(jī)制中獲益。

 

AOF 方式的優(yōu)點(diǎn)：

• 使用 AOF 會(huì)讓你的 Redis 更加耐久。
• 你可以使用不同的 Fsync 策略：無(wú) Fsync、每秒 Fsync 、每次寫(xiě)的時(shí)候 Fsync 使用默認(rèn)的每秒 Fsync 策略。

Redis 的性能依然很好( Fsync 是由后臺(tái)線程進(jìn)行處理的，主線程會(huì)盡力處理客戶端請(qǐng)求)，一旦出現(xiàn)故障，你最多丟失 1 秒的數(shù)據(jù)。

• AOF文件是一個(gè)只進(jìn)行追加的日志文件，所以不需要寫(xiě)入 Seek，即使由于某些原因(磁盤(pán)空間已滿，寫(xiě)的過(guò)程中宕機(jī)等等)未執(zhí)行完整的寫(xiě)入命令，你也可使用 redis-check-aof 工具修復(fù)這些問(wèn)題。
• Redis 可以在 AOF 文件體積變得過(guò)大時(shí)，自動(dòng)地在后臺(tái)對(duì) AOF 進(jìn)行重寫(xiě)： 重寫(xiě)后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。

整個(gè)重寫(xiě)操作是絕對(duì)安全的，因?yàn)?Redis 在創(chuàng)建新 AOF 文件的過(guò)程中，會(huì)繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫(xiě)過(guò)程中發(fā)生停機(jī)，現(xiàn)有的 AOF 文件也不會(huì)丟失。

而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會(huì)從舊 AOF 文件切換到新 AOF 文件，并開(kāi)始對(duì)新 AOF 文件進(jìn)行追加操作。

• AOF 文件有序地保存了對(duì)數(shù)據(jù)庫(kù)執(zhí)行的所有寫(xiě)入操作，這些寫(xiě)入操作以 Redis 協(xié)議的格式保存。

因此 AOF 文件的內(nèi)容非常容易被人讀懂， 對(duì)文件進(jìn)行分析(parse)也很輕松。導(dǎo)出(export) AOF 文件也非常簡(jiǎn)單。

舉個(gè)例子，如果你不小心執(zhí)行了 FLUSHALL 命令，但只要 AOF 文件未被重寫(xiě)，那么只要停止服務(wù)器， 移除 AOF 文件末尾的 FLUSHALL 命令，并重啟 Redis ，就可以將數(shù)據(jù)集恢復(fù)到 FLUSHALL 執(zhí)行之前的狀態(tài)。

優(yōu)點(diǎn)對(duì)比總結(jié)：

• RDB 方式可以保存過(guò)去一段時(shí)間內(nèi)的數(shù)據(jù)，并且保存結(jié)果是一個(gè)單一的文件，可以將文件備份到其他服務(wù)器，并且在回復(fù)大量數(shù)據(jù)的時(shí)候，RDB 方式的速度會(huì)比 AOF 方式的回復(fù)速度要快。
• AOF 方式默認(rèn)每秒鐘備份 1 次，頻率很高，它的操作方式是以追加的方式記錄日志而不是數(shù)據(jù)，并且它的重寫(xiě)過(guò)程是按順序進(jìn)行追加，所以它的文件內(nèi)容非常容易讀懂。

可以在某些需要的時(shí)候打開(kāi) AOF 文件對(duì)其編輯，增加或刪除某些記錄，***再執(zhí)行恢復(fù)操作。

RDB 方式與 AOF 方式的缺點(diǎn)對(duì)比

RDB 方式的缺點(diǎn)：

• 如果你希望在 Redis 意外停止工作(例如電源中斷)的情況下丟失的數(shù)據(jù)最少的話，那么 RDB 不適合你。

雖然你可以配置不同的 Save 時(shí)間點(diǎn)(例如每隔 5 分鐘并且對(duì)數(shù)據(jù)集有 100 個(gè)寫(xiě)的操作)，但是 Redis 要完整的保存整個(gè)數(shù)據(jù)集是一個(gè)比較繁重的工作。

你通常會(huì)每隔 5 分鐘或者更久做一次完整的保存，萬(wàn)一 Redis 意外宕機(jī)，你可能會(huì)丟失幾分鐘的數(shù)據(jù)。

• RDB 需要經(jīng)常 Fork 子進(jìn)程來(lái)保存數(shù)據(jù)集到硬盤(pán)上，當(dāng)數(shù)據(jù)集比較大的時(shí)，F(xiàn)ork 的過(guò)程是非常耗時(shí)的，可能會(huì)導(dǎo)致 Redis 在一些毫秒級(jí)內(nèi)不能響應(yīng)客戶端的請(qǐng)求。

如果數(shù)據(jù)集巨大并且 CPU 性能不是很好的情況下，這種情況會(huì)持續(xù) 1 秒，AOF 也需要 Fork，但是你可以調(diào)節(jié)重寫(xiě)日志文件的頻率來(lái)提高數(shù)據(jù)集的耐久度。

AOF 方式的缺點(diǎn)：

• 對(duì)于相同的數(shù)據(jù)集來(lái)說(shuō)，AOF 文件的體積通常要大于 RDB 文件的體積。
• 根據(jù)所使用的 Fsync 策略，AOF 的速度可能會(huì)慢于 RDB。在一般情況下，每秒 Fsync 的性能依然非常高，而關(guān)閉 Fsync 可以讓 AOF 的速度和 RDB 一樣快，即使在高負(fù)荷之下也是如此。

不過(guò)在處理巨大的寫(xiě)入載入時(shí)，RDB 可以提供更有保證的***延遲時(shí)間(Latency)。

缺點(diǎn)對(duì)比總結(jié)：

• RDB 由于備份頻率不高，所以在回復(fù)數(shù)據(jù)的時(shí)候有可能丟失一小段時(shí)間的數(shù)據(jù)，而且在數(shù)據(jù)集比較大的時(shí)候有可能對(duì)毫秒級(jí)的請(qǐng)求產(chǎn)生影響。
• AOF 的文件提及比較大，而且由于保存頻率很高，所以整體的速度會(huì)比 RDB 慢一些，但是性能依舊很高。

RDB 與 AOF 工作原理

 

 

 

 

AOF 重寫(xiě)和 RDB 創(chuàng)建快照一樣，都巧妙地利用了寫(xiě)時(shí)復(fù)制機(jī)制：

• Redis 執(zhí)行 fork() ，現(xiàn)在同時(shí)擁有父進(jìn)程和子進(jìn)程。
• 子進(jìn)程開(kāi)始將新 AOF 文件的內(nèi)容寫(xiě)入到臨時(shí)文件。
• 對(duì)于所有新執(zhí)行的寫(xiě)入命令，父進(jìn)程一邊將它們累積到一個(gè)內(nèi)存緩存中，一邊將這些改動(dòng)追加到現(xiàn)有 AOF 文件的末尾，這樣即使在重寫(xiě)的中途發(fā)生停機(jī)，現(xiàn)有的 AOF 文件也還是安全的。
• 當(dāng)子進(jìn)程完成重寫(xiě)工作時(shí)，它給父進(jìn)程發(fā)送一個(gè)信號(hào)，父進(jìn)程在接收到信號(hào)之后，將內(nèi)存緩存中的所有數(shù)據(jù)追加到新 AOF 文件的末尾。
• 現(xiàn)在 Redis 原子地用新文件替換舊文件，之后所有命令都會(huì)直接追加到新 AOF 文件的末尾。

付諸實(shí)踐，RDB 與 AOF 的實(shí)現(xiàn)

[[250655]]

 

RDB 方式持久化的開(kāi)啟與配置

Redis 默認(rèn)的持久化方式是 RDB ，并且默認(rèn)是打開(kāi)的。RDB 的保存方式分為主動(dòng)保存與被動(dòng)保存。

主動(dòng)保存可以在 redis-cli 中輸入 Save 即可;被動(dòng)保存需要滿足配置文件中設(shè)定的觸發(fā)條件，目前官方默認(rèn)的觸發(fā)條件可以在 redis.conf 中看到：

save 900 1save 300 10save 60 10000

其含義為：

服務(wù)器在900秒之內(nèi)，對(duì)數(shù)據(jù)庫(kù)進(jìn)行了至少1次修改。服務(wù)器在300秒之內(nèi)，對(duì)數(shù)據(jù)庫(kù)進(jìn)行了至少10次修改。服務(wù)器在60秒之內(nèi)，對(duì)數(shù)據(jù)庫(kù)進(jìn)行了至少10000次修改。

滿足觸發(fā)條件后，數(shù)據(jù)就會(huì)被保存為快照，正是因?yàn)檫@樣才說(shuō) RDB 的數(shù)據(jù)完整性是比不上 AOF 的。

觸發(fā)保存條件后，會(huì)在指定的目錄生成一個(gè)名為 dump.rdb 的文件，等到下一次啟動(dòng) Redis 時(shí)，Redis 會(huì)去讀取該目錄下的 dump.rdb 文件，將里面的數(shù)據(jù)恢復(fù)到 Redis。

這個(gè)目錄在哪里呢?我們可以在客戶端中輸入命令 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>  

 

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

在測(cè)試之前，說(shuō)明一下前提：Redis 是直接從官網(wǎng)下載的壓縮包，解壓后得到 redis-x.x.x 文件夾。

比如我的是 redis-5.0.0，然后進(jìn)入文件夾，在 redis-5.0.0 項(xiàng)目根目錄使用 make 命令安裝。

 

RDB 被動(dòng)觸發(fā)保存測(cè)試

剛才提到它分為主動(dòng)保存與被動(dòng)觸發(fā)，現(xiàn)在我們來(lái)測(cè)試一下被動(dòng)觸發(fā)。首先啟動(dòng) redis-server，然后再打開(kāi)客戶端 redis-cli ，先增添幾條記錄：

127.0.0.1:6379> set lca 1OK127.0.0.1:6379> set lcb 1OK127.0.0.1:6379> set lcc 1OK127.0.0.1:6379> set lcd 1OK127.0.0.1:6379> set lce 1OK127.0.0.1:6379> set lcf 1OK127.0.0.1:6379> set lcg 1OK127.0.0.1:6379> set lch 1OK127.0.0.1:6379> set lci 1OK127.0.0.1:6379> set lcj 1OK127.0.0.1:6379> set lck 1OK127.0.0.1:6379> set lcl 1OK127.0.0.1:6379> set lcm 1OK

可以看到，總共添加了 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>

然后發(fā)現(xiàn) redis-server 端的日志窗口中出現(xiàn)了如下的提示：

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 2255222552:C 21 Oct 2018 16:52:44.066 * DB saved on disk21971:M 21 Oct 2018 16:52:44.165 * Background saving terminated with success

從英文提示中可以大概讀懂這些內(nèi)容，它檢測(cè)到 300 秒內(nèi)有 10 條記錄被改動(dòng)，剛才我們添加了 13 條數(shù)據(jù)記錄，滿足 redis.conf 中對(duì)于 RDB 數(shù)據(jù)保存的條件。

所以這里執(zhí)行數(shù)據(jù)保存操作，并且提示開(kāi)辟了一個(gè) 22552 的進(jìn)程出來(lái)執(zhí)行保存操作，***提示保存成功。并且在目錄內(nèi)看到有 dump.rdb 文件生成。

現(xiàn)在將 Redis 進(jìn)程 Kill，哪些數(shù)據(jù)會(huì)被保存?通過(guò)命令 kill -9 pid ( pid 是進(jìn)程編號(hào))模擬 Redis 異常關(guān)閉，然后再啟動(dòng) Redis 。

我們來(lái)看一看，到底是只保存了 10 條記錄還是 13 條全都保存下來(lái)了?

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>

重啟后查看記錄，發(fā)現(xiàn) 13 條記錄中只有 10 條記錄會(huì)被保存，這也印證了之前所說(shuō)，RDB 方式的數(shù)據(jù)完整性是不可靠的，除非斷掉的那一刻正好是滿足觸發(fā)條件的條數(shù)。

關(guān)閉 RDB

剛才提到了，它是默認(rèn)啟用的，如果你不需要它可以在配置文件中將這 3 個(gè)配置注釋掉，并新增 save " " 即可：

  save "" 
# save 900 1 
# save 300 10 
# save 60 10000 

保存配置文件后需要重新啟動(dòng) Redis 服務(wù)才會(huì)生效，然后繼續(xù)添加十幾條記錄：

127.0.0.1:6379> keys * 
 1) "lcb" 
... 
23) "lca" 
24) "lcg" 
127.0.0.1:6379>  

在之前已有 10 條的基礎(chǔ)上我再增加了 14 條記錄，這次同樣要通過(guò) kill 來(lái)模擬 Redis 異常關(guān)閉，再啟動(dòng)服務(wù)看一看，數(shù)據(jù)是否還被保存：

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>  

發(fā)現(xiàn)后面添加的 14 條記錄并沒(méi)有被保存，恢復(fù)數(shù)據(jù)的時(shí)候僅僅只是恢復(fù)了之前的 10 條。

并且觀察 Redis 服務(wù)端窗口日志，并未發(fā)現(xiàn)像之前一樣的觸發(fā)保存的提示，證明 RDB 方式已經(jīng)被關(guān)閉。

RDB 主動(dòng)保存測(cè)試

通過(guò)配置文件關(guān)閉被動(dòng)觸發(fā)，那么主動(dòng)關(guān)閉是否還會(huì)生效呢?

在 Redis 客戶端( redis-cli )通過(guò) del 命令刪除幾條記錄，然后輸入 save 命令執(zhí)行保存操作：

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，它告訴我們數(shù)據(jù)已經(jīng)保存。

那么繼續(xù)模擬異常關(guān)閉，再打開(kāi)服務(wù)，看一看是否真的保存了這些操作：

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>  

 

果不其然，這幾個(gè)刪除操作都被保存了下來(lái)，恢復(fù)過(guò)來(lái)的數(shù)據(jù)中已經(jīng)沒(méi)有那 3 條記錄了，證明主動(dòng)關(guān)閉不受配置文件的影響。除了 Save 還有其他的保存方式么?

Save 和 Bgsave 保存

有的，Redis 提供了 Save 和 Bgsave 這兩種不同的保存方式，并且這兩個(gè)方式在執(zhí)行的時(shí)候都會(huì)調(diào)用 rdbSave 函數(shù)。

但它們調(diào)用的方式各有不同：

• Save 直接調(diào)用 rdbSave方法 ，阻塞 Redis 主進(jìn)程，直到保存完成為止。在主進(jìn)程阻塞期間，服務(wù)器不能處理客戶端的任何請(qǐng)求。
• Bgsave 則 Fork 出一個(gè)子進(jìn)程，子進(jìn)程負(fù)責(zé)調(diào)用 rdbSave ，并在保存完成之后向主進(jìn)程發(fā)送信號(hào)，通知保存已完成。

因?yàn)?rdbSave 在子進(jìn)程被調(diào)用，所以 Redis 服務(wù)器在 Bgsave 執(zhí)行期間仍然可以繼續(xù)處理客戶端的請(qǐng)求。

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 保存

事實(shí)上，Shutdown 命令也是可以保存數(shù)據(jù)的，驚不驚喜。它會(huì)在關(guān)閉前將數(shù)據(jù)保存下來(lái)，意不意外?

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 服務(wù)就被關(guān)閉掉了。我們需要重新啟動(dòng) Redis 服務(wù)，到客戶端中看一看是否生效：

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

竟然沒(méi)有生效，刺不刺激?這是為什么呢?明明官方文檔之 Shutdown 就說(shuō)會(huì)保存了才退出的，你騙人~注意到，文檔中有一句：

 

恍然大悟，原來(lái)是要在持久化被打開(kāi)的情況下，通過(guò) Shutdown 命令關(guān)閉才不會(huì)丟失數(shù)據(jù)，那么就到配置文件中將那幾個(gè) Save 的配置項(xiàng)打開(kāi)吧：

#   save ""save 900 1 
save 300 10 
save 60 10000 

然后再開(kāi)啟 Redis 服務(wù)，再嘗試一遍(過(guò)程為：添加 -> shutdown -> 重啟服務(wù) -> 查看)：

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 方式持久化的開(kāi)啟與配置

開(kāi)啟 AOF

默認(rèn)是不開(kāi)啟 AOF 的，如果想要啟用則需要到 redis.conf 配置文件中開(kāi)啟，打開(kāi) redis.conf：

$ vim redis.conf 

然后在文件中找到 appendonly 并將 no 改為 yes：

appendonly yes 

即為開(kāi)啟了 AOF 方式的持久化。

設(shè)置同步方式

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

appendfsync always  # 每次有數(shù)據(jù)修改發(fā)生時(shí)都會(huì)寫(xiě)入AOF文件（安全但是費(fèi)時(shí)）。 
appendfsync everysec  # 每秒鐘同步一次，該策略為AOF的缺省策略。 
appendfsync no  # 從不同步。高效但是數(shù)據(jù)不會(huì)被持久化。 

默認(rèn)配置是 everysec，你可以根據(jù)需求進(jìn)行調(diào)整，這里我將配置改成 always：

appendfsync always 
# appendfsync everysec 
# appendfsync no 

自定義 AOF 記錄文件的文件名

Redis 設(shè)置有默認(rèn)的文件名，在配置中顯示為：

appendfilename "appendonly.aof" 

你可以讓其保持默認(rèn)名字，也可以指定其他的文件名，比如：

appendfilename "RNGLetme.aof" 

 

將 appendonly、appendfsync 和 appendfilename 設(shè)置好并保存。重新啟動(dòng) Redis 服務(wù)：

$./redis-server 

通過(guò)命令 ls 查看本地文件，可以看到新生成了一個(gè)名為 RNGLetme.aof 的文件，可以使用：

$cat RNGLetme.aof 

來(lái)查看里面的內(nèi)容，由于當(dāng)前未進(jìn)行數(shù)據(jù)的改動(dòng)，所以是空白的。然后打開(kāi) Redis 的客戶端：

$./redis-cli 

并且添加幾條數(shù)據(jù)記錄：

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 這三條記錄，然后打開(kāi) 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 

 

每一次的數(shù)據(jù)添加都被記錄下來(lái)了。那如果是刪除操作呢，也會(huì)被記錄下來(lái)么?

127.0.0.1:6379> del edg 
(integer) 1 
127.0.0.1:6379> keys * 
1) "rng" 
2) "ig" 
127.0.0.1:6379>  

執(zhí)行完刪除操作后，再看一看 RNGLetme.aof 文件中的記錄：

 

 

對(duì)比之前的記錄，新增了 del edg 的操作記錄。這就印證了之前對(duì) AOF 的描述：以日志的方式將數(shù)據(jù)變動(dòng)記錄下來(lái)。

 

AOF 恢復(fù)測(cè)試

下面同樣是通過(guò) Kill 命令模擬 Redis 異常關(guān)閉：

gannicus@$ kill -9 22645 

然后再重新啟動(dòng) Redis 服務(wù)：

$ src/redis-server redis.conf 

接著通過(guò)客戶端看一看，那些數(shù)據(jù)是否都在：

$ src/redis-cli 
127.0.0.1:6379> keys * 
1) "ig" 
2) "rng" 

 

可以看到，rng 和 ig 都還在，意味著持久化是生效的。

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

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

為***的 dump.rdb 文件創(chuàng)建一個(gè)備份、將備份放到一個(gè)安全的地方。

執(zhí)行以下兩條命令：

redis-cli config set appendonly yes 
redis-cli config set save “” 

確保寫(xiě)命令會(huì)被正確地追加到 AOF 文件的末尾。執(zhí)行的***條命令開(kāi)啟了 AOF 功能：Redis 會(huì)阻塞直到初始 AOF 文件創(chuàng)建完成為止，之后 Redis 會(huì)繼續(xù)處理命令請(qǐng)求，并開(kāi)始將寫(xiě)入命令追加到 AOF 文件末尾。

執(zhí)行的第二條命令用于關(guān)閉 RDB 功能。這一步是可選的，如果你愿意的話，也可以同時(shí)使用 RDB 和 AOF 這兩種持久化功能。

注意：別忘了在 redis.conf 中打開(kāi) AOF 功能!否則服務(wù)器重啟后，之前通過(guò) CONFIG SET 命令設(shè)置的配置就會(huì)被遺忘，程序會(huì)按原來(lái)的配置來(lái)啟動(dòng)服務(wù)器。

優(yōu)先選擇 RDB 還是 AOF 呢?

[[250657]]

 

分析對(duì)比兩種方式并做了測(cè)試后，發(fā)現(xiàn)這是兩種不同風(fēng)格的持久化方式。那么應(yīng)該如何選擇呢?

• 對(duì)于企業(yè)級(jí)的中大型應(yīng)用，如果不想犧牲數(shù)據(jù)完整性但是又希望保持高效率，那么你應(yīng)該同時(shí)使用 RDB 和 AOF 兩種方式。
• 如果你不打算耗費(fèi)精力在這個(gè)地方，只需要保證數(shù)據(jù)完整性，那么優(yōu)先考慮使用 AOF 方式。
• RDB 方式非常適合大規(guī)模的數(shù)據(jù)恢復(fù)，如果業(yè)務(wù)對(duì)數(shù)據(jù)完整性和一致性要求不高，RDB 是很好的選擇。

備份 Redis 數(shù)據(jù)的建議

確保你的數(shù)據(jù)有完整的備份，磁盤(pán)故障、節(jié)點(diǎn)失效等問(wèn)題可能讓你的數(shù)據(jù)消失不見(jiàn)， 不進(jìn)行備份是非常危險(xiǎn)的。

Redis 對(duì)于數(shù)據(jù)備份是非常友好的，因?yàn)槟憧梢栽诜?wù)器運(yùn)行的時(shí)候?qū)?RDB 文件進(jìn)行復(fù)制：RDB 文件一旦被創(chuàng)建，就不會(huì)進(jìn)行任何修改。

當(dāng)服務(wù)器要?jiǎng)?chuàng)建一個(gè)新的 RDB 文件時(shí)，它先將文件的內(nèi)容保存在一個(gè)臨時(shí)文件里面，當(dāng)臨時(shí)文件寫(xiě)入完畢時(shí)，程序才使用 rename(2) 原子地用臨時(shí)文件替換原來(lái)的 RDB 文件。

這也就是說(shuō)，無(wú)論何時(shí)，復(fù)制 RDB 文件都是絕對(duì)安全的：

• 創(chuàng)建一個(gè)定期任務(wù)( cron job )，每小時(shí)將一個(gè) RDB 文件備份到一個(gè)文件夾，并且每天將一個(gè) RDB 文件備份到另一個(gè)文件夾。
• 確?？煺盏膫浞荻紟в邢鄳?yīng)的日期和時(shí)間信息，每次執(zhí)行定期任務(wù)腳本時(shí)，使用 Find 命令來(lái)刪除過(guò)期的快照：比如說(shuō)你可以保留最近 48 小時(shí)內(nèi)的每小時(shí)快照，還可以保留最近一兩個(gè)月的每日快照。
• 至少每天一次，將 RDB 備份到你的數(shù)據(jù)中心之外，或者至少是備份到你運(yùn)行 Redis 服務(wù)器的物理機(jī)器之外。

Redis 密碼持久化

在 Redis 中數(shù)據(jù)需要持久化，密碼也要持久化。在客戶端通過(guò)命令：

config set requirepass zxc9527 

可以為 Redis 設(shè)置值為 zxc9527 的密碼，但是當(dāng) Redis 關(guān)閉并重新啟動(dòng)后，權(quán)限驗(yàn)證功能就會(huì)失效，再也不需要密碼。

所以，密碼也需要在 redis.conf 中持久化。打開(kāi) redis.conf 找到 requirepass 配置項(xiàng)，取消其注釋并在后面設(shè)置密碼：

requirepass zxc9527 

 

保存后重啟 Redis 服務(wù)，密碼持久化即生效。

參考文章：

• Redis 源碼剖析和注釋(十七)--- RDB 持久化機(jī)制
• Redis 設(shè)計(jì)與實(shí)現(xiàn)
• www.redis.cn/
• Redis 兩種持久化方案 RDB 和 AOF 詳解
• Redis 持久化的幾種方式
• Redis 官方文檔