簡介

背景

Redis是一種記憶體資料庫，在斷電時資料可能會丟失，比如你redis整個掛了，然后redis不可用了，如果沒有持久化的話，redis就會丟失所有的資料，如果通過持久化將資料搞一份兒到磁盤上去，然后再定期同步到一些云存盤服務上去，那么就可以保證一些資料不丟失，保證資料的可靠性，

持久化方式

Redis中為了保證在系統宕機(類似行程被殺死)情況下，能更快的進行故障恢復，設計了兩種資料持久化方案，分別為rdb和aof方式，

Rdb方式持久化

概述

Rdb方式是通過手動(save-阻塞式，bgsave-異步)或周期性方式保存redis中key/value的一種機制,Rdb方式一般為redis的默認資料持久化方式.系統啟動時會自動開啟這種方式的持久化機制，

RDB方式配置

RDB方式的持久化是默認開啟的，也可按規則自己配置，例如，打開redis.conf檔案，例如

# 這里表示每隔60s，如果有超過1000個key發生了變更，那么就生成一個新的dump.rdb檔案，就是當前redis記憶體中完整的資料快照，這個操作也被稱之為snapshotting(快照)，

save 60 1000

# 持久化 rdb檔案遇到問題時，主行程是否接受寫入，yes 表示停止寫入，如果是no 表示redis繼續提供服務，
stop-writes-on-bgsave-error yes
    
# 在進行快照鏡像時,是否進行壓縮，yes:壓縮，但是需要一些cpu的消耗，no:不壓縮，需要更多的磁盤空間，
rdbcompression yes
# 一個CRC64的校驗就被放在了檔案末尾，當存盤或者加載rbd檔案的時候會有一個10%左右的性能下降，為了達到性能的最大化，你可以關掉這個配置項，
rdbchecksum yes

# 快照的檔案名
dbfilename dump.rdb

# 存放快照的目錄
dir /var/lib/redis

Rdb方式持久化實踐

試驗一

在redis中保存幾條資料，然后執行shutdown關閉redis,然后再重啟redis，看看剛才插入的資料是否還在？假如資料還在，為什么？
因為,通過redis-cli shutdown這種方式去停掉redis，其實是一種安全退出的模式，redis在退出的時候會將記憶體中的資料立即生成一份完整的rdb快照,例如

127.0.0.1:6379> set phone 11111111
OK
127.0.0.1:6379> shutdown   #默認也會進行持久化
[root@centos7964 ~]#  docker start redis01
[root@centos7964 ~]# docker exec -it redis01 redis-cli
127.0.0.1:6379> keys *
1) "pone"

試驗二

在redis中再保存幾條新的資料，用kill -9粗暴殺死redis行程，模擬redis故障例外退出，導致記憶體資料丟失的場景？
這次就發現，redis行程例外被殺掉，幾條最新的資料就丟失了，例如:

首先,打開第一個客戶端,先清除redis記憶體和磁盤對應的資料

[root@centos7964 data]# docker exec -it redis01 redis-cli
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> exit
[root@centos7964 data]# ls
dump.rdb
[root@centos7964 data]# rm –f dump.rdb
[root@centos7964 data]# ls

然后,打開并登錄第二個客戶端,并向redis存盤一些資料,例如

[root@centos7964 ~]# docker exec -it redis01 redis-cli
127.0.0.1:6379> set one mybatis
OK
127.0.0.1:6379> set two spring
OK
127.0.0.1:6379> keys *
1) "one"
2) "two"

接下來,再次回到第一個客戶端,殺掉redis行程,例如

[root@centos7964 data]# ps -ef | grep redis
polkitd    6995   6974  0 14:44 ?        00:00:00 redis-server *:6379
root       7064   6974  0 14:44 pts/0    00:00:00 redis-cli
root       7111   6467  0 14:47 pts/1    00:00:00 docker exec -it redis01 redis-cli
root       7130   6974  0 14:47 pts/1    00:00:00 redis-cli
root       7278   7180  0 14:51 pts/0    00:00:00 grep --color=auto redis
[root@centos7964 data]# kill -9 6995
[root@centos7964 data]# docker start redis01

最后,打開第一個客戶端,登錄redis,檢查key是否還存在.

[root@centos7964 ~]# docker exec -it redis01 redis-cli
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379>
[root@centos7964 ~]#

試驗三

手動呼叫save(同步保存)或者bgsave(異步保存)執行rdb快照生成.然后殺掉redis行程,再重啟檢測是否還有剛剛保存的資料.

127.0.0.1:6379> set id 100
OK
127.0.0.1:6379> set name jack
OK
127.0.0.1:6379> save  #阻塞式持久化
OK
127.0.0.1:6379> set address beijing
OK
127.0.0.1:6379> bgsave  #異步方式持久化
Background saving started

小節面試分析

Redis中的save和bgsave有什么不同？

• Redis Save 命令執行一個同步保存操作，將當前 Redis 實體的所有資料快照(snapshot)以 RDB 檔案的形式保存到硬碟，
• BGSAVE 命令執行之后立即回傳 OK ，然后 Redis fork 出一個新子行程，原來的 Redis 行程(父行程)繼續處理客戶端請求，而子行程則負責將資料保存到磁盤，然后退出，

RDB持久化機制有哪些優點？

第一：RDB會生成多個資料檔案，每個資料檔案都代表了某一個時刻中redis的資料，這種多個資料檔案的方式，非常適合做冷備，可以將這種完整的資料檔案發送到一些遠程云服務上去，在國內可以是阿里云的ODPS分布式存盤上，以預定好的備份策略來定期備份redis中的資料.
第二：RDB對redis對外提供的讀寫服務，影響非常小，可以讓redis保持高性能，因為redis主行程只需要fork一個子行程，讓子行程執行磁盤IO操作來進行RDB持久化即可，
第三：相對于AOF持久化機制來說，直接基于RDB資料檔案來重啟和恢復redis行程，更加快速，

RDB持久化機制有哪些缺點？

假如redis故障時，要盡可能少的丟失資料，那么RDB方式不太好，它都是每隔5分鐘或更長時間做一次快照，這個時候一旦redis行程宕機，那么會丟失最近幾分鐘的資料，

Aof方式資料持久化

概述

Aof方式是通過記錄寫操作日志的方式,記錄redis資料的一種持久化機制,這個機制默認是關閉的，

AOF方式配置

# 是否開啟AOF，默認關閉
appendonly yes
# 指定 AOF 檔案名
appendfilename appendonly.aof
# Redis支持三種刷寫模式：
# appendfsync always #每次收到寫命令就立即強制寫入磁盤，類似MySQL的sync_binlog=1,是最安全的，但該模式下速度也是最慢的，一般不推薦使用，
appendfsync everysec #每秒鐘強制寫入磁盤一次，在性能和持久化方面做平衡，推薦該方式，
# appendfsync no     #完全依賴OS的寫入，一般為30秒左右一次，性能最好但是持久化最沒有保證，不推薦，
    
#在日志重寫時，不進行命令追加操作，而只是將其放在緩沖區里，避免與命令的追加造成DISK IO上的沖突，
#設定為yes表示rewrite期間對新寫操作不fsync,暫時存在記憶體中,等rewrite完成后再寫入，默認為no，建議yes
no-appendfsync-on-rewrite yes
#當前AOF檔案大小是上次日志重寫得到AOF檔案大小的二倍時，自動啟動新的日志重寫程序，
auto-aof-rewrite-percentage 100
#當前AOF檔案啟動新的日志重寫程序的最小值，避免剛剛啟動Reids時由于檔案尺寸較小導致頻繁的重寫，
auto-aof-rewrite-min-size 64mb

AOF方式持久化實踐

第一：先僅僅打開RDB，寫入一些資料，然后kill -9殺掉redis行程，接著重啟redis，發現資料沒了，因為RDB快斬訓沒生成.
第二：打開AOF的開關，啟用AOF持久化
第三：寫入一些資料，觀察AOF檔案（appendonly.aof）中的日志內容
第四：kill -9殺掉redis行程，重新啟動redis行程，發現資料被恢復回來了，就是從AOF檔案中恢復回來的，redis行程啟動的時候，直接就會從appendonly.aof中加載所有的日志，把記憶體中的資料恢復回來，

小節面試分析

如何理解AOF方式中的rewrite操作？

redis中的資料其實有限的，很多資料可能會自動過期，可能會被用戶洗掉，可能會被redis用快取清除的演算法清理掉，也就是說redis中的資料會不斷淘汰掉舊的，只有一部分常用的資料會被自動保留在redis記憶體中，所以可能很多之前的已經被清理掉的資料，對應的寫日志還停留在AOF中，AOF日志檔案就一個，會不斷的膨脹，到很大很大，
所以,AOF會自動在后臺每隔一定時間做rewrite操作，比如日志里已經存放了針對100w資料的寫日志了; redis記憶體只剩下10萬; 基于記憶體中當前的10萬資料構建一套最新的日志，到AOF中; 覆寫之前的老日志; 確保AOF日志檔案不會過大，保持跟redis記憶體資料量一致.

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這種基于命令日志方式，比基于RDB每次持久化一份完整的資料快照檔案的方式，更加脆弱一些，容易有bug，不過AOF為了避免rewrite程序導致的bug，因此每次rewrite并不是基于舊的指令日志進行merge的，而是基于當時記憶體中的資料進行指令的重新構建，這樣健壯性會好很多，

如何選擇redis的持久化方式？

第一：不要僅僅使用RDB，因為那樣會導致你丟失很多資料，
第二：也不要僅僅使用AOF，因為AOF做冷備沒有RDB做冷備進行資料恢復的速度快,并且RDB簡單粗暴的資料快照方式更加健壯，
第三：綜合使用AOF和RDB兩種持久化機制，用AOF來保證資料不丟失，作為資料恢復的第一選擇; 用RDB來做不同程度的冷備，

總結（Summary）

本章主要是對redis中的持久化方式，持久化機制，應用實踐進行基本分析與講解，重點是如何在生產環境下應用，