摘要：命令和創(chuàng)建快照原理十分相似，所以文件重寫也需要用到子進(jìn)程，這樣會(huì)導(dǎo)致性能問題和內(nèi)存占用問題，和快照持久化一樣。

歷史文章推薦：

一只準(zhǔn)程序猿的嘮叨

可能是最漂亮的Spring事務(wù)管理詳解

Java多線程學(xué)習(xí)（八）線程池與Executor 框架

面試中關(guān)于Redis的問題看這篇就夠了

非常感謝《redis實(shí)戰(zhàn)》真本書，本文大多內(nèi)容也參考了書中的內(nèi)容。非常推薦大家看一下《redis實(shí)戰(zhàn)》這本書，感覺書中的很多理論性東西還是很不錯(cuò)的。

為什么本文的名字要加上春夏秋冬又一春，哈哈 ，這是一部韓國(guó)的電影，我感覺電影不錯(cuò)，所以就用在文章名字上了，沒有什么特別的含義，然后下面的有些配圖也是電影相關(guān)鏡頭。

很多時(shí)候我們需要持久化數(shù)據(jù)也就是將內(nèi)存中的數(shù)據(jù)寫入到硬盤里面，大部分原因是為了之后重用數(shù)據(jù)（比如重啟機(jī)器、機(jī)器故障之后回復(fù)數(shù)據(jù)），或者是為了防止系統(tǒng)故障而將數(shù)據(jù)備份到一個(gè)遠(yuǎn)程位置。

Redis不同于Memcached的很重一點(diǎn)就是，Redis支持持久化，而且支持兩種不同的持久化操作。Redis的一種持久化方式叫快照（snapshotting，RDB）,另一種方式是只追加文件（append-only file,AOF）.這兩種方法各有千秋，下面我會(huì)詳細(xì)這兩種持久化方法是什么，怎么用，如何選擇適合自己的持久化方法。

Redis可以通過創(chuàng)建快照來(lái)獲得存儲(chǔ)在內(nèi)存里面的數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)上的副本。Redis創(chuàng)建快照之后，可以對(duì)快照進(jìn)行備份，可以將快照復(fù)制到其他服務(wù)器從而創(chuàng)建具有相同數(shù)據(jù)的服務(wù)器副本（Redis主從結(jié)構(gòu)，主要用來(lái)提高Redis性能），還可以將快照留在原地以便重啟服務(wù)器的時(shí)候使用。

快照持久化是Redis默認(rèn)采用的持久化方式，在redis.conf配置文件中默認(rèn)有此下配置：

save 900 1              #在900秒(15分鐘)之后，如果至少有1個(gè)key發(fā)生變化，Redis就會(huì)自動(dòng)觸發(fā)BGSAVE命令創(chuàng)建快照。

save 300 10            #在300秒(5分鐘)之后，如果至少有10個(gè)key發(fā)生變化，Redis就會(huì)自動(dòng)觸發(fā)BGSAVE命令創(chuàng)建快照。

save 60 10000        #在60秒(1分鐘)之后，如果至少有10000個(gè)key發(fā)生變化，Redis就會(huì)自動(dòng)觸發(fā)BGSAVE命令創(chuàng)建快照。

根據(jù)配置，快照將被寫入dbfilename選項(xiàng)指定的文件里面，并存儲(chǔ)在dir選項(xiàng)指定的路徑上面。如果在新的快照文件創(chuàng)建完畢之前，Redis、系統(tǒng)或者硬件這三者中的任意一個(gè)崩潰了，那么Redis將丟失最近一次創(chuàng)建快照寫入的所有數(shù)據(jù)。

舉個(gè)例子：假設(shè)Redis的上一個(gè)快照是2：35開始創(chuàng)建的，并且已經(jīng)創(chuàng)建成功。下午3：06時(shí)，Redis又開始創(chuàng)建新的快照，并且在下午3：08快照創(chuàng)建完畢之前，有35個(gè)鍵進(jìn)行了更新。如果在下午3：06到3：08期間，系統(tǒng)發(fā)生了崩潰，導(dǎo)致Redis無(wú)法完成新快照的創(chuàng)建工作，那么Redis將丟失下午2：35之后寫入的所有數(shù)據(jù)。另一方面，如果系統(tǒng)恰好在新的快照文件創(chuàng)建完畢之后崩潰，那么Redis將丟失35個(gè)鍵的更新數(shù)據(jù)。

創(chuàng)建快照的辦法有如下幾種：

BGSAVE命令： 客戶端向Redis發(fā)送 BGSAVE命令 來(lái)創(chuàng)建一個(gè)快照。對(duì)于支持BGSAVE命令的平臺(tái)來(lái)說（基本上所有平臺(tái)支持，除了Windows平臺(tái)），Redis會(huì)調(diào)用fork來(lái)創(chuàng)建一個(gè)子進(jìn)程，然后子進(jìn)程負(fù)責(zé)將快照寫入硬盤，而父進(jìn)程則繼續(xù)處理命令請(qǐng)求。

SAVE命令： 客戶端還可以向Redis發(fā)送 SAVE命令 來(lái)創(chuàng)建一個(gè)快照，接到SAVE命令的Redis服務(wù)器在快照創(chuàng)建完畢之前不會(huì)再響應(yīng)任何其他命令。SAVE命令不常用，我們通常只會(huì)在沒有足夠內(nèi)存去執(zhí)行BGSAVE命令的情況下，又或者即使等待持久化操作執(zhí)行完畢也無(wú)所謂的情況下，才會(huì)使用這個(gè)命令。

save選項(xiàng)： 如果用戶設(shè)置了save選項(xiàng)（一般會(huì)默認(rèn)設(shè)置），比如 save 60 10000，那么從Redis最近一次創(chuàng)建快照之后開始算起，當(dāng)“60秒之內(nèi)有10000次寫入”這個(gè)條件被滿足時(shí)，Redis就會(huì)自動(dòng)觸發(fā)BGSAVE命令。

SHUTDOWN命令： 當(dāng)Redis通過SHUTDOWN命令接收到關(guān)閉服務(wù)器的請(qǐng)求時(shí)，或者接收到標(biāo)準(zhǔn)TERM信號(hào)時(shí)，會(huì)執(zhí)行一個(gè)SAVE命令，阻塞所有客戶端，不再執(zhí)行客戶端發(fā)送的任何命令，并在SAVE命令執(zhí)行完畢之后關(guān)閉服務(wù)器。

一個(gè)Redis服務(wù)器連接到另一個(gè)Redis服務(wù)器： 當(dāng)一個(gè)Redis服務(wù)器連接到另一個(gè)Redis服務(wù)器，并向?qū)Ψ桨l(fā)送SYNC命令來(lái)開始一次復(fù)制操作的時(shí)候，如果主服務(wù)器目前沒有執(zhí)行BGSAVE操作，或者主服務(wù)器并非剛剛執(zhí)行完BGSAVE操作，那么主服務(wù)器就會(huì)執(zhí)行BGSAVE命令

如果系統(tǒng)真的發(fā)生崩潰，用戶將丟失最近一次生成快照之后更改的所有數(shù)據(jù)。因此，快照持久化只適用于即使丟失一部分?jǐn)?shù)據(jù)也不會(huì)造成一些大問題的應(yīng)用程序。不能接受這個(gè)缺點(diǎn)的話，可以考慮AOF持久化。

與快照持久化相比，AOF持久化 的實(shí)時(shí)性更好，因此已成為主流的持久化方案。默認(rèn)情況下Redis沒有開啟AOF（append only file）方式的持久化，可以通過appendonly參數(shù)開啟：

appendonly yes

開啟AOF持久化后每執(zhí)行一條會(huì)更改Redis中的數(shù)據(jù)的命令，Redis就會(huì)將該命令寫入硬盤中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通過dir參數(shù)設(shè)置的，默認(rèn)的文件名是appendonly.aof。

在Redis的配置文件中存在三種同步方式，它們分別是：

appendfsync always     #每次有數(shù)據(jù)修改發(fā)生時(shí)都會(huì)寫入AOF文件,這樣會(huì)嚴(yán)重降低Redis的速度
appendfsync everysec  #每秒鐘同步一次，顯示地將多個(gè)寫命令同步到硬盤
appendfsync no      #讓操作系統(tǒng)決定何時(shí)進(jìn)行同步

appendfsync always 可以實(shí)現(xiàn)將數(shù)據(jù)丟失減到最少，不過這種方式需要對(duì)硬盤進(jìn)行大量的寫入而且每次只寫入一個(gè)命令，十分影響Redis的速度。另外使用固態(tài)硬盤的用戶謹(jǐn)慎使用appendfsync always選項(xiàng)，因?yàn)檫@會(huì)明顯降低固態(tài)硬盤的使用壽命。

為了兼顧數(shù)據(jù)和寫入性能，用戶可以考慮 appendfsync everysec選項(xiàng) ，讓Redis每秒同步一次AOF文件，Redis性能幾乎沒受到任何影響。而且這樣即使出現(xiàn)系統(tǒng)崩潰，用戶最多只會(huì)丟失一秒之內(nèi)產(chǎn)生的數(shù)據(jù)。當(dāng)硬盤忙于執(zhí)行寫入操作的時(shí)候，Redis還會(huì)優(yōu)雅的放慢自己的速度以便適應(yīng)硬盤的最大寫入速度。

appendfsync no 選項(xiàng)一般不推薦，這種方案會(huì)使Redis丟失不定量的數(shù)據(jù)而且如果用戶的硬盤處理寫入操作的速度不夠的話，那么當(dāng)緩沖區(qū)被等待寫入的數(shù)據(jù)填滿時(shí)，Redis的寫入操作將被阻塞，這會(huì)導(dǎo)致Redis的請(qǐng)求速度變慢。

雖然AOF持久化非常靈活地提供了多種不同的選項(xiàng)來(lái)滿足不同應(yīng)用程序?qū)?shù)據(jù)安全的不同要求，但AOF持久化也有缺陷——AOF文件的體積太大。

AOF雖然在某個(gè)角度可以將數(shù)據(jù)丟失降低到最小而且對(duì)性能影響也很小，但是極端的情況下，體積不斷增大的AOF文件很可能會(huì)用完硬盤空間。另外，如果AOF體積過大，那么還原操作執(zhí)行時(shí)間就可能會(huì)非常長(zhǎng)。

為了解決AOF體積過大的問題，用戶可以向Redis發(fā)送 BGREWRITEAOF命令 ，這個(gè)命令會(huì)通過移除AOF文件中的冗余命令來(lái)重寫（rewrite）AOF文件來(lái)減小AOF文件的體積。BGREWRITEAOF命令和BGSAVE創(chuàng)建快照原理十分相似，所以AOF文件重寫也需要用到子進(jìn)程，這樣會(huì)導(dǎo)致性能問題和內(nèi)存占用問題，和快照持久化一樣。更糟糕的是，如果不加以控制的話，AOF文件的體積可能會(huì)比快照文件大好幾倍。

文件重寫流程：

和快照持久化可以通過設(shè)置save選項(xiàng)來(lái)自動(dòng)執(zhí)行BGSAVE一樣，AOF持久化也可以通過設(shè)置

auto-aof-rewrite-percentage

選項(xiàng)和

auto-aof-rewrite-min-size

選項(xiàng)自動(dòng)執(zhí)行BGREWRITEAOF命令。舉例：假設(shè)用戶對(duì)Redis設(shè)置了如下配置選項(xiàng)并且啟用了AOF持久化。那么當(dāng)AOF文件體積大于64mb，并且AOF的體積比上一次重寫之后的體積大了至少一倍（100%）的時(shí)候，Redis將執(zhí)行BGREWRITEAOF命令。

auto-aof-rewrite-percentage 100  
auto-aof-rewrite-min-size 64mb

無(wú)論是AOF持久化還是快照持久化，將數(shù)據(jù)持久化到硬盤上都是非常有必要的，但除了進(jìn)行持久化外，用戶還必須對(duì)持久化得到的文件進(jìn)行備份（最好是備份到不同的地方），這樣才能盡量避免數(shù)據(jù)丟失事故發(fā)生。如果條件允許的話，最好能將快照文件和重新重寫的AOF文件備份到不同的服務(wù)器上面。

隨著負(fù)載量的上升，或者數(shù)據(jù)的完整性變得 越來(lái)越重要時(shí)，用戶可能需要使用到復(fù)制特性。

參考：

《Redis實(shí)戰(zhàn)》

深入學(xué)習(xí)Redis（2）：持久化

歡迎關(guān)注我的微信公眾號(hào):"Java面試通關(guān)手冊(cè)"（一個(gè)有溫度的微信公眾號(hào)，無(wú)廣告，單純技術(shù)分享，期待與你共同進(jìn)步~~~堅(jiān)持原創(chuàng)，分享美文，分享各種Java學(xué)習(xí)資源。)

最后，就是使用阿里云服務(wù)器一段時(shí)間后，感覺阿里云真的很不錯(cuò)，就申請(qǐng)做了阿里云大使，然后這是我的優(yōu)惠券地址.