Redis面試篇 -- Redis持久化的方式有哪些？優缺點分別是什麼？

Redis持久化方式 

---

 

       持久化的目的主要是作災難恢復，數據恢復。因爲Redis的數據全都放在內存裏面，若是Redis掛了，沒有配置持久化的話，重啓的時候數據會所有丟失。

        忽然間，大量的請求過來，緩存全都沒法命中，形成緩存雪崩，mysql沒法承載大量的請求，形成整個系統崩潰。 若是把Redis持久化作好，即便Redis故障了，也可以當即重啓，對外提供服務。

 

        Redis持久化分爲兩種：

• RDB持久化： 在指定的時間間隔內將內存中的數據集快照寫入磁盤，實際操做過程是fork一個子進程，先將數據集寫入臨時文件，寫入成功後，再替換以前的文件，用二進制壓縮存儲 。
• AOF持久化： AOF 機制對每條寫入命令做爲日誌，以 append-only 的模式寫入一個日誌文件中，在 redis 重啓的時候，能夠經過回放 AOF 日誌中的寫入指令來從新構建整個數據集。            

        經過RDB和AOF，均可以Redis內存中的數據持久化到磁盤中，也能夠被分到其餘地方，好比阿里雲等。若是Redis掛了，能夠從磁盤或者阿里雲等地方拷貝數據到Redis中，重啓Redis，Redis就會自動根據文件來重構數據。

        若是同時使用RDB和AOF 兩種持久化機制，那麼在 redis 重啓的時候，會使用 AOF 來從新構建數據，由於 AOF 中的數據更加完整。

RDB持久化的配置：

     Redis會將數據集的快照dump到dump.rdb文件中。此外，咱們也能夠經過配置文件來修改Redis服務器dump快照的頻率，在打開6379.conf文件以後，咱們搜索save，能夠看到下面的配置信息：

 　save 900 1              #在900秒(15分鐘)以後，若是至少有1個key發生變化，則dump內存快照。
   save 300 10             #在300秒(5分鐘)以後，若是至少有10個key發生變化，則dump內存快照。
   save 60 10000           #在60秒(1分鐘)以後，若是至少有10000個key發生變化，則dump內存快照。

AOF持久化配置：

     在Redis的配置文件中存在三種同步方式，它們分別是：

  appendfsync always      #每次有數據修改發生時都會寫入AOF文件。
  appendfsync everysec   #每秒鐘同步一次，該策略爲AOF的缺省策略。
  appendfsync no            #從不一樣步。高效可是數據不會被持久化。

 

RDB和AOF的優缺點

---

 

RDB的優缺點：

• 一旦採用該方式，那麼你的整個Redis數據庫將只包含一個文件，這對於文件備份而言是很是完美的。好比，你可能打算每一個小時歸檔一次最近24小時的數 據，同時還要天天歸檔一次最近30天的數據。經過這樣的備份策略，一旦系統出現災難性故障，咱們能夠很是容易的進行恢復。
• 相對於 AOF 持久化機制來講，直接基於 RDB 數據文件來重啓和恢復 redis 進程，更加快速。
• RDB 對 redis 對外提供的讀寫服務，影響很是小，可讓 redis 保持高性能，由於 redis 主進程只須要 fork 一個子進程，讓子進程執行磁盤 IO 操做來進行 RDB 持久化便可。
• 對於災難恢復而言，RDB是很是不錯的選擇。由於咱們能夠很是輕鬆的將一個單獨的文件壓縮後再轉移到其它存儲介質上。
• 若是想要在 redis 故障時，儘量少的丟失數據，那麼 RDB 沒有 AOF 好。通常來講，RDB 數據快照文件，都是每隔 5 分鐘，或者更長時間生成一次，這個時候就得接受一旦 redis 進程宕機，那麼會丟失最近 5 分鐘的數據。
• RDB 每次在 fork 子進程來執行 RDB 快照數據文件生成的時候，若是數據文件特別大，可能會致使對客戶端提供的服務暫停數毫秒，或者甚至數秒。

 

AOF的優缺點：

• AOF 能夠更好的保護數據不丟失，通常 AOF 會每隔 1 秒，經過一個後臺線程執行一次fsync操做，最多丟失 1 秒鐘的數據。
• AOF 日誌文件以append-only模式寫入，因此沒有任何磁盤尋址的開銷，寫入性能很是高，並且文件不容易破損。 若是咱們本次操做只是寫入了一半數據就出現了系統崩潰問題，不用擔憂，在Redis下一次啓動以前，咱們能夠經過redis-check-aof工具來幫助咱們解決數據 一致性的問題。
• AOF 日誌文件即便過大的時候，出現後臺重寫操做，也不會影響客戶端的讀寫。由於在rewrite log 的時候，會對其中的指令進行壓縮，建立出一份須要恢復數據的最小日誌出來。在建立新日誌文件的時候，老的日誌文件仍是照常寫入。當新的 merge 後的日誌文件 ready 的時候，再交換新老日誌文件便可。 所以在進行rewrite切換時能夠更好的保證數據安全性。
• AOF以一個格式清晰、易於理解的日誌文件用於記錄全部的修改操做， 很是適合作災難性的誤刪除的緊急恢復。 好比有人不當心用flushall命令清空了全部數據，只要這個時候後臺rewrite尚未發生，那麼就能夠當即拷貝 AOF 文件，將最後一條flushall命令給刪了，而後再將該aof文件放回去，就能夠經過恢復機制，自動恢復全部數據。
• 對於相同數量的數據集而言，AOF文件一般要大於RDB文件。RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
• AOF 開啓後，支持的寫 QPS 會比 RDB 支持的寫 QPS 低， 由於 AOF 通常會配置成每秒 fsync 一第二天志文件。
• 類 似 AOF 這種較爲複雜的基於命令日誌 / merge / 回放的方式，比基於 RDB 每次持久化一份完整的數據快照文件的方式，更加脆弱一些，容易有 bug。

如何選擇？

---

 

RDB和AOF如何選擇？

•  不要僅僅使用 RDB，由於那樣會致使你丟失不少數據；
• 也不要僅僅使用 AOF，由於那樣有兩個問題：第一，你經過 AOF 作冷備，沒有 RDB 作冷備來的恢復速度更快；第二，RDB 每次簡單粗暴生成數據快照，更加健壯，能夠避免 AOF 這種複雜的備份和恢復機制的 bug；
• redis 支持同時開啓開啓兩種持久化方式，咱們能夠綜合使用 AOF 和 RDB 兩種持久化機制，用 AOF 來保證數據不丟失，做爲數據恢復的第一選擇; 用 RDB 來作不一樣程度的冷備，在 AOF 文件都丟失或損壞不可用的時候，還可使用 RDB 來進行快速的數據恢復。