解密Redis持久化

參考：http://blog.nosqlfan.com/html/3813.html

本文內容來源於Redis做者博文，Redis做者說，他看到的全部針對Redis的討論中，對Redis持久化的誤解是最大的，因而他寫了一篇長文來對Redis的持久化進行了系統性的論述。文章很是長，也很值得一看，NoSQLFan將主要內容簡述成本文。

什麼是持久化，簡單來說就是將數據放到斷電後數據不會丟失的設備中。也就是咱們一般理解的硬盤上。

寫操做的流程

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

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

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

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

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

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

故障分析

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

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

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

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

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

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

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

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

數據損壞

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

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

• 第一種是最粗糙的處理，就是不經過數據的組織形式保證數據的可恢復性。而是經過配置數據同步備份的方式，在數據文件損壞後經過數據備份來進行恢復。實際上MongoDB在不開啓journaling日誌，經過配置Replica Sets時就是這種狀況。

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

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

RDB快照

下面咱們說一下Redis的第一個持久化策略，RDB快照。Redis支持將當前數據的快照存成一個數據文件的持久化機制。而一個持續寫入的數據庫如何生成快照呢。Redis藉助了fork命令的copy on write機制。在生成快照時，將當前進程fork出一個子進程，而後在子進程中循環全部的數據，將數據寫成爲RDB文件。

咱們能夠經過Redis的save指令來配置RDB快照生成的時機，好比你能夠配置當10分鐘之內有100次寫入就生成快照，也能夠配置當1小時內有1000次寫入就生成快照，也能夠多個規則一塊兒實施。這些規則的定義就在Redis的配置文件中，你也能夠經過Redis的CONFIG SET命令在Redis運行時設置規則，不須要重啓Redis。

Redis的RDB文件不會壞掉，由於其寫操做是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，而後經過原子性rename系統調用將臨時文件重命名爲RDB文件，這樣在任什麼時候候出現故障，Redis的RDB文件都老是可用的。

同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。

可是，咱們能夠很明顯的看到，RDB有他的不足，就是一旦數據庫出現問題，那麼咱們的RDB文件中保存的數據並非全新的，從上次RDB文件生成到Redis停機這段時間的數據所有丟掉了。在某些業務下，這是能夠忍受的，咱們也推薦這些業務使用RDB的方式進行持久化，由於開啓RDB的代價並不高。可是對於另一些對數據安全性要求極高的應用，沒法容忍數據丟失的應用，RDB就無能爲力了，因此Redis引入了另外一個重要的持久化機制：AOF日誌。

AOF日誌

aof日誌的全稱是append only file，從名字上咱們就能看出來，它是一個追加寫入的日誌文件。與通常數據庫的binlog不一樣的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標準命令。好比咱們進行以下實驗，使用Redis2.6版本，在啓動命令參數中設置開啓aof功能：

./redis-server --appendonly yes

而後咱們執行以下的命令：

redis 127.0.0.1:6379> set key1 Hello
OK
redis 127.0.0.1:6379> append key1 " World!"
(integer) 12
redis 127.0.0.1:6379> del key1
(integer) 1
redis 127.0.0.1:6379> del non_existing_key
(integer) 0

這時咱們查看AOF日誌文件，就會獲得以下內容：

$ cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$4
key1
$5
Hello
*3
$6
append
$4
key1
$7
 World!
*2
$3
del
$4
key1

能夠看到，寫操做都生成了一條相應的命令做爲日誌。其中值得注意的是最後一個del命令，它並無被記錄在AOF日誌中，這是由於Redis判斷出這個命令不會對當前數據集作出修改。因此不須要記錄這個無用的寫命令。另外AOF日誌也不是徹底按客戶端的請求來生成日誌的，好比命令INCRBYFLOAT在記AOF日誌時就被記成一條SET記錄，由於浮點數操做可能在不一樣的系統上會不一樣，因此爲了不同一份日誌在不一樣的系統上生成不一樣的數據集，因此這裏只將操做後的結果經過SET來記錄。

AOF重寫

你能夠會想，每一條寫命令都生成一條日誌，那麼AOF文件是否是會很大？答案是確定的，AOF文件會愈來愈大，因此Redis又提供了一個功能，叫作AOF rewrite。其功能就是從新生成一份AOF文件，新的AOF文件中一條記錄的操做只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的屢次操做。其生成過程和RDB相似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程當中，全部的寫操做日誌仍是會寫到原來老的AOF文件中，同時還會記錄在內存緩衝區中。當重完操做完成後，會將全部緩衝區中的日誌一次性寫入到臨時文件中。而後調用原子性的rename命令用新的AOF文件取代老的AOF文件。

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

AOF可靠性設置

AOF是一個寫文件操做，其目的是將操做日誌寫到磁盤上，因此它也一樣會遇到咱們上面說的寫操做的5個流程。那麼寫AOF的操做安全性又有多高呢。實際上這是能夠設置的，在Redis中對AOF調用write(2)寫入後，什麼時候再調用fsync將其寫到磁盤上，經過appendfsync選項來控制，下面appendfsync的三個設置項，安全強度逐漸變強。

appendfsync no

當設置appendfsync爲no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁盤，因此這一切就徹底依賴於操做系統的調試了。對大多數Linux操做系統，是每30秒進行一次fsync，將緩衝區中的數據寫到磁盤上。

appendfsync everysec

當設置appendfsync爲everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩衝區中的數據寫到磁盤。可是當這一次的fsync調用時長超過1秒時。Redis會採起延遲fsync的策略，再等一秒鐘。也就是在兩秒後再進行fsync，這一次的fsync就無論會執行多長時間都會進行。這時候因爲在fsync時文件描述符會被阻塞，因此當前的寫操做就會阻塞。

因此，結論就是，在絕大多數狀況下，Redis會每隔一秒進行一次fsync。在最壞的狀況下，兩秒鐘會進行一次fsync操做。

這一操做在大多數數據庫系統中被稱爲group commit，就是組合屢次寫操做的數據，一次性將日誌寫到磁盤。

appednfsync always

當設置appendfsync爲always時，每一次寫操做都會調用一次fsync，這時數據是最安全的，固然，因爲每次都會執行fsync，因此其性能也會受到影響。

對於pipelining有什麼不一樣

對於pipelining的操做，其具體過程是客戶端一次性發送N個命令，而後等待這N個命令的返回結果被一塊兒返回。經過採用pipilining就意味着放棄了對每個命令的返回值確認。因爲在這種狀況下，N個命令是在同一個執行過程當中執行的。因此當設置appendfsync爲everysec時，可能會有一些誤差，由於這N個命令可能執行時間超過1秒甚至2秒。可是能夠保證的是，最長時間不會超過這N個命令的執行時間和。

與postgreSQL和MySQL的比較

這一塊就很少說了，因爲上面操做系統層面的數據安全已經講了不少，因此其實不一樣的數據庫在實現上都大同小異。總之最後的結論就是，在Redis開啓AOF的狀況下，其單機數據安全性並不比這些成熟的SQL數據庫弱。

數據導入

這些持久化的數據有什麼用，固然是用於重啓後的數據恢復。Redis是一個內存數據庫，不管是RDB仍是AOF，都只是其保證數據恢復的措施。因此Redis在利用RDB和AOF進行恢復的時候，都會讀取RDB或AOF文件，從新加載到內存中。相對於MySQL等數據庫的啓動時間來講，會長不少，由於MySQL原本是不須要將數據加載到內存中的。

可是相對來講，MySQL啓動後提供服務時，其被訪問的熱數據也會慢慢加載到內存中，一般咱們稱之爲預熱，而在預熱完成前，其性能都不會過高。而Redis的好處是一次性將數據加載到內存中，一次性預熱。這樣只要Redis啓動完成，那麼其提供服務的速度都是很是快的。

而在利用RDB和利用AOF啓動上，其啓動時間有一些差異。RDB的啓動時間會更短，緣由有兩個，一是RDB文件中每一條數據只有一條記錄，不會像AOF日誌那樣可能有一條數據的屢次操做記錄。因此每條數據只須要寫一次就好了。另外一個緣由是RDB文件的存儲格式和Redis數據在內存中的編碼格式是一致的，不須要再進行數據編碼工做。在CPU消耗上要遠小於AOF日誌的加載。

好了，大概內容就說到這裏。更詳細完整的版本請看Redis做者的博文：Redis persistence demystified。本文若有描述不周之處，就你們指正。