Redis 持久化

Redis的強勁性能很大程度上是因爲其將全部數據都存儲在了內存中，爲了使Redis在重啓以後仍能保證數據不丟失，例如：

(1) 將Redis做爲數據庫使用(存儲歷史數據)。

(2) 將Redis做爲緩存服務器使用，若是緩存被穿透後會對性能形成很大影響，全部緩存同時失效會致使緩存雪崩，從而使服務器沒法響應。

這時，咱們但願Redis能將數據從內存中以某種方式同步到硬盤中，當服務器重啓後能夠根據硬盤中的記錄恢復數據，這一過程就是持久化。

 

寫操做的流程

首先咱們來看一下數據庫在進行寫操做時到底作了哪些事，主要有下面五個過程。

1.客戶端向服務端發送寫操做（數據在客戶端的內存中）

2.數據庫服務端接收到寫請求的數據（數據在服務端的內存中）

3.服務端調用write(2) 這個系統調用，將數據往磁盤上寫（數據在系統內存的緩衝區中）

4.操做系統將緩衝區中的數據轉移到磁盤控制器上（數據在磁盤緩存中）

5.磁盤控制器將數據寫到磁盤的物理介質中（數據真正落到磁盤上）

 

寫操做大體有上面5個流程，下面咱們結合上面的5個流程看一下各類級別的故障。

•當數據庫系統故障時，這時候系統內核仍是OK的，那麼此時只要咱們執行完了第3步，那麼數據就是安全的，由於後續操做系統會來完成後面幾步，保證數據最終會落到磁盤上。

•當系統斷電，這時候上面5項中提到的全部緩存都會失效，而且數據庫和操做系統都會中止工做。因此只有當數據在完成第5步後，機器斷電才能保證數據不丟失，在上述四步中的數據都會丟失。

經過上面5步的瞭解，可能咱們會但願搞清下面一些問題：

•數據庫多長時間調用一次write(2)，將數據寫到內核緩衝區

•內核多長時間會將系統緩衝區中的數據寫到磁盤控制器

•磁盤控制器又在何時把緩存中的數據寫到物理介質上

對於第一個問題，一般數據庫層面會進行全面控制。而對第二個問題，操做系統有其默認的策略，可是咱們也能夠經過POSIX API提供的fsync系列命令強制操做系統將數據從內核區寫到磁盤控制器上。對於第三個問題，好像數據庫已經沒法觸及，但實際上，大多數狀況下磁盤緩存是被設置關閉的。或者是隻開啓爲讀緩存，也就是寫操做不會進行緩存，直接寫到磁盤。建議的作法是僅僅當你的磁盤設備有備用電池時纔開啓寫緩存。

所謂數據損壞，就是數據沒法恢復，上面咱們講的都是如何保證數據是確實寫到磁盤上去，可是寫到磁盤上可能並不意味着數據不會損壞。好比咱們可能一次寫請求會進行兩次不一樣的寫操做，當意外發生時，可能會致使一次寫操做安全完成，可是另外一次尚未進行。若是數據庫的數據文件結構組織不合理，可能就會致使數據徹底不能恢復的情況出現。

這裏一般也有三種策略來組織數據，以防止數據文件損壞到沒法恢復的狀況：

1.第一種是最粗糙的處理，就是不經過數據的組織形式保證數據的可恢復性。而是經過配置數據同步備份的方式，在數據文件損壞後經過數據備份來進行恢復。

2.另外一種是在上面基礎上添加一個操做日誌，每次操做時記一下操做的行爲，這樣咱們能夠經過操做日誌來進行數據恢復。由於操做日誌是順序追加的方式寫的，因此不會出現操做日誌也沒法恢復的狀況。

3.更保險的作法是數據庫不進行老數據的修改，只是以追加方式去完成寫操做，這樣數據自己就是一份日誌，這樣就永遠不會出現數據沒法恢復的狀況了。

 

針對上述數據庫寫操做流程及數據庫文件組織策略，咱們來認識Redis的持久化

Redis支持兩種方式的持久化

一種是RDB(快照)方式，一種是AOF(追加文件)方式。能夠單獨使用其中一種或將兩者結合使用。

RDB

RDB方式的持久化是經過快照(snapshotting)完成的，當符合必定條件時Redis會自動將內存中的全部數據生成一份副本並存儲在硬盤上，這個過程即爲「快照」。Redis會在一下幾種狀況下對數據進行快照：

1. 根據配置規則進行自動快照。
2. 用戶執行save或者bgsave命令。
3. 執行flushall命令。
4. 執行復制時。

根據配置規則進行自動快照

你能夠配置保存點，使Redis若是在每N秒後數據發生了M次改變就保存快照文件。例以下面這個保存點配置表示每60秒，若是數據發生了1000次以上的變更，Redis就會自動保存快照文件：

save 60 1000

保存點能夠設置多個，Redis的配置文件就默認設置了3個保存點：

# 格式爲：save <seconds> <changes>

# 能夠設置多個。

save 900 1 #900秒後至少1個key有變更

save 300 10 #300秒後至少10個key有變更

save 60 10000 #60秒後至少10000個key有變更

若是想禁用快照保存的功能，能夠經過註釋掉全部"save"配置達到，或者在最後一條"save"配置後添加以下的配置：

save ""

文件路徑和名稱

默認Redis會把快照文件存儲爲當前目錄下一個名爲dump.rdb的文件。要修改文件的存儲路徑和名稱，能夠經過修改配置文件redis.conf實現：

# RDB文件名，默認爲dump.rdb。

dbfilename dump.rdb

# 文件存放的目錄，AOF文件一樣存放在此目錄下。默認爲當前工做目錄。

dir ./

用戶執行save或者bgsave命令

除了讓Redis進行自動快照外，當進行服務器重啓，手動遷移以及備份的時候咱們也須要手動執行快照操做，redis提供了兩命令：

save 命令執行一個同步保存操做，將當前 Redis 實例的全部數據快照(snapshot)以 RDB 文件的形式保存到硬盤。

通常來講，在生產環境不多執行 SAVE 操做，由於它會阻塞全部客戶端，保存數據庫的任務一般由 BGSAVE 命令異步地執行。

bgsave 命令執行以後當即返回 OK ，而後 Redis fork 出一個新子進程，原來的 Redis 進程(父進程)繼續處理客戶端請求，而子進程則負責將數據保存到磁盤，而後退出。

客戶端能夠經過 LASTSAVE 命令查看最近一次成功執行快照的時間，返回一個unix時間戳。

Flushall命令

flushall清空整個 Redis 服務器的數據(刪除全部數據庫的全部 key )。注意：不管清空數據庫的過程是否觸發了自動快照條件，只要自動快照條件不爲空，redis就會執行一次快照。例如：當定義快照條件爲1秒內修改10000個鍵時進行快照，而是據庫只有一個健，執行flushall也會觸發快照，即便這一過程只有一個健被修改。當沒有定義自動快照條件時，執行fluahall命令不進行快照。

執行復制

當設置了主從模式時，redis會在複製初始化時進行自動快照，即便沒有自定義自動快照條件，而且沒有手動執行過快照操做，也會生成RDB快照文件。

快照原理

1.redis 使用 fork 命令複製一份當前進程（父進程）的副本（子進程）

2.父進程繼續接受並處理客戶端發來的命令，而子進程開始將內存的數據存儲寫入硬盤的臨時文件

3.當子進程寫入完全部數據後調用將臨時文件替換舊的 RDB 文件，到這裏一次快照結束。

RBD 明顯的不足就是一旦數據庫出現崩潰之類的，RDB 裏保存的數據可能不是最新的，從上次 RDB 到 redis 停機這段時間的數據可能會丟失。

 

AOF

Redis 將全部對數據庫進行過寫入的命令（及其參數）記錄到 AOF 文件， 以此達到記錄數據庫狀態的目的爲了方便起見， 咱們稱呼這種記錄過程爲同步。

開啓AOF方式持久化：

appendonly  yes

AOF文件的保存位置和RDB文件位置相同，默認appendonly.aof,可經過appendfilename參數修改：

Appendfilename  appendonly.aof

同步硬盤數據

根據「寫的操做流程」可知，雖然每次執行更改數據庫內存操做時，AOF都會將命令記錄在AOF文件中，可是根據操做系統緩存機制，數據並無真正地寫入硬盤。通常來說啓用AOF的應用沒法容忍這樣的損失，這就須要Redis在寫入AOF文件後主動將系統緩存同步到硬盤中。

Redis 能夠經過appendfsync 參數設同步的時機：

#appendfsync   always   #每次執行都同步

appendfsync   everysec  #每秒執行一次同步，默認

#appendfsync   no      # 不主動同步操做，由操做系統決定(30秒一次)

Redis 容許同時開啓AOF和RDB，重啓時會使用AOF文件恢復數據，由於AOF方式可能丟失的數據更少。

 

 

從上面看出，RDB和AOF操做都是順序IO操做，性能都很高。而同時在經過RDB文件或者AOF日誌進行數據庫恢復的時候，也是順序的讀取數據加載到內存中。因此也不會形成磁盤的隨機讀。

到底選擇什麼呢？下面是來自官方的建議：一般，若是你要想提供很高的數據保障性，那麼建議你同時使用兩種持久化方式。若是你能夠接受災難帶來的幾分鐘的數據丟失，那麼你能夠僅使用RDB。不少用戶僅使用了AOF，可是咱們建議，既然RDB能夠時不時的給數據作個完整的快照，而且提供更快的重啓，因此最好仍是也使用RDB。在數據恢復方面：RDB的啓動時間會更短，緣由有兩個：一是RDB文件中每一條數據只有一條記錄，不會像AOF日誌那樣可能有一條數據的屢次操做記錄。因此每條數據只須要寫一次就好了。另外一個緣由是RDB文件的存儲格式和Redis數據在內存中的編碼格式是一致的，不須要再進行數據編碼工做，因此在CPU消耗上要遠小於AOF日誌的加載