Redis 的數(shù)據(jù)全部在內存里，如果突然宕機武契，數(shù)據(jù)就會全部丟失咒唆，因此必須有一種機制來保證 Redis 的數(shù)據(jù)不會因為故障而丟失全释，這種機制就是 Redis 的持久化機制误债。

Redis有兩種持久化的方式：快照（RDB文件）和追加式文件（AOF文件)

一寝蹈、RDB（Redis DataBase）

1. 是什么

在指定的時間間隔內將內存中的數(shù)據(jù)集快照寫入磁盤箫老，也就是行話講的Snapshot快照槽惫，它恢復時是將快照文件直接讀到內存里辩撑。

Redis會單獨創(chuàng)建（fork）一個子進程來進行持久化合冀，會先將數(shù)據(jù)寫入到一個臨時文件中君躺，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件林螃。整個過程中疗认，主進程是不進行任何IO操作的横漏，這就確保了極高的性能缎浇，如果需要進行大規(guī)模數(shù)據(jù)的恢復，且對于數(shù)據(jù)恢復的完整性不是非常敏感二蓝，那 RDB 方式要比 AOF 方式更加的高效侣夷。RDB的缺點是最后一次持久化后的數(shù)據(jù)可能丟失百拓。

? What ? Redis 不是單進程的嗎?

Redis 使用操作系統(tǒng)的多進程 COW(Copy On Write) 機制來實現(xiàn)快照持久化衙传， fork是類Unix操作系統(tǒng)上創(chuàng)建進程的主要方法蓖捶。COW(Copy On Write)是計算機編程中使用的一種優(yōu)化策略扁远。

2. Fork

fork 的作用是復制一個與當前進程一樣的進程畅买。新進程的所有數(shù)據(jù)（變量谷羞、環(huán)境變量湃缎、程序計數(shù)器等）數(shù)值都和原進程一致嗓违，但是是一個全新的進程，并作為原進程的子進程比庄。 子進程讀取數(shù)據(jù)佳窑，然后序列化寫到磁盤中

rdb 默認保存的是dump.rdb文件

你可以對 Redis 進行設置神凑， 讓它在“ N 秒內數(shù)據(jù)集至少有 M 個改動”這一條件被滿足時溉委， 自動保存一次數(shù)據(jù)集瓣喊。

你也可以通過調用 SAVE 或者 BGSAVE ， 手動讓 Redis 進行數(shù)據(jù)集保存操作洪橘。

比如說， 以下設置會讓 Redis 在滿足“ 60 秒內有至少有 1000 個鍵被改動”這一條件時棵帽， 自動保存一次數(shù)據(jù)集：

save 60 1000

這種持久化方式被稱為快照（snapshot）熄求。

配置位置： SNAPSHOTTING

3. 如何觸發(fā)RDB快照

①. 配置文件中默認的快照配置

冷拷貝后重新使用 可以cp dump.rdb dump_new.rdb

②. 命令save或者是bgsave

• Save：save時只管保存，其它不管逗概，全部阻塞
• BGSAVE：Redis會在后臺異步進行快照操作弟晚，快照同時還可以響應客戶端請求∮馍唬可以通過lastsave命令獲取最后一次成功執(zhí)行快照的時間
• 執(zhí)行flushall命令卿城，也會產生dump.rdb文件铅搓，但里面是空的藻雪，無意義

4. 快照的運作方式]

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

①. Redis 調用 fork() 狸吞，產生一個子進程，此時同時擁有父進程和子進程指煎。

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

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

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

5. 如何恢復

將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可（CONFIG GET dir獲取目錄）

6. 優(yōu)勢

①. 一旦采用該方式像街，那么你的整個Redis數(shù)據(jù)庫將只包含一個文件黎棠，這對于文件備份而言是非常完美的晋渺。比如，你可能打算每個小時歸檔一次最近24小時的數(shù)據(jù)脓斩，同時還要每天歸檔一次最近30天的數(shù)據(jù)木西。通過這樣的備份策略，一旦系統(tǒng)出現(xiàn)災難性故障随静，我們可以非常容易的進行恢復八千。適合大規(guī)模的數(shù)據(jù)恢復

②. 對于災難恢復而言，RDB是非常不錯的選擇燎猛。因為我們可以非常輕松的將一個單獨的文件壓縮后再轉移到其它存儲介質上恋捆。

③. 性能最大化。對于Redis的服務進程而言重绷，在開始持久化時沸停，它唯一需要做的只是fork出子進程，之后再由子進程完成這些持久化的工作昭卓，這樣就可以極大的避免服務進程執(zhí)行IO操作了愤钾。

④. 相比于AOF機制，如果數(shù)據(jù)集很大葬凳，RDB的啟動效率會更高绰垂。

7. 劣勢

①. 如果你想保證數(shù)據(jù)的高可用性，即最大限度的避免數(shù)據(jù)丟失火焰，那么RDB將不是一個很好的選擇劲装。因為系統(tǒng)一旦在定時持久化之前出現(xiàn)宕機現(xiàn)象，此前沒有來得及寫入磁盤的數(shù)據(jù)都將丟失（丟失最后一次快照后的所有修改）昌简。

②. 由于RDB是通過fork子進程來協(xié)助完成數(shù)據(jù)持久化工作的占业，內存中的數(shù)據(jù)被克隆了一份，大致2倍的膨脹性需要考慮纯赎，因此谦疾，如果當數(shù)據(jù)集較大時，可能會導致整個服務器停止服務幾百毫秒犬金，甚至是1秒鐘念恍。

8. 如何停止

動態(tài)停止RDB保存規(guī)則的方法：redis-cli config set save ""

9. 總結

①. RDB是一個非常緊湊的文件

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

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

④. 數(shù)據(jù)丟失風險大

⑤. RDB需要經常fork子進程來保存數(shù)據(jù)集到硬盤上瞳氓，當數(shù)據(jù)集比較大的時候，fork的過程是非常耗時的栓袖，可能會導致redis在一些毫秒級不能響應客戶端的請求

二匣摘、AOF（Append Only File）

1. 是什么

以日志的形式來記錄每個寫操作店诗，將 Redis 執(zhí)行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件音榜，redis 啟動之初會讀取該文件重新構建數(shù)據(jù)庞瘸，也就是「重放」。換言之囊咏，redis 重啟的話就根據(jù)日志文件的內容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復工作恕洲。

AOF 默認保存的是 **appendonly.aof ** 文件

配置位置： APPEND ONLY MODE

2. AOF啟動/修復/恢復

正常恢復

• 啟動：設置Yes 修改默認的appendonly no梅割，改為yes
• 將有數(shù)據(jù)的 aof 文件復制一份保存到對應目錄(config get dir)
• 恢復：重啟redis然后重新加載

異乘冢恢復

• 啟動：設置Yes 修改默認的appendonly no，改為yes
• 備份被寫壞的AOF文件
• 修復：redis-check-aof --fix進行修復 + AOF文件
• 恢復：重啟redis然后重新加載

3. rewrite（AOF 重寫）

①. 是什么：AOF采用文件追加方式户辞，文件會越來越大為避免出現(xiàn)此種情況泌类，新增了重寫機制,當 AOF 文件的大小超過所設定的閾值時，Redis就會啟動 AOF 文件的內容壓縮底燎，只保留可以恢復數(shù)據(jù)的最小指令集刃榨，可以使用命令bgrewriteaof

②. 重寫原理：AOF 文件持續(xù)增長而過大時，會 fork 出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)双仍，遍歷新進程的內存中數(shù)據(jù)枢希，每條記錄有一條的 Set 語句。重寫 aof 文件的操作朱沃，并沒有讀取舊的aof文件苞轿，而是將整個內存中的數(shù)據(jù)庫內容用命令的方式重寫了一個新的 aof 文件，這點和快照有點類似

③. 觸發(fā)機制：Redis 會記錄上次重寫時的 AOF 大小逗物，默認配置是當 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于64M 時觸發(fā)

4. AOF耐久性

你可以配置 Redis 多久才將數(shù)據(jù) fsync 到磁盤一次搬卒。

有三個選項：

• 每次有新命令追加到 AOF 文件時就執(zhí)行一次 fsync ：非常慢，也非常安全翎卓。
• 每秒 fsync 一次：足夠快（和使用 RDB 持久化差不多）契邀，并且在故障時只會丟失 1 秒鐘的數(shù)據(jù)。
• 從不 fsync ：將數(shù)據(jù)交給操作系統(tǒng)來處理失暴。更快坯门，也更不安全的選擇。

推薦（并且也是默認）的措施為每秒 fsync 一次逗扒， 這種 fsync 策略可以兼顧速度和安全性田盈。

總是 fsync 的策略在實際使用中非常慢，頻繁調用 fsync 注定了這種策略不可能快得起來缴阎。

5. 如果 AOF 文件出錯了，怎么辦简软？

服務器可能在程序正在對 AOF 文件進行寫入時停機蛮拔， 如果停機造成了 AOF 文件出錯（corrupt）述暂， 那么 Redis 在重啟時會拒絕載入這個 AOF 文件， 從而確保數(shù)據(jù)的一致性不會被破壞建炫。

當發(fā)生這種情況時畦韭， 可以用以下方法來修復出錯的 AOF 文件：

①. 為現(xiàn)有的 AOF 文件創(chuàng)建一個備份。

②. 使用 Redis 附帶的 redis-check-aof 程序肛跌，對原來的 AOF 文件進行修復艺配。

$ redis-check-aof --fix

①. （可選）使用 diff -u 對比修復后的 AOF 文件和原始 AOF 文件的備份，查看兩個文件之間的不同之處衍慎。

②. 重啟 Redis 服務器转唉，等待服務器載入修復后的 AOF 文件，并進行數(shù)據(jù)恢復稳捆。

6. AOF運作方式

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

以下是 AOF 重寫的執(zhí)行步驟：

• Redis 執(zhí)行 fork() 乔夯，現(xiàn)在同時擁有父進程和子進程砖织。
• 子進程開始將新 AOF 文件的內容寫入到臨時文件。
• 對于所有新執(zhí)行的寫入命令末荐，父進程一邊將它們累積到一個內存緩存中侧纯，一邊將這些改動追加到現(xiàn)有 AOF 文件的末尾： 這樣即使在重寫的中途發(fā)生停機，現(xiàn)有的 AOF 文件也還是安全的甲脏。
• 當子進程完成重寫工作時眶熬，它給父進程發(fā)送一個信號，父進程在接收到信號之后剃幌，將內存緩存中的所有數(shù)據(jù)追加到新 AOF 文件的末尾聋涨。
• 搞定！現(xiàn)在 Redis 原子地用新文件替換舊文件负乡，之后所有命令都會直接追加到新 AOF 文件的末尾牍白。

7. 優(yōu)勢

• 該機制可以帶來更高的數(shù)據(jù)安全性，即數(shù)據(jù)持久性抖棘。Redis中提供了3種同步策略茂腥，即每秒同步、每修改同步和不同步切省。事實上最岗，每秒同步也是異步完成的，其效率也是非常高的朝捆，所差的是一旦系統(tǒng)出現(xiàn)宕機現(xiàn)象般渡，那么這一秒鐘之內修改的數(shù)據(jù)將會丟失。而每修改同步，我們可以將其視為同步持久化驯用，即每次發(fā)生的數(shù)據(jù)變化都會被立即記錄到磁盤中脸秽。可以預見蝴乔，這種方式在效率上是最低的记餐。至于無同步，無需多言薇正，我想大家都能正確的理解它片酝。
• 由于該機制對日志文件的寫入操作采用的是append模式，因此在寫入過程中即使出現(xiàn)宕機現(xiàn)象挖腰，也不會破壞日志文件中已經存在的內容雕沿。然而如果我們本次操作只是寫入了一半數(shù)據(jù)就出現(xiàn)了系統(tǒng)崩潰問題，不用擔心曙聂，在Redis下一次啟動之前晦炊，我們可以通過redis-check-aof工具來幫助我們解決數(shù)據(jù)一致性的問題。
• 如果日志過大宁脊，Redis可以自動啟用rewrite機制断国。即Redis以append模式不斷的將修改數(shù)據(jù)寫入到老的磁盤文件中，同時Redis還會創(chuàng)建一個新的文件用于記錄此期間有哪些修改命令被執(zhí)行榆苞。因此在進行rewrite切換時可以更好的保證數(shù)據(jù)安全性稳衬。
• AOF 包含一個格式清晰、易于理解的日志文件用于記錄所有的修改操作坐漏。事實上薄疚，我們也可以通過該文件完成數(shù)據(jù)的重建。因此 AOF 文件的內容非常容易被人讀懂赊琳， 對文件進行分析（parse）也很輕松街夭。 導出（export） AOF 文件也非常簡單： 舉個例子， 如果你不小心執(zhí)行了 FLUSHALL 命令躏筏， 但只要 AOF 文件未被重寫板丽， 那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令趁尼， 并重啟 Redis 埃碱， 就可以將數(shù)據(jù)集恢復到 FLUSHALL 執(zhí)行之前的狀態(tài)。

8. 劣勢

• 對于相同數(shù)量的數(shù)據(jù)集而言酥泞，AOF文件通常要大于RDB文件砚殿。恢復速度慢于rdb芝囤。
• 根據(jù)同步策略的不同似炎，AOF在運行效率上往往會慢于RDB辛萍。總之羡藐，每秒同步策略的效率是比較高的叹阔，同步禁用策略的效率和RDB一樣高效。

9. 總結

• AOF 文件是一個只進行追加的日志文件
• Redis 可以在 AOF 文件體積變得過大時传睹，自動在后臺對 AOF 進行重寫
• AOF文件有序的保存了對數(shù)據(jù)庫執(zhí)行的所有寫入操作，這些寫入操作以Redis協(xié)議的格式保存岸晦，因此AOF文件的內容非常容易被人讀懂欧啤，對文件進行分析也很輕松
• 對于相同的數(shù)據(jù)集來說，AOF 文件的體積通常需要大于 RDB 文件的體積
• 根據(jù)所使用的 fsync 策略启上，AOF 的速度可能會慢于 RDB

10. 怎么從 RDB 持久化切換到 AOF 持久化

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

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

 redis-cli> CONFIG SET appendonly yes     

 redis-cli> CONFIG SET save "" 

• 確保命令執(zhí)行之后，數(shù)據(jù)庫的鍵的數(shù)量沒有改變包券。
• 確保寫命令會被正確地追加到 AOF 文件的末尾纫谅。

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

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

別忘了在 redis.conf 中打開 AOF 功能亮元！ 否則的話猛计， 服務器重啟之后， 之前通過 CONFIG SET 設置的配置就會被遺忘爆捞， 程序會按原來的配置來啟動服務器奉瘤。

三、Which one

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

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

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

④. 同時開啟兩種持久化方式

• 在這種情況下,當 redis 重啟的時候會優(yōu)先載入 AOF 文件來恢復原始的數(shù)據(jù),因為在通常情況下 AOF 文件保存的數(shù)據(jù)集要比 RDB 文件保存的數(shù)據(jù)集要完整。
• RDB 的數(shù)據(jù)不實時苛秕，同時使用兩者時服務器重啟也只會找 AOF 文件肌访。那要不要只使用AOF 呢媒咳？建議不要阁簸，因為 RDB 更適合用于備份數(shù)據(jù)庫(AOF 在不斷變化不好備份)仔雷，快速重啟，而且不會有 AOF 可能潛在的bug甩牺，留著作為一個萬一的手段。

1. 性能建議

• 因為 RDB 文件只用作后備用途阴颖，建議只在 Slave上持久化 RDB 文件英妓，而且只要15分鐘備份一次就夠了，只保留save 900 1這條規(guī)則酒请。
• 如果Enalbe AOF骡技，好處是在最惡劣情況下也只會丟失不超過兩秒數(shù)據(jù)，啟動腳本較簡單只load自己的 AOF 文件就可以了羞反。代價一是帶來了持續(xù)的 IO布朦，二是 AOF rewrite 的最后將 rewrite 過程中產生的新數(shù)據(jù)寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可昼窗，應該盡量減少 AOF rewrite 的頻率是趴，AOF 重寫的基礎大小默認值64M太小了，可以設到5G以上澄惊。默認超過原大小100%大小時重寫可以改到適當?shù)臄?shù)值唆途。
• 如果不 Enable AOF ，僅靠 Master-Slave Replication 實現(xiàn)高可用性也可以掸驱。能省掉一大筆 IO 肛搬，也減少了rewrite 時帶來的系統(tǒng)波動。代價是如果 Master/Slav e同時宕掉亭敢，會丟失十幾分鐘的數(shù)據(jù)滚婉，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個帅刀。

# 鏈接 Java程序員福利"常用資料分享"