Redis 數據持久化 - RDB 和 AOF 簡單介紹

大綱

1. 爲何要作數據持久化
2. 數據持久化方式（RDB 和 AOF 介紹）
3. RDB 的優缺點
4. AOF 的優缺點

開篇

本文着重講得是 redis 數據持久化，不會去介紹 redis 是什麼，它的特性是什麼，以及安裝方式，使用場景等等。

正文

一. 爲何要作數據持久化

或者咱們還能夠這樣問，什麼狀況下須要作數據持久化？

這須要結合你的業務場景去選擇，固然大部分狀況下，仍是建議你們去作 redis 的數據持久化。

回到原題，咱們作數據持久化的目的是用於故障恢復。

舉個例子：

我最近接手到的 xx 系統，它的數據就直接存在 redis 中，或者說咱們就是把 redis 看成一個持久化數據庫在用，這樣作的緣由就先不說了。根據這樣一個應用場景，假設咱們不作數據持久化，萬一 redis 掛掉，咱們的數據就全沒了，如何跟客戶去交代？？？ ～～～～～ 只能跑路～～～

那麼問題又來了，

1. redis 是怎麼作數據持久化的？

2. 若是咱們作了數據持久化，就能保證一條數據都不會丟了嗎？

請接着往下看 ⬇️️️

二. redis 數據持久化方式

redis 提供了兩種不一樣的持久化方式： RDB 和 AOF。

1. RDB ： 按期保存一份 redis 快照數據到 rdb 文件當中

2. AOF ： 把每個寫操做都記錄在一個日誌文件裏

說的通俗一點就是：

RDB 就是將 redis 的數據保存到一份 rdb 文件中，當咱們啓動 redis 時，redis 會把這個文件的數據 load 到內存中。（這裏先不要管 redis 如何 load 的）

AOF 就是記錄每個 redis 寫指令， 好比 set key value。當須要恢復數據時，redis 會把這個文件的這些寫指令，全都執行一遍。

也許到這裏你仍是會有不少疑問，好比：

1. 寫文件寫到一半，redis 掛掉怎麼辦？ 由於文件不完整了
2. 生成數據快照的時候，若是 redis 掛掉，不也是會丟數據嗎？

這些下面會提到，另外只憑上面講得那些設計，你也應該要想到會出現這樣那樣的問題。

三. RDB 數據持久化的優缺點

優勢

1. RDB 很是適合作冷備，它會把每一個時間點的完整數據保存到一份 rbd 文件中。好比把過去 24 小時的數據按每 1 小時保存一次，或者過去 30 天的數據，每隔一天保存一次
2. RDB對於災難恢復很是有用，它是一個緊湊的文件，能夠傳輸到遠程的安全存儲上
3. RDB對 redis 對外提供的讀寫服務影響很是小，可讓 redis 保持高性能，由於 redis 主進程只須要 fork 一個子進程，讓子進程執行磁盤IO操做來進行RDB持久化便可
4. 相比於 AOF，直接基於 RDB 數據文件來重啓和恢復 redis 進程，會更快

缺點

1. 相比於 AOF， 當 redis 由於某種緣由（好比停電）忽然不能工做後，要想保證數據儘量少丟失，RDB 可能表現的沒有那麼多好
2. RDB 每次在 fork 子進程來執行 RDB 快照數據文件生成的時候，若是數據文件特別大，可能會致使對客戶端提供的服務暫停數毫秒，或者甚至數秒。雖然 AOF 也須要 fork ，可是你能夠調整要重寫日誌的頻率，而無需在持久性上進行權衡（這點能夠先不用理解，後面講 AOF， 再說）

四. AOF 數據持久化的優缺點

優勢

1. AOF 能夠更好的保護數據不丟失，默認策略是 AOF 會每隔1秒，經過一個後臺線程執行一次 fsync 操做。redis進程掛了，最多丟失1秒鐘的數據

三個 fsync 策略

1. no fsync at all
2. fsync every second（默認）
3. fsync at every query

簡單來說，fsync 操做，就是保證操做系統 cache 中的數據寫入磁盤中（多說無益）

2. AOF日誌文件以 append-only 模式寫入，因此沒有任何磁盤尋址的開銷，寫入性能很是高，並且文件不容易破損，即便文件尾部破損，也很容易修復

如何修復？

假如本次操做只是寫入了一半數據就出現了系統崩潰問題，不用擔憂，
在 Redis 下一次啓動以前，咱們能夠經過 redis-check-aof 工具來幫助咱們解決數據一致性的問題。

3. 當 AOF 日誌文件過大的時候，redis 可以在後臺自動進行 rewrite 操做，而且不會影響客戶端的讀寫。

什麼是 rewrite 操做？

AOF採用文件追加方式，爲避免文件會愈來愈大，新增了重寫機制。
 
當AOF文件的大小超過所設定的閾值時，Redis就會啓動AOF文件的內容壓縮，
只保留能夠恢復數據的最小指令集.（可使用命令bgrewriteaof）

重寫原理

AOF文件持續增加而過大時，會 fork 出一條新進程來將文件重寫(也是先寫臨時文件最後再rename)，
重寫 AOF 文件的操做，並不會讀取舊的 AOF 文件（所以不會影響舊的 AOF 文件的寫入）。
而是將整個內存中的數據用命令的方式生成一個新的 AOF 文件.

4. AOF 包含一個格式清晰、易於理解的日誌文件，用於記錄全部的修改操做。所以很是適合作災難性的誤刪除的緊急恢復。好比有人不當心用 FLUSHALL 命令清空了全部數據，只要這個時候後臺 rewrite 尚未發生，那麼就能夠中止服務，將最後一條 FLUSHALL 命令給刪了，而後重啓 redis ，就能夠自動恢復全部數據

缺點

1. 對同一份數據來講，AOF日誌文件一般比 RDB 數據快照文件更大

2. 根據確切的 fsync 策略，AOF 可能比 RDB 慢。可是在將fsync設置爲每秒的狀況下，性能仍然很高，而且在禁用 fsync 的狀況下，即便在高負載下，它也應與RDB同樣快。即便在巨大的寫負載狀況下，RDB 仍然可以提供有關最大延遲的更多保證。

3. 之前 AOF 發生過 bug，就是經過 AOF 記錄的日誌，進行數據恢復的時候，沒有恢復如出一轍的數據出來。因此說，相似 AOF 這種基於命令日誌回放的方式，比基於 RDB 每次持久化一份完整的數據快照文件的方式，更加脆弱一些，容易有bug。不過 AOF 就是爲了不 rewrite 過程致使的 bug，所以每次 rewrite 並非基於舊的指令日誌進行 merge 的，而是基於當時內存中的數據進行指令的從新構建，這樣健壯性會好不少。

總之，AOF 惟一的比較大的缺點，其實就是作數據恢復的時候，會比較慢，還有作冷備，按期的備份，不太方便，可能要本身手寫複雜的腳本去作。

未完待續

看到這裏，你也許期待會有具體的持久化方案，以及持久化配置等等。這些會在後面的文章補充，由於我的不喜歡篇幅過長，講得東西一大堆，消化不了～～～

總結

本文主要說了 redis 數據持久化的兩種方式以及對應的優缺點。固然文章也出現了對部分人來講相對陌生的名詞，好比 fsync，冷備等，以及難以理解，或者很繞的解釋，好比講 AOF 優缺點時，提到的 rewrite 方面的東西。 這都須要多看，多理解，也能夠參考他人的文章。（沒講明白的地方，請見諒）

讀完此文，能夠轉入

Redis 持久化方式 - RDB 和 AOF 配置及 rewrite 機制