在這篇文章轧葛，我們繼續(xù)有關(guān)Redis方面知識的學(xué)習(xí)搂抒，一起了解一下其中一個非常重要的內(nèi)容：Redis的持久化機(jī)制艇搀。
什么是Redis持久化?
Redis作為一個鍵值對內(nèi)存數(shù)據(jù)庫(NoSQL)，數(shù)據(jù)都存儲在內(nèi)存當(dāng)中求晶，在處理客戶端請求時焰雕，所有操作都在內(nèi)存當(dāng)中進(jìn)行，如下所示：
這樣做有什么問題呢芳杏？
其實矩屁，只要稍微有點(diǎn)計算機(jī)基礎(chǔ)知識的人都知道，存儲在內(nèi)存當(dāng)中的數(shù)據(jù)蚜锨，只要服務(wù)器關(guān)機(jī)(各種原因引起的)档插，內(nèi)存中的數(shù)據(jù)就會消失了，不僅服務(wù)器關(guān)機(jī)會造成數(shù)據(jù)消失亚再，Redis服務(wù)器守護(hù)進(jìn)程退出郭膛，內(nèi)存中的數(shù)據(jù)也一樣會消失。
對于只把Redis當(dāng)緩存來用的項目來說氛悬，數(shù)據(jù)消失或許問題不大则剃，重新從數(shù)據(jù)源把數(shù)據(jù)加載進(jìn)來就可以了，但如果直接把用戶提交的業(yè)務(wù)數(shù)據(jù)存儲在Redis當(dāng)中如捅，把Redis作為數(shù)據(jù)庫來使用棍现，在其放存儲重要業(yè)務(wù)數(shù)據(jù)，那么Redis的內(nèi)存數(shù)據(jù)丟失所造成的影響也許是毀滅性镜遣。
為了避免內(nèi)存中數(shù)據(jù)丟失己肮，Redis提供了對持久化的支持，我們可以選擇不同的方式將數(shù)據(jù)從內(nèi)存中保存到硬盤當(dāng)中悲关，使數(shù)據(jù)可以持久化保存谎僻。
Redis提供了RDB和AOF兩種不同的數(shù)據(jù)持久化方式，下面我們就來詳細(xì)介紹一下這種不同的持久化方式吧寓辱。
RDB
RDB是一種快照存儲持久化方式艘绍，具體就是將Redis某一時刻的內(nèi)存數(shù)據(jù)保存到硬盤的文件當(dāng)中，默認(rèn)保存的文件名為dump.rdb秫筏，而在Redis服務(wù)器啟動時诱鞠，會重新加載dump.rdb文件的數(shù)據(jù)到內(nèi)存當(dāng)中恢復(fù)數(shù)據(jù)。
開啟RDB持久化方式
開啟RDB持久化方式很簡單这敬，客戶端可以通過向Redis服務(wù)器發(fā)送save或bgsave命令讓服務(wù)器生成rdb文件航夺，或者通過服務(wù)器配置文件指定觸發(fā)RDB條件。
1. save命令
save命令是一個同步操作崔涂。
# 同步數(shù)據(jù)到磁盤上
> save
當(dāng)客戶端向服務(wù)器發(fā)送save命令請求進(jìn)行持久化時阳掐，服務(wù)器會阻塞save命令之后的其他客戶端的請求，直到數(shù)據(jù)同步完成。
如果數(shù)據(jù)量太大锚烦，同步數(shù)據(jù)會執(zhí)行很久觅闽，而這期間Redis服務(wù)器也無法接收其他請求，所以涮俄，最好不要在生產(chǎn)環(huán)境使用save命令蛉拙。
2. bgsave
與save命令不同，bgsave命令是一個異步操作彻亲。
# 異步保存數(shù)據(jù)集到磁盤上
> bgsave
當(dāng)客戶端發(fā)服務(wù)發(fā)出bgsave命令時孕锄，Redis服務(wù)器主進(jìn)程會forks一個子進(jìn)程來數(shù)據(jù)同步問題，在將數(shù)據(jù)保存到rdb文件之后苞尝，子進(jìn)程會退出畸肆。
所以，與save命令相比宙址，Redis服務(wù)器在處理bgsave采用子線程進(jìn)行IO寫入轴脐，而主進(jìn)程仍然可以接收其他請求，但forks子進(jìn)程是同步的抡砂，所以forks子進(jìn)程時大咱，一樣不能接收其他請求，這意味著注益，如果forks一個子進(jìn)程花費(fèi)的時間太久(一般是很快的)碴巾，bgsave命令仍然有阻塞其他客戶的請求的情況發(fā)生。
3. 服務(wù)器配置自動觸發(fā)
除了通過客戶端發(fā)送命令外丑搔，還有一種方式厦瓢，就是在Redis配置文件中的save指定到達(dá)觸發(fā)RDB持久化的條件，比如【多少秒內(nèi)至少達(dá)到多少寫操作】就開啟RDB數(shù)據(jù)同步啤月。
例如我們可以在配置文件redis.conf指定如下的選項：
# 900s內(nèi)至少達(dá)到一條寫命令
save 900 1
# 300s內(nèi)至少達(dá)至10條寫命令
save 300 10
# 60s內(nèi)至少達(dá)到10000條寫命令
save 60 10000
之后在啟動服務(wù)器時加載配置文件煮仇。
# 啟動服務(wù)器加載配置文件
redis-server redis.conf
這種通過服務(wù)器配置文件觸發(fā)RDB的方式，與bgsave命令類似顽冶，達(dá)到觸發(fā)條件時欺抗，會forks一個子進(jìn)程進(jìn)行數(shù)據(jù)同步售碳，不過最好不要通過這方式來觸發(fā)RDB持久化强重，因為設(shè)置觸發(fā)的時間太短，則容易頻繁寫入rdb文件贸人，影響服務(wù)器性能间景，時間設(shè)置太長則會造成數(shù)據(jù)丟失。
rdb文件
前面介紹了三種讓服務(wù)器生成rdb文件的方式艺智，無論是由主進(jìn)程生成還是子進(jìn)程來生成倘要，其過程如下：
生成臨時rdb文件，并寫入數(shù)據(jù)。
完成數(shù)據(jù)寫入封拧，用臨時文代替代正式rdb文件志鹃。
刪除原來的db文件。
RDB默認(rèn)生成的文件名為dump.rdb泽西，當(dāng)然曹铃，我可以通過配置文件進(jìn)行更加詳細(xì)配置，比如在單機(jī)下啟動多個redis服務(wù)器進(jìn)程時捧杉，可以通過端口號配置不同的rdb名稱陕见，如下所示：
# 是否壓縮rdb文件
rdbcompression yes
# rdb文件的名稱
dbfilename redis-6379.rdb
# rdb文件保存目錄
dir ~/redis/
RDB的幾個優(yōu)點(diǎn)
與AOF方式相比，通過rdb文件恢復(fù)數(shù)據(jù)比較快味抖。
rdb文件非常緊湊评甜，適合于數(shù)據(jù)備份。
通過RDB進(jìn)行數(shù)據(jù)備仔涩，由于使用子進(jìn)程生成忍坷，所以對Redis服務(wù)器性能影響較小。
RDB的幾個缺點(diǎn)
如果服務(wù)器宕機(jī)的話熔脂，采用RDB的方式會造成某個時段內(nèi)數(shù)據(jù)的丟失承匣，比如我們設(shè)置10分鐘同步一次或5分鐘達(dá)到1000次寫入就同步一次，那么如果還沒達(dá)到觸發(fā)條件服務(wù)器就死機(jī)了锤悄，那么這個時間段的數(shù)據(jù)會丟失韧骗。
使用save命令會造成服務(wù)器阻塞，直接數(shù)據(jù)同步完成才能接收后續(xù)請求零聚。
使用bgsave命令在forks子進(jìn)程時袍暴，如果數(shù)據(jù)量太大，forks的過程也會發(fā)生阻塞隶症，另外政模，forks子進(jìn)程會耗費(fèi)內(nèi)存。
AOF
聊完了RDB蚂会，來聊聊Redis的另外一個持久化方式：AOF(Append-only file)淋样。與RDB存儲某個時刻的快照不同，AOF持久化方式會記錄客戶端對服務(wù)器的每一次寫操作命令胁住，并將這些寫操作以Redis協(xié)議追加保存到以后綴為aof文件末尾趁猴，在Redis服務(wù)器重啟時，會加載并運(yùn)行aof文件的命令彪见，以達(dá)到恢復(fù)數(shù)據(jù)的目的儡司。
開啟AOF持久化方式
Redis默認(rèn)不開啟AOF持久化方式，我們可以在配置文件中開啟并進(jìn)行更加詳細(xì)的配置余指，如下面的redis.conf文件：
# 開啟aof機(jī)制
appendonly yes
# aof文件名
appendfilename "appendonly.aof"
# 寫入策略,always表示每個寫操作都保存到aof文件中,也可以是everysec或no
appendfsync always
# 默認(rèn)不重寫aof文件
no-appendfsync-on-rewrite no
# 保存目錄
dir ~/redis/
三種寫入策略
在上面的配置文件中捕犬，我們可以通過appendfsync選項指定寫入策略，有三個選項。
appendfsync always
# appendfsync everysec
# appendfsync no
1. always
客戶端的每一個寫操作都保存到aof文件當(dāng)碉碉，這種策略很安全柴钻，但是每個寫請注都有IO操作摔吏，所以也很慢饺饭。
2. everysec
appendfsync的默認(rèn)寫入策略，每秒寫入一次aof文件宝惰，因此足丢，最多可能會丟失1s的數(shù)據(jù)粱腻。
3. no
Redis服務(wù)器不負(fù)責(zé)寫入aof，而是交由操作系統(tǒng)來處理什么時候?qū)懭隺of文件斩跌。更快绍些，但也是最不安全的選擇，不推薦使用耀鸦。
AOF文件重寫
AOF將客戶端的每一個寫操作都追加到aof文件末尾柬批，比如對一個key多次執(zhí)行incr命令，這時候袖订，aof保存每一次命令到aof文件中氮帐，aof文件會變得非常大。
incr num 1
incr num 2
incr num 3
incr num 4
incr num 5
incr num 6
...
incr num 100000
aof文件太大洛姑，加載aof文件恢復(fù)數(shù)據(jù)時上沐，就會非常慢，為了解決這個問題楞艾，Redis支持aof文件重寫参咙，通過重寫aof，可以生成一個恢復(fù)當(dāng)前數(shù)據(jù)的最少命令集硫眯，比如上面的例子中那么多條命令蕴侧，可以重寫為：
set num 100000
aof文件是一個二進(jìn)制文件，并不是像上面的例子一樣两入，直接保存每個命令净宵，而使用Redis自己的格式，上面只是方便演示裹纳。
兩種重寫方式
通過在redis.conf配置文件中的選項no-appendfsync-on-rewrite可以設(shè)置是否開啟重寫择葡，這種方式會在每次fsync時都重寫，影響服務(wù)器性以痊夭，因此默認(rèn)值為no刁岸，不推薦使用脏里。
# 默認(rèn)不重寫aof文件
no-appendfsync-on-rewrite no
客戶端向服務(wù)器發(fā)送bgrewriteaof命令她我，也可以讓服務(wù)器進(jìn)行AOF重寫。
# 讓服務(wù)器異步重寫追加aof文件命令
> bgrewriteaof
重寫aof文件的好處
壓縮aof文件，減少磁盤占用量番舆。
將aof的命令壓縮為最小命令集酝碳，加快了數(shù)據(jù)恢復(fù)的速度。
AOF文件損壞
在寫入aof日志文件時恨狈，如果Redis服務(wù)器宕機(jī)疏哗，則aof日志文件文件會出格式錯誤，在重啟Redis服務(wù)器時禾怠，Redis服務(wù)器會拒絕載入這個aof文件返奉，可以通過以下步驟修復(fù)aof并恢復(fù)數(shù)據(jù)。
備份現(xiàn)在aof文件吗氏，以防萬一芽偏。
使用redis-check-aof命令修復(fù)aof文件，該命令格式如下：
# 修復(fù)aof日志文件
$ redis-check-aof -fix file.aof
重啟Redis服務(wù)器弦讽，加載已經(jīng)修復(fù)的aof文件污尉，恢復(fù)數(shù)據(jù)。
AOF的優(yōu)點(diǎn)
AOF只是追加日志文件往产，因此對服務(wù)器性能影響較小被碗，速度比RDB要快，消耗的內(nèi)存較少仿村。
AOF的缺點(diǎn)
AOF方式生成的日志文件太大锐朴，即使通過AFO重寫，文件體積仍然很大蔼囊。
恢復(fù)數(shù)據(jù)的速度比RDB慢包颁。
選擇RDB還是AOF呢？
通過上面的介紹压真，我們了解了RDB與AOF各自的優(yōu)點(diǎn)與缺點(diǎn)娩嚼，到底要如何選擇呢？
通過下面的表示滴肿，我們可以從幾個方面對比一下RDB與AOF,在應(yīng)用時岳悟，要根本自己的實際需求，選擇RDB或者AOF泼差，其實贵少，如果想要數(shù)據(jù)足夠安全，可以兩種方式都開啟堆缘，但兩種持久化方式同時進(jìn)行IO操作滔灶，會嚴(yán)重影響服務(wù)器性能，因此有時候不得不做出選擇吼肥。
當(dāng)RDB與AOF兩種方式都開啟時录平，Redis會優(yōu)先使用AOF日志來恢復(fù)數(shù)據(jù)麻车，因為AOF保存的文件比RDB文件更完整。
小結(jié)
上面講了一大堆Redis的持久化機(jī)制的知識斗这，其實动猬，如果你只是單純把Redis作為緩存服務(wù)器，那么可以完全不用考慮持久化表箭，但是赁咙，在如今的大多數(shù)服務(wù)器架構(gòu)中，Redis的單單只是扮演一個緩存服務(wù)器的角色免钻，還可以作為數(shù)據(jù)庫彼水，保存我們的業(yè)務(wù)數(shù)據(jù)，此時极舔，我們則需要好好了解有關(guān)Redis持久化策略的區(qū)別與選擇猿涨。
