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

Redis 是一個開源（ BSD 許可）的，內(nèi)存中的數(shù)據(jù)結構存儲系統(tǒng)，它可以用作數(shù)據(jù)庫、緩存和消息中間件。它支持的數(shù)據(jù)類型很豐富，如字符串、鏈表、集 合、以及散列等，并且還支持多種排序功能。

什么叫持久化？

用一句話可以將持久化概括為：將數(shù)據(jù)（如內(nèi)存中的對象）保存到可永久保存的存儲設備中。持久化的主要應用是將內(nèi)存中的對象存儲在數(shù)據(jù)庫中，或者存儲在磁盤文件中、 XML 數(shù)據(jù)文件中等等。

從應用層與系統(tǒng)層理解持久化

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

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

系統(tǒng)層：如果關閉( Shutdown )你的系統(tǒng)（電腦）然后重新啟動則先前的數(shù)據(jù)依然存在。

Redis 為什么要持久化？

Redis 中的數(shù)據(jù)類型都支持 push/pop、add/remove 及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，Redis 支持各種不同方式的排序。與 Memcached 一樣，為了保證效率，數(shù)據(jù)都是緩存在內(nèi)存中。

對，數(shù)據(jù)都是緩存在內(nèi)存中的，當你重啟系統(tǒng)或者關閉系統(tǒng)后，緩存在內(nèi)存中的數(shù)據(jù)都會消失殆盡，再也找不回來了。所以，為了讓數(shù)據(jù)能夠長期保存，就要將 Redis 放在緩存中的數(shù)據(jù)做持久化存儲。

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

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

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

2、AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執(zhí)行這些命令來恢復原始的數(shù)據(jù),AOF命令以redis協(xié)議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進行后臺重寫,使得AOF文件的體積不至于過大。

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

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

如果你不知道該選擇哪一個級別的持久化方式，那我們就先來了解一下 AOF 方式和 RDB 方式有什么樣的區(qū)別，并且它們各自有何優(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ù)需求恢復到不同版本的數(shù)據(jù)集。

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

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

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

當 Redis 需要保存 dump.rdb 文件時， 服務器執(zhí)行以下操作:

Redis 調(diào)用forks. 同時擁有父進程和子進程。

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

當子進程完成對新 RDB 文件的寫入時，Redis 用新 RDB 文件替換原來的 RDB 文件，并刪除舊的 RDB 文件。

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

AOF 方式的優(yōu)點

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

你可以使用不同的 fsync 策略：無 fsync、每秒 fsync 、每次寫的時候 fsync .使用默認的每秒 fsync 策略, Redis 的性能依然很好( fsync 是由后臺線程進行處理的,主線程會盡力處理客戶端請求),一旦出現(xiàn)故障，你最多丟失1秒的數(shù)據(jù)。

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

Redis 可以在 AOF 文件體積變得過大時，自動地在后臺對 AOF 進行重寫： 重寫后的新 AOF 文件包含了恢復當前數(shù)據(jù)集所需的最小命令集合。 整個重寫操作是絕對安全的，因為 Redis 在創(chuàng)建新 AOF 文件的過程中，會繼續(xù)將命令追加到現(xiàn)有的 AOF 文件里面，即使重寫過程中發(fā)生停機，現(xiàn)有的 AOF 文件也不會丟失。 而一旦新 AOF 文件創(chuàng)建完畢，Redis 就會從舊 AOF 文件切換到新 AOF 文件，并開始對新 AOF 文件進行追加操作。

AOF 文件有序地保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作， 這些寫入操作以 Redis 協(xié)議的格式保存， 因此 AOF 文件的內(nèi)容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執(zhí)行了 FLUSHALL 命令， 但只要 AOF 文件未被重寫， 那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數(shù)據(jù)集恢復到 FLUSHALL 執(zhí)行之前的狀態(tài)。

優(yōu)點對比總結

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

AOF 方式默認每秒鐘備份1次，頻率很高，它的操作方式是以追加的方式記錄日志而不是數(shù)據(jù)，并且它的重寫過程是按順序進行追加，所以它的文件內(nèi)容非常容易讀懂。可以在某些需要的時候打開 AOF 文件對其編輯，增加或刪除某些記錄，最后再執(zhí)行恢復操作。

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

RDB 方式的缺點

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

RDB 需要經(jīng)常 fork 子進程來保存數(shù)據(jù)集到硬盤上,當數(shù)據(jù)集比較大的時候, fork 的過程是非常耗時的,可能會導致 Redis 在一些毫秒級內(nèi)不能響應客戶端的請求。如果數(shù)據(jù)集巨大并且 CPU 性能不是很好的情況下,這種情況會持續(xù)1秒, AOF 也需要 fork ,但是你可以調(diào)節(jié)重寫日志文件的頻率來提高數(shù)據(jù)集的耐久度。

AOF 方式的缺點

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

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

缺點對比總結

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

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

工作原理

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

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

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

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

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

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

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

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

這個目錄在哪里呢？

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

Redis 版本說明

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

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

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

關閉 RDB

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

發(fā)現(xiàn)后面添加的 14 條記錄并沒有被保存，恢復數(shù)據(jù)的時候僅僅只是恢復了之前的 10 條。并且觀察 Redis 服務端窗口日志，并未發(fā)現(xiàn)像之前一樣的觸發(fā)保存的提示，證明 RDB 方式已經(jīng)被關閉。

RDB 主動保存測試

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

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

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

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

除了save還有其他的保存方式么？

save 和 bgsave 保存

shutdown 保存

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

注意到，文檔中有一句

這下終于弄明白了。

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

開啟 AOF

設置同步方式

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

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

Redis 設置有默認的文件名，在配置中顯示為：

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

每一次的數(shù)據(jù)添加都被記錄下來了。

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

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

AOF 恢復測試

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

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

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

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

為最新的 dump.rdb 文件創(chuàng)建一個備份、將備份放到一個安全的地方。執(zhí)行以下兩條命令:

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

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

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

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

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

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

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

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

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

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

Redis 對于數(shù)據(jù)備份是非常友好的， 因為你可以在服務器運行的時候?qū)?RDB 文件進行復制： RDB 文件一旦被創(chuàng)建， 就不會進行任何修改。 當服務器要創(chuàng)建一個新的 RDB 文件時， 它先將文件的內(nèi)容保存在一個臨時文件里面， 當臨時文件寫入完畢時， 程序才使用 rename(2) 原子地用臨時文件替換原來的 RDB 文件。

這也就是說，無論何時，復制 RDB 文件都是絕對安全的。

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

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

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

Redis 密碼持久化

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

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

參考文章

Redis源碼剖析和注釋（十七）--- RDB持久化機制

Redis 設計與實現(xiàn)

http://www.redis.cn/

Redis兩種持久化方案RDB和AOF詳解

redis持久化的幾種方式

Redis 官方文檔

本文轉(zhuǎn)載自異步社區(qū)。

Redis 大數(shù)據(jù)

版權聲明：本文內(nèi)容由網(wǎng)絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權內(nèi)容。