Redis學習 RDB和AOF兩種持久化介紹以及實現

如下筆記以及實驗皆出自於 中華石杉大佬的視頻教學，我跟着作了實驗，而且把課上的筆記整理了一下。

更多閱讀

• Redis學習 安裝與簡單命令的使用（一）

• 實驗環境搭建

• 更多redis的高可用文檔

redis持久化對於災難恢復的意義

redis有一個持久化的功能，在不少的視頻和資料中都有對持久化的介紹，那麼持久化對於什麼樣場景有着重大的意義呢？

故障發生的時候會怎麼樣

在實際的狀況中有着這樣的狀況，redis忽然掛掉了，進程死了，或者所在的機器沒了，遇到了災難性的故障，由於redis的數據存在內存中

這時候內存中的數據就都沒有了，很重要的緩存數據等等，redis會重啓，重啓以後要費很大的勁去恢復，若是單單把數據放到內存中，

是沒有任何辦法應對一些災難性的故障的，因此redis中的持久化是很重要的。再經過按期備份數據，是能夠恢復一部分數據的。

意義

在企業級的redis集羣架構中，持久化的主要意義就是作災難恢復，數據恢復。

redis中RDB和AOF兩種持久化的介紹

RDB持久化機制，對redis中的數據執行週期性的持久化存儲，並且是完整的數據存儲。 意思是假如每隔一個小時就存儲一份如今redis內存中的所有數據。

AOF機制對每條寫入命令做爲日誌，以append-only的模式寫入一個日誌文件中，在redis重啓的時候，能夠經過回放AOF日誌中的寫入指令來從新構建整個數據集

AOF的機制只對一個AOF日誌文件作寫入（僅追加 append-only）操做，在liunx系統中，中間會通過os cache而後纔會寫入磁盤中，AOF文件存放的是redis的寫入指令。

假如內存中的數據最多存放1G，那麼AOF文件的大小也將會被控制在1G範圍以內，當內存中的數據超過1G的時候，AOF會利用一種緩存淘汰算法（LRU） 將最不經常使用的數據清除,而AOF的rewrite操做會基於redis清除後的內存中的數據從新構造一個更小的AOF文件，而後將舊的文件刪除。

若是redis掛了，服務器上的內存和磁盤上的數據都丟了，能夠從雲服務上拷貝回來以前的數據，放到指定的目錄中，而後從新啓動redis，redis就會自動根據持久化數據文件中的數據，去恢復內存中的數據，繼續對外提供服務 若是同時使用RDB和AOF兩種持久化機制，那麼在redis重啓的時候，會使用AOF來從新構建數據，由於AOF中的數據更加完整。

RDB持久化機制的優勢

• RDB會生成多個數據文件，每一個數據文件都表明了某一個時刻中redis的數據，這種多個數據文件的方式，很是適合作冷備，能夠將這種完整的數據文件發送到一些遠程的安全存儲上去，好比說Amazon的S3雲服務上去， 在國內能夠是阿里雲的ODPS分佈式存儲上，以預約好的備份策略來按期備份redis中的數據

• RDB對redis對外提供的讀寫服務，影響很是小，可讓redis保持高性能，由於redis主進程只須要fork一個子進程，讓子進程執行磁盤IO操做來進行RDB持久化便可

• 相對於AOF持久化機制來講，直接基於RDB數據文件來重啓和恢復redis進程，更加快速

RDB持久化機制的缺點

• 若是想要在redis故障時，儘量少的丟失數據，那麼RDB沒有AOF好。通常來講，RDB數據快照文件，都是每隔5分鐘，或者更長時間生成一次，這個時候就得接受一旦redis進程宕機，那麼會丟失最近5分鐘的數據

• RDB每次在fork子進程來執行RDB快照數據文件生成的時候，若是數據文件特別大，可能會致使對客戶端提供的服務暫停數毫秒，或者甚至數秒，因此通常不要間隔太長時間進行持久化操做。

AOF持久化機制的優勢

• AOF能夠更好的保護數據不丟失，通常AOF會每隔1秒，經過一個後臺線程執行一次fsync操做，最多丟失1秒鐘的數據

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

• AOF日誌文件即便過大的時候，出現後臺重寫操做，也不會影響客戶端的讀寫。由於在rewrite log的時候，會對其中的指導進行壓縮，建立出一份須要恢復數據的最小日誌出來。再建立新日誌文件的時候，老的日誌文件仍是照常寫入。 當新的merge後的日誌文件ready的時候，再交換新老日誌文件便可。

• AOF日誌文件的命令經過很是可讀的方式進行記錄，這個特性很是適合作災難性的誤刪除的緊急恢復。好比某人不當心用flushall命令清空了全部數據，只要這個時候後臺rewrite尚未發生，那麼就能夠當即拷貝AOF文件， 將最後一條flushall命令給刪了，而後再將該AOF文件放回去，就能夠經過恢復機制，自動恢復全部數據

AOF持久化機制的缺點

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

• AOF開啓後，支持的寫QPS會比RDB支持的寫QPS低，由於AOF通常會配置成每秒fsync一第二天志文件，固然，每秒一次fsync，性能也仍是很高的

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

RDB和AOF到底該如何選擇

• 不要僅僅使用RDB，由於那樣會致使你丟失不少數據

• 也不要僅僅使用AOF，由於那樣有兩個問題，第一，你經過AOF作冷備，沒有RDB作冷備，來的恢復速度更快; 第二，RDB每次簡單粗暴生成數據快照，更加健壯，能夠避免AOF這種複雜的備份和恢復機制的bug

• 綜合使用AOF和RDB兩種持久化機制，用AOF來保證數據不丟失，做爲數據恢復的第一選擇; 用RDB來作不一樣程度的冷備，在AOF文件都丟失或損壞不可用的時候，還可使用RDB來進行快速的數據恢復

實現redis持久化

首先實現Redis中的兩種持久化，而且作一些實驗來測試一下兩種持久化是否生效。 AOF持久化，默認是關閉的，默認是打開RDB持久化

配置文件路徑以及後面的全部路徑都是以我本身的爲主。本身的配置文件在哪裏本身就在哪去配就能夠了，下面的全部的路徑都按本身的路徑走，不要盲目按照個人來，除非你按照個人環境來搭建的。

RDB持久化

如何配置RDB持久化機制

redis.conf文件，也就是/etc/redis/6379.conf，去配置持久化，

找到如下相似配置項，在vi中使用/save便可查找指定的save字符，:noh取消高亮

save 60 1000

每隔60s，若是有超過1000個key發生了變動，那麼就生成一個新的dump.rdb文件，就是當前redis內存中完整的數據快照， 這個操做也被稱之爲snapshotting(快照)

也能夠手動調用save或者bgsave命令，同步或異步執行rdb快照生成

save能夠設置多個，就是多個snapshotting檢查點，每到一個檢查點，就會去check一下，是否有指定的key數量發生了變動，若是有， 就生成一個新的dump.rdb文件

RDB持久化機制的工做流程

• redis根據配置本身嘗試去生成rdb快照文件
• fork一個子進程出來
• 子進程嘗試將數據dump到臨時的rdb快照文件中
• 完成rdb快照文件的生成以後，就替換以前的舊的快照文件

dump.rdb，每次生成一個新的快照，都會覆蓋以前的老快照

基於RDB持久化機制的數據恢復實驗

1. 實驗1，首先使用命令 redis-cli 進入redis命令行，保存幾條數據而且重啓redis，看剛剛的數據是否還能查詢的到。

$ redis-cli
$ set k1 v1
$ set k2 v2
$ exit
$ redis-cli SHUTDOWN
# 進入/etc/init.d文件下，使用redis_6379腳本重啓redis
$ cd /etc/init.d
$ ./redis_6379 start
$ redis-cli
$ get k1
"v1"
$ get k2
"v2"
複製代碼

執行以上命令後，能夠看到若是正常退出的redis，數據還在，這是由於經過redis-cli SHUTDOWN這種方式去停掉redis，實際上是一種安全退出的模式， redis在退出的時候會將內存中的數據當即生成一份完整的rdb快照

2. 實驗2，再次在redis中存入幾條數據，此次咱們使用kill -9 暴力殺死redis的進程而且刪除/var/run/redis_6379.pid文件後，看是否還能查詢到數據

$ set k3 v3
$ set k4 v4
$ exit
# 經過ps -ef | grep redis 查看redis的進程
$ ps -ef | grep redis
$ kill -9 62789
# 必定要注意-rf不會提示你刪除，確認好文件後在進行刪除
$ rm -rf /var/run/redis_6379.pid 
# 再次重啓redis
$ cd /etc/init.d
$ ./redis_6379 start
$ redis-cli
$ get k3
(nil)
$ get k4
(nil)
複製代碼

這回保存的新數據都沒有了，是由於尚未到配置的檢查點的時候，出現了意外，這時候就沒法保存rdb文件了，也就丟失了文件，因此這也是RDB的一個缺點。

3. 實驗3，設置間隔短的保存點，重啓redis進程，而且重複實驗2的步驟

$ vi /etc/redis/6379.conf
# 找到save 60 1000相似的設置後添加如下內容保存退出
save 5 1
# 代表每5秒檢查一次，只有有一條插入的數據就生成快照文件rdb，即保存了數據。
$ redis-cli SHUTDOWN
$ /etc/init.d/redis_6379 start
# 重複實驗2的步驟，插入新的數據
複製代碼

實驗3代表RDB的持久化經過咱們手動設置，確實保存了內存中的數據，作到了持久化，可是配置中不建議配置間隔這麼短的檢查點

AOF持久化

AOF持久化，默認是關閉的，默認是打開RDB持久化

如何配置AOF的持久化

在配置文件中找到 appendonly no，設置爲 yes 能夠打開AOF持久化機制，在生產環境裏面，通常來講AOF都是要打開的， 除非你說隨便丟個幾分鐘的數據也無所謂打開AOF持久化機制以後，redis每次接收到一條寫命令，就會寫入日誌文件中，固然是先寫入os cache的， 而後每隔必定時間再fsync一下,並且即便AOF和RDB都開啓了，redis重啓的時候，也是優先經過AOF進行數據恢復的，由於aof數據比較完整

AOF的fsync策略

在redis的配置文件中找到appendfsync everysec有三種策略提供給咱們使用，默認everysec，也是咱們常用的

• always: 每次寫入一條數據，當即將這個數據對應的寫日誌fsync到磁盤上去，性能很是很是差，吞吐量很低; 若是必定要確保說redis裏的數據一條都不丟，那就只能這樣了

• everysec: 每秒將os cache中的數據fsync到磁盤，這個最經常使用的，生產環境通常都這麼配置，性能很高，QPS仍是能夠上萬的

• no:僅僅redis負責將數據寫入os cache就撒手無論了，而後後面os本身會時不時有本身的策略將數據刷入磁盤，不可控了

AOF持久化的數據恢復實驗

1. 實驗1，先僅僅打開RDB，寫入一些數據，而後kill -9殺掉redis進程而且刪除/var/run/redis_6379.pid文件，接着重啓redis，發現數據沒了， 由於RDB快照還沒生成，檢查點不能過短，不然數據就被保存了，這個就不寫命令了，按照上面的RDB實驗便可。

2. 實驗2，打開AOF的開關，啓用AOF的持久化，重啓redis進程，寫入一些數據，觀察AOF文件中的日誌內容，kill -9殺掉redis進程，從新啓動redis進程， 發現數據被恢復回來了，就是從AOF文件中恢復回來的，它們其實就是先寫入os cache的，而後1秒後才fsync到磁盤中，只有fsync到磁盤中了，纔是安全的， 要否則光是在os cache中，機器只要重啓，就什麼都沒了，持久化文件咱們配置了在 /var/redis/6379 中

$ vi /etc/redis/6379.conf
appendonly yes
$ redis-cli SHUTDOWN
$ /etc/init.d/redis_6379 start
$ redis-cli
$ set mykey1 k1
$ set mykey2 k2
$ exit
$ ps -ef | grep redis
$ kill -9 32523
$ rm -rf /var/run/redis_6379.pid
$ /etc/init.d/redis_6379 start
$ redis-cli
$ get mykey1
"k1"
$ get mykey2
"k2" 
複製代碼

實驗證實了，在咱們開啓了AOF後，能夠在乎外發生的時候正常的保存咱們的數據，而RDB由於沒有到達檢查點，並無保存咱們的數據， 因此生產環境中咱們有必要把RDB和AOF兩種持久化都開啓

AOF rewrite操做

redis中的數據其實有限的，不少數據可能會自動過時，可能會被用戶刪除，可能會被redis用緩存清除的算法清理掉，redis中的數據會不斷淘汰掉舊的， 就一部分經常使用的數據會被自動保留在redis內存中

因此可能不少以前的已經被清理掉的數據，對應的寫日誌還停留在AOF中，AOF日誌文件就一個，會不斷的膨脹，到很大很大

因此AOF會自動在後臺每隔必定時間作rewrite操做，好比日誌裏已經存放了針對100w數據的寫日誌了; redis內存只剩下10萬; 基於內存中當前的10萬數據構建一套最新的日誌，到AOF中; 覆蓋以前的老日誌; 確保AOF日誌文件不會過大，保持跟redis內存數據量一致

redis 2.4以前，還須要手動，開發一些腳本，crontab，經過BGREWRITEAOF命令去執行AOF rewrite，可是redis 2.4以後，會自動進行rewrite操做

在redis的配置文件中咱們能夠配置rewrite的策略

• auto-aof-rewrite-percentage 100，這個屬性表明着百分比，增加的百分比到達100%，就是一倍，基於上一次rewrite後文件的大小
• auto-aof-rewrite-min-size 64mb，這個屬性表明增加後的總大小要大於64mb

舉例

好比說上一次AOF rewrite以後，是128mb 而後就會接着128mb繼續寫AOF的日誌，若是發現增加的比例，超過了以前的100%，256mb，就可能會去觸發一次rewrite 可是此時還要去跟min-size，64mb去比較，256mb > 64mb，纔會去觸發rewrite

rewrite工做流程

• redis fork一個子進程
• 子進程基於當前內存中的數據，構建日誌，開始往一個新的臨時的AOF文件中寫入日誌
• redis主進程，接收到client新的寫操做以後，在內存中寫入日誌，同時新的日誌也繼續寫入舊的AOF文件
• 子進程寫完新的日誌文件以後，redis主進程將內存中的新日誌再次追加到新的AOF文件中
• 用新的日誌文件替換掉舊的日誌文件

AOF的破損文件的修復

若是redis在append數據到AOF文件時，機器宕機了，可能會致使AOF文件破損

用redis-check-aof --fix命令來修復破損的AOF文件，這個命令存在於redis的安裝包下src文件中

這個破損文件的修復就是把文件中最後面不完整命令給刪除掉，因此修復也會致使部分數據丟失，可是總好過全部數據所有丟失。

AOF和RDB同時工做

• 若是RDB在執行snapshotting操做，那麼redis不會執行AOF rewrite; 若是redis再執行AOF rewrite，那麼就不會執行RDB snapshotting
• 若是RDB在執行snapshotting，此時用戶執行BGREWRITEAOF命令，那麼等RDB快照生成以後，纔會去執行AOF rewrite
• 同時有RDB snapshot文件和AOF日誌文件，那麼redis重啓的時候，會優先使用AOF進行數據恢復，由於其中的日誌更完整

3. 實驗3，

• 在有rdb的dump和aof的appendonly的同時，rdb裏也有部分數據，aof裏也有部分數據，這個時候其實會發現，rdb的數據不會恢復到內存中
• 咱們模擬讓aof破損，手動刪除aof文件後面的指令變成不完整，而後fix，有一條數據會被fix刪除
• 再次用fix修復後的aof文件去重啓redis，發現數據只剩下一條了

爲何rdb不會恢復到內存中呢，這是由於redis會優先使用aof文件來恢復數據，因此在有aof文件的狀況下，rdb文件是不會被恢復的

總結

整體來講redis在咱們的項目中做爲緩存是很是重要的，爲咱們的mysql等數據庫分擔了不少的壓力，而緩存中的數據又是重中之重，因此redis中的持久化對咱們來說就是必需要會的一點知識

這章節講述瞭如下幾點

• 持久化的意義？

• 對於出現災難性的意外如何應對？

採用持久化和週期性備份來應對災難性的出現

• 兩種持久化的優劣對比

經過上面的兩種的持久化方式來看，數據恢復徹底依賴於底層的磁盤的持久化，若是rdb和aof上都沒有數據，或者這兩個文件都丟了，那麼就真的沒有了 因此在有條件的狀況下，須要對適合作冷備的rdb文件週期性的備份也算是作最後的防線吧