Redis基礎學習(四)—Redis的持久化

1、概述

     Redis的強大性能很大程度上都是由於數據時存在內存中的，然而當Redis重啓時，全部存儲在內存中的數據將會丟失，因此咱們要將內存中的數據持久化。

Redis支持兩種數據持久化的方式: RDB方式和AOF方式。

(1)RDB方式會根據配置的規則定時的將內存中的數據持久化到硬盤上。

(2)AOF則是將redis執行過的全部寫指令記錄下來，在下次redis從新啓動時，只要把這些寫指令從前到後再重複執行一遍，就能夠實現數據恢復了。

     其實RDB和AOF兩種方式也能夠同時使用，在這種狀況下，若是redis重啓的話，則會優先採用AOF方式來進行數據恢復，這是由於AOF方式的數據恢復完整度更高。

     若是你沒有數據持久化的需求，也徹底能夠關閉RDB和AOF方式，這樣的話，redis將變成一個純內存數據庫，就像memcache同樣。

 

1.RDB方式

     RDB方式的持久化是經過快照的方式完成的。當符合某種規則時，會將內存中的數據所有生成一個副本存儲在硬盤上，Redis會在如下幾種狀況下對數據進行快照:

a: 根據配置的規則自動快照。

b: 用戶執行save、bgsave命令。

c: 執行flushall命令。

d: 執行復制(replication)。

(1)根據配置自動快照

     Redis容許用戶自定義快照條件，當知足條件時自動執行快照，快照規則的配置方式以下:

 

(2)執行save、bgsave命令

     咱們能夠手動執行save、bgsave命令主動進行快照操做。

save: 當執行save命令時，Redis同步進行快照操做，期間會阻塞全部來自客戶端的請求，因此放數據庫數據較多時，應該避免使用該命令；

bgsave: 從命令名字就能看出來，這個命令與save命令的區別就在於該命令的快照操做是在後臺異步進行的，進行快照操做的同時還能處理來自客戶端的請求。執行bgsave命令後Redis會立刻返回OK表示開始進行快照操做，若是想知道快照操做是否已經完成，可使用lasesave命令返回最近一次成功執行快照的時間，返回結果是一個Unix時間戳。

 

(3)執行flushall命令

     執行FLUSHALL命令時，Redis會清除數據庫中的全部數據。

 

(4)執行復制

     當設置了主從模式時，Redis會在複製初始化的時候進行自動快照。

 

2.快照原理

     Redis默認會將快照文件存儲在Redis當前進程的工做目錄的dump.rdb文件中，能夠經過配置文件中的dir和dbfilename兩個參數分別指定快照文件的存儲路徑和文件名。

    

快照執行的過程以下:

(1)Redis使用fork()函數複製一份當前進程(父進程)的副本(子進程)。

(2)父進程繼續處理來自客戶端的請求，子進程開始將內存中的數據寫入硬盤的臨時文件。

(3)當子進程寫完全部的數據後，用該臨時文件替換舊的RDB文件。

     Redis啓動時會自動讀取RDB快照文件，將數據從硬盤載入到內存，根據數量的不一樣，這個過程持續的時間也不盡相同，一般來說，一個記錄1000萬個字符串類型鍵，大小爲1GB的快照文件載入到內存須要20-30秒的時間。

     對於RDB方式，redis會單首創建(fork)一個子進程來進行持久化，而主進程是不會進行任何IO操做的，這樣就確保了redis極高的性能。

     若是須要進行大規模數據的恢復，且對於數據恢復的完整性不是很是敏感，那RDB方式要比AOF方式更加的高效。

     雖然RDB有很多優勢，但它的缺點也是不容忽視的。若是你對數據的完整性很是敏感，那麼RDB方式就不太適合你，由於即便你每5分鐘都持久化一次，當redis故障時，仍然會有近5分鐘的數據丟失。因此，redis還提供了另外一種持久化方式，那就是AOF。

 

3.AOF方式

默認狀況下，Redis沒有開啓AOF(append only file)持久化功能，能夠經過在配置文件中做以下配置啓用：

    

     開啓以後，Redis每執行一條寫命令就會將該命令寫入硬盤中的AOF文件。AOF文件保存路徑和RDB文件路徑是一致的，都是經過dir參數配置，默認文件名是：appendonly.aof，能夠經過配置appendonlyfilename參數修改。

AOF英文是Append Only File，即只容許追加不容許改寫的文件。

     如前面介紹的，AOF方式是將執行過的寫指令記錄下來，在數據恢復時按照從前到後的順序再將指令都執行一遍，就這麼簡單。

     咱們經過配置redis.conf中的appendonly yes就能夠打開AOF功能。若是有寫操做（如SET等），redis就會被追加到AOF文件的末尾。

     默認的AOF持久化策略是每秒鐘fsync一次（fsync是指把緩存中的寫指令記錄到磁盤中），由於在這種狀況下，redis仍然能夠保持很好的處理性能，即便redis故障，也只會丟失最近1秒鐘的數據。

     若是在追加日誌時，剛好遇到磁盤空間滿、inode滿或斷電等狀況致使日誌寫入不完整，也沒有關係，redis提供了redis-check-aof工具，能夠用來進行日誌修復。

     由於採用了追加方式，若是不作任何處理的話，AOF文件會變得愈來愈大，爲此，redis提供了AOF文件重寫（rewrite）機制，即當AOF文件的大小超過所設定的閾值時，redis就會啓動AOF文件的內容壓縮，只保留能夠恢復數據的最小指令集。舉個例子或許更形象，假如咱們調用了100次INCR指令，在AOF文件中就要存儲100條指令，但這明顯是很低效的，徹底能夠把這100條指令合併成一條SET指令，這就是重寫機制的原理。

     在進行AOF重寫時，仍然是採用先寫臨時文件，所有完成後再替換的流程，因此斷電、磁盤滿等問題都不會影響AOF文件的可用性，這點你們能夠放心。

     AOF方式的另外一個好處，咱們經過一個「場景再現」來講明。某同窗在操做redis時，不當心執行了FLUSHALL，致使redis內存中的數據所有被清空了，這是很悲劇的事情。不過這也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件尚未被重寫（rewrite），咱們就能夠用最快的速度暫停redis並編輯AOF文件，將最後一行的FLUSHALL命令刪除，而後重啓redis，就能夠恢復redis的全部數據到FLUSHALL以前的狀態了。是否是很神奇，這就是AOF持久化方式的好處之一。可是若是AOF文件已經被重寫了，那就沒法經過這種方法來恢復數據了。

     雖然優勢多多，但AOF方式也一樣存在缺陷，好比在一樣數據規模的狀況下，AOF文件要比RDB文件的體積大。並且，AOF方式的恢復速度也要慢於RDB方式。

     若是你直接執行BGREWRITEAOF命令，那麼redis會生成一個全新的AOF文件，其中便包括了能夠恢復現有數據的最少的命令集。

     若是運氣比較差，AOF文件出現了被寫壞的狀況，也沒必要過度擔心，redis並不會貿然加載這個有問題的AOF文件，而是報錯退出。這時能夠經過如下步驟來修復出錯的文件：

1.備份被寫壞的AOF文件。 2.運行redis-check-aof –fix進行修復。 3.用diff -u來看下兩個文件的差別，確認問題點。 4.重啓redis，加載修復後的AOF文件。