轉(zhuǎn)載

Redis 是一個開源（ BSD 許可）的，內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)存儲系統(tǒng)，它可以用作數(shù)據(jù)庫、緩存和消息中間件.

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

什么叫持久化?

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

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

也可以從如下兩個層面來理解持久化：

應(yīng)用層：如果關(guān)閉( Close )你的應(yīng)用，然后重新啟動則先前的數(shù)據(jù)依然存在。

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

Redis 為什么要持久化?

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

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

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

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

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

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

RDB 持久化方式能夠在指定的時間間隔對你的數(shù)據(jù)進(jìn)行快照存儲。

AOF 持久化方式記錄每次對服務(wù)器寫的操作，當(dāng)服務(wù)器重啟的時候會重新執(zhí)行這些命令來恢復(fù)原始的數(shù)據(jù)，AOF 命令以 Redis 協(xié)議追加保存每次寫的操作到文件末尾。

Redis 還能對 AOF 文件進(jìn)行后臺重寫，使得 AOF 文件的體積不至于過大。

如果你只希望你的數(shù)據(jù)在服務(wù)器運行的時候存在，你也可以不使用任何持久化方式。

你也可以同時開啟兩種持久化方式，在這種情況下，當(dāng) Redis 重啟的時候會優(yōu)先載入 AOF 文件來恢復(fù)原始的數(shù)據(jù)，因為在通常情況下 AOF 文件保存的數(shù)據(jù)集要比 RDB 文件保存的數(shù)據(jù)集要完整。

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

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

RDB 方式與 AOF 方式的優(yōu)點對比

首先我們來看一看官方對于兩種方式的優(yōu)點描述，并做個對比，然后再看一看兩種方式的缺點描述。

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

RDB 是一個非常緊湊的文件,它保存了某個時間點的數(shù)據(jù)集，非常適用于數(shù)據(jù)集的備份。

比如你可以在每個小時保存一下過去 24 小時內(nèi)的數(shù)據(jù)，同時每天保存過去 30 天的數(shù)據(jù)，這樣即使出了問題你也可以根據(jù)需求恢復(fù)到不同版本的數(shù)據(jù)集。

RDB 是一個緊湊的單一文件，很方便傳送到另一個遠(yuǎn)端數(shù)據(jù)中心，非常適用于災(zāi)難恢復(fù)。

RDB 在保存 RDB 文件時父進(jìn)程唯一需要做的就是 Fork 出一個子進(jìn)程，接下來的工作全部由子進(jìn)程來做，父進(jìn)程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化 Redis 的性能。

與 AOF 相比，在恢復(fù)大的數(shù)據(jù)集的時候，RDB 方式會更快一些。

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

Redis 調(diào)用 Forks，同時擁有父進(jìn)程和子進(jìn)程。

子進(jìn)程將數(shù)據(jù)集寫入到一個臨時 RDB 文件中。

當(dāng)子進(jìn)程完成對新 RDB 文件的寫入時，Redis 用新 RDB 文件替換原來的 RDB 文件，并刪除舊的 RDB 文件。

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

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

使用 AOF 會讓你的 Redis 更加耐久。

你可以使用不同的 Fsync 策略：無 Fsync、每秒 Fsync 、每次寫的時候 Fsync 使用默認(rèn)的每秒 Fsync 策略。

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

AOF文件是一個只進(jìn)行追加的日志文件，所以不需要寫入 Seek，即使由于某些原因(磁盤空間已滿，寫的過程中宕機(jī)等等)未執(zhí)行完整的寫入命令，你也可使用 redis-check-aof 工具修復(fù)這些問題。

Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進(jìn)行重寫： 重寫后的新 AOF 文件包含了恢復(fù)當(dāng)前數(shù)據(jù)集所需的最小命令集合。

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

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

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

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

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

優(yōu)點對比總結(jié)：

RDB 方式可以保存過去一段時間內(nèi)的數(shù)據(jù)，并且保存結(jié)果是一個單一的文件，可以將文件備份到其他服務(wù)器，并且在回復(fù)大量數(shù)據(jù)的時候，RDB 方式的速度會比 AOF 方式的回復(fù)速度要快。

AOF 方式默認(rèn)每秒鐘備份 1 次，頻率很高，它的操作方式是以追加的方式記錄日志而不是數(shù)據(jù)，并且它的重寫過程是按順序進(jìn)行追加，所以它的文件內(nèi)容非常容易讀懂。

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

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

RDB 方式的缺點：

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

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

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

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

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

AOF 方式的缺點：

對于相同的數(shù)據(jù)集來說，AOF 文件的體積通常要大于 RDB 文件的體積。

根據(jù)所使用的 Fsync 策略，AOF 的速度可能會慢于 RDB。在一般情況下，每秒 Fsync 的性能依然非常高，而關(guān)閉 Fsync 可以讓 AOF 的速度和 RDB 一樣快，即使在高負(fù)荷之下也是如此。

不過在處理巨大的寫入載入時，RDB 可以提供更有保證的最大延遲時間(Latency)。

缺點對比總結(jié)：

RDB 由于備份頻率不高，所以在回復(fù)數(shù)據(jù)的時候有可能丟失一小段時間的數(shù)據(jù)，而且在數(shù)據(jù)集比較大的時候有可能對毫秒級的請求產(chǎn)生影響。

AOF 的文件提及比較大，而且由于保存頻率很高，所以整體的速度會比 RDB 慢一些，但是性能依舊很高。

RDB 與 AOF 工作原理

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

Redis 執(zhí)行 fork() ，現(xiàn)在同時擁有父進(jìn)程和子進(jìn)程。

子進(jìn)程開始將新 AOF 文件的內(nèi)容寫入到臨時文件。

對于所有新執(zhí)行的寫入命令，父進(jìn)程一邊將它們累積到一個內(nèi)存緩存中，一邊將這些改動追加到現(xiàn)有 AOF 文件的末尾，這樣即使在重寫的中途發(fā)生停機(jī)，現(xiàn)有的 AOF 文件也還是安全的。

當(dāng)子進(jìn)程完成重寫工作時，它給父進(jìn)程發(fā)送一個信號，父進(jìn)程在接收到信號之后，將內(nèi)存緩存中的所有數(shù)據(jù)追加到新 AOF 文件的末尾。

現(xiàn)在 Redis 原子地用新文件替換舊文件，之后所有命令都會直接追加到新 AOF 文件的末尾。

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

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

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

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

save 900 1save 300 10save 60 10000

其含義為：

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

滿足觸發(fā)條件后，數(shù)據(jù)就會被保存為快照，正是因為這樣才說 RDB 的數(shù)據(jù)完整性是比不上 AOF 的。

觸發(fā)保存條件后，會在指定的目錄生成一個名為 dump.rdb 的文件，等到下一次啟動 Redis 時，Redis 會去讀取該目錄下的 dump.rdb 文件，將里面的數(shù)據(jù)恢復(fù)到 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>

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

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

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

RDB 被動觸發(fā)保存測試

剛才提到它分為主動保存與被動觸發(fā)，現(xiàn)在我們來測試一下被動觸發(fā)。首先啟動 redis-server，然后再打開客戶端 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)容，它檢測到 300 秒內(nèi)有 10 條記錄被改動，剛才我們添加了 13 條數(shù)據(jù)記錄，滿足 redis.conf 中對于 RDB 數(shù)據(jù)保存的條件。

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

現(xiàn)在將 Redis 進(jìn)程 Kill，哪些數(shù)據(jù)會被保存?通過命令 kill -9 pid ( pid 是進(jìn)程編號)模擬 Redis 異常關(guān)閉，然后再啟動 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>

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

關(guān)閉 RDB

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

save ""

# save 900 1

# save 300 10

# save 60 10000

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

127.0.0.1:6379> keys *

1) "lcb"

...

23) "lca"

24) "lcg"

127.0.0.1:6379>

在之前已有 10 條的基礎(chǔ)上我再增加了 14 條記錄，這次同樣要通過 kill 來模擬 Redis 異常關(guān)閉，再啟動服務(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 條記錄并沒有被保存，恢復(fù)數(shù)據(jù)的時候僅僅只是恢復(fù)了之前的 10 條。

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

RDB 主動保存測試

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

在 Redis 客戶端( redis-cli )通過 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)閉，再打開服務(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>

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

Save 和 Bgsave 保存

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

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

Save 直接調(diào)用 rdbSave方法 ，阻塞 Redis 主進(jìn)程，直到保存完成為止。在主進(jìn)程阻塞期間，服務(wù)器不能處理客戶端的任何請求。

Bgsave 則 Fork 出一個子進(jìn)程，子進(jìn)程負(fù)責(zé)調(diào)用 rdbSave ，并在保存完成之后向主進(jìn)程發(fā)送信號，通知保存已完成。

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

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 命令也是可以保存數(shù)據(jù)的，驚不驚喜。它會在關(guān)閉前將數(shù)據(jù)保存下來，意不意外?

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

gannicus@$ src/redis-cli

127.0.0.1:6379> keys *

1) "lce"

2) "lcf"

3) "lcd"

4) "lch"

5) "lcg"

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

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

# save ""save 900 1

save 300 10

save 60 10000

然后再開啟 Redis 服務(wù)，再嘗試一遍(過程為：添加 -> 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 方式持久化的開啟與配置

開啟 AOF

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

$ vim redis.conf

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

appendonly yes

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

設(shè)置同步方式

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

appendfsync always # 每次有數(shù)據(jù)修改發(fā)生時都會寫入AOF文件（安全但是費時）。

appendfsync everysec # 每秒鐘同步一次，該策略為AOF的缺省策略。

appendfsync no # 從不同步。高效但是數(shù)據(jù)不會被持久化。

默認(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è)置好并保存。重新啟動 Redis 服務(wù)：

$./redis-server

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

$cat RNGLetme.aof

來查看里面的內(nèi)容，由于當(dāng)前未進(jìn)行數(shù)據(jù)的改動，所以是空白的。然后打開 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 這三條記錄，然后打開 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ù)添加都被記錄下來了。那如果是刪除操作呢，也會被記錄下來么?

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 文件中的記錄：

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

AOF 恢復(fù)測試

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

gannicus@$ kill -9 22645

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

$ src/redis-server redis.conf

接著通過客戶端看一看，那些數(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)建一個備份、將備份放到一個安全的地方。

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

redis-cli config set appendonly yes

redis-cli config set save “”

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

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

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

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

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

對于企業(yè)級的中大型應(yīng)用，如果不想犧牲數(shù)據(jù)完整性但是又希望保持高效率，那么你應(yīng)該同時使用 RDB 和 AOF 兩種方式。

如果你不打算耗費精力在這個地方，只需要保證數(shù)據(jù)完整性，那么優(yōu)先考慮使用 AOF 方式。

RDB 方式非常適合大規(guī)模的數(shù)據(jù)恢復(fù)，如果業(yè)務(wù)對數(shù)據(jù)完整性和一致性要求不高，RDB 是很好的選擇。

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

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

Redis 對于數(shù)據(jù)備份是非常友好的，因為你可以在服務(wù)器運行的時候?qū)?RDB 文件進(jìn)行復(fù)制：RDB 文件一旦被創(chuàng)建，就不會進(jìn)行任何修改。

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

這也就是說，無論何時，復(fù)制 RDB 文件都是絕對安全的：

創(chuàng)建一個定期任務(wù)( cron job )，每小時將一個 RDB 文件備份到一個文件夾，并且每天將一個 RDB 文件備份到另一個文件夾。

確保快照的備份都帶有相應(yīng)的日期和時間信息，每次執(zhí)行定期任務(wù)腳本時，使用 Find 命令來刪除過期的快照：比如說你可以保留最近 48 小時內(nèi)的每小時快照，還可以保留最近一兩個月的每日快照。

至少每天一次，將 RDB 備份到你的數(shù)據(jù)中心之外，或者至少是備份到你運行 Redis 服務(wù)器的物理機(jī)器之外。

Redis 密碼持久化

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

config set requirepass zxc9527

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

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

requirepass zxc9527

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