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

歷史文章推薦：

一只準程序猿的嘮叨

可能是最漂亮的Spring事務管理詳解

Java多線程學習（八）線程池與Executor 框架

面試中關于Redis的問題看這篇就夠了

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

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

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

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

Redis可以通過創(chuàng)建快照來獲得存儲在內存里面的數據在某個時間點上的副本。Redis創(chuàng)建快照之后，可以對快照進行備份，可以將快照復制到其他服務器從而創(chuàng)建具有相同數據的服務器副本（Redis主從結構，主要用來提高Redis性能），還可以將快照留在原地以便重啟服務器的時候使用。

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

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

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

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

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

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

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

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

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

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

SHUTDOWN命令： 當Redis通過SHUTDOWN命令接收到關閉服務器的請求時，或者接收到標準TERM信號時，會執(zhí)行一個SAVE命令，阻塞所有客戶端，不再執(zhí)行客戶端發(fā)送的任何命令，并在SAVE命令執(zhí)行完畢之后關閉服務器。

一個Redis服務器連接到另一個Redis服務器： 當一個Redis服務器連接到另一個Redis服務器，并向對方發(fā)送SYNC命令來開始一次復制操作的時候，如果主服務器目前沒有執(zhí)行BGSAVE操作，或者主服務器并非剛剛執(zhí)行完BGSAVE操作，那么主服務器就會執(zhí)行BGSAVE命令

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

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

appendonly yes

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

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

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

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

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

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

雖然AOF持久化非常靈活地提供了多種不同的選項來滿足不同應用程序對數據安全的不同要求，但AOF持久化也有缺陷——AOF文件的體積太大。

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

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

文件重寫流程：

和快照持久化可以通過設置save選項來自動執(zhí)行BGSAVE一樣，AOF持久化也可以通過設置

auto-aof-rewrite-percentage

選項和

auto-aof-rewrite-min-size

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

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

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

隨著負載量的上升，或者數據的完整性變得 越來越重要時，用戶可能需要使用到復制特性。

參考：

《Redis實戰(zhàn)》

深入學習Redis（2）：持久化

歡迎關注我的微信公眾號:"Java面試通關手冊"（一個有溫度的微信公眾號，無廣告，單純技術分享，期待與你共同進步~~~堅持原創(chuàng)，分享美文，分享各種Java學習資源。)

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