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

2019 年 10 月 14 日
筆記

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 來進行快速的數據恢復。