Redis持久化機制

標籤：

【RDB與AOF兩種持久化模式的對比，實現原理】【RDB模式】fork一個進程，遍曆hash table，利用copy on write，把整個db dump儲存下來。save, shutdown, slave 命令會觸發這個操作。粒度比較大，如果save, shutdown, slave 之前crash了，則中間的操作沒辦法恢複。【AOF模式】把寫操作指令，持續的寫到一個類似記錄檔裡。（類似於從postgresql等資料庫匯出sql一樣，只記錄寫操作）粒度較小，crash之後，只有crash之前沒有來得及做日誌的操作沒辦法恢複。AOF模式：持續的用日誌記錄寫操作，crash後利用日誌恢複；RDB模式：平時寫操作的時候不觸發寫，只有手動提交save命令，或者是關閉命令時，才觸發備份操作。選擇的標準，就是看系統是願意犧牲一些效能，換取更高的緩衝一致性（aof），還是願意寫操作頻繁的時候，不啟用備份來換取更高的效能，待手動運行save的時候，再做備份（rdb）。rdb：最終一致性。  【解密Redis持久化】【http://blog.nosqlfan.com/html/3813.html】【寫操作的流程】首先我們來看一下資料庫在進行寫操作時到底做了哪些事，主要有下面五個過程。

1. 用戶端向服務端發送寫操作（資料在用戶端的記憶體中）
2. 資料庫服務端接收到寫請求的資料（資料在服務端的記憶體中）
3. 服務端調用write(2) 這個系統調用，將資料往磁碟上寫（資料在系統記憶體的緩衝區中）
4. 作業系統將緩衝區中的資料轉移到磁碟控制卡上（資料在磁碟緩衝中）
5. 磁碟控制卡將資料寫到磁碟的物理介質中（資料真正落到磁碟上）

 【故障分析】寫操作大致有上面5個流程，下面我們結合上面的5個流程看一下各種層級的故障。

1. 當資料庫系統故障時，這時候系統核心還是OK的，那麼此時只要我們執行完了第3步，那麼資料就是安全的，因為後續作業系統會來完成後面幾步，保證資料最終會落到磁碟上。
2. 當系統斷電，這時候上面5項中提到的所有緩衝都會失效，並且資料庫和作業系統都會停止工作。所以只有當資料在完成第5步後，機器斷電才能保證資料不丟失，在上述四步中的資料都會丟失。

通過上面5步的瞭解，可能我們會希望搞清下面一些問題：

1. 資料庫多長時間調用一次write(2)，將資料寫到核心緩衝區
2. 核心多長時間會將系統緩衝區中的資料寫到磁碟控制卡
3. 磁碟控制卡又在什麼時候把緩衝中的資料寫到物理介質上

對於第一個問題，通常資料庫層面會進行全面控制。而對第二個問題，作業系統有其預設的策略，但是我們也可以通過POSIX API提供的fsync系列命令強制作業系統將資料從核心區寫到磁碟控制卡上。對於第三個問題，好像資料庫已經無法觸及，但實際上，大多數情況下磁碟緩衝是被設定關閉的。或者是只開啟為讀緩衝，也就是寫操作不會進行緩衝，直接寫到磁碟。建議的做法是僅僅當你的磁碟裝置有備用電池時才開啟寫緩衝。 【資料損毀】        所謂資料損毀，就是資料無法恢複，上面我們講的都是如何保證資料是確實寫到磁碟上去，但是寫到磁碟上可能並不意味著資料不會損壞。比如我們可能一次寫請求會進行兩次不同的寫操作，當意外發生時，可能會導致一次寫操作安全完成，但是另一次還沒有進行。如果資料庫的資料檔案結構組織不合理，可能就會導致資料完全不能恢複的狀況出現。        這裡通常也有三種策略來組織資料，以防止資料檔案損壞到無法恢複的情況：         第一種是最粗糙的處理，就是不通過資料的組織形式保證資料的可恢複性。而是通過配置資料 同步備份的方式，在資料檔案損壞後通過資料備份來進行恢複。實際上MongoDB在不開啟journaling日誌，通過配置Replica Sets時就是這種情況。        另一種是在上面基礎上添加一個 動作記錄，每次操作時記一下操作的行為，這樣我們可以通過動作記錄來進行資料恢複。因為動作記錄是順序追加的方式寫的，所以不會出現動作記錄也無法恢複的情況。這也類似於MongoDB開啟了journaling日誌的情況。        更保險的做法是資料庫 不進行老資料的修改，只是以追加方式去完成寫操作，這樣資料本身就是一份日誌，這樣就永遠不會出現資料無法恢複的情況了。實際上CouchDB就是此做法的優秀範例。 RDB快照

        第一個持久化策略，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 HelloOKredis 127.0.0.1:6379> append key1 " World!"(integer) 12redis 127.0.0.1:6379> del key1(integer) 1redis 127.0.0.1:6379> del non_existing_key(integer) 0

這時我們查看AOF記錄檔，就會得到如下內容：

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

可以看到，寫操作都產生了一條相應的命令作為日誌。其中值得注意的是最後一個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。本文如有描述不周之處，就大家指正。

【Redis RDB檔案格式全解析】【http://blog.nosqlfan.com/html/3734.html】

RDB檔案是Redis持久化的一種方式，Redis通過制定好的策略，按期將記憶體中的資料以鏡像的形式轉存到RDB檔案中。那麼RDB檔案內部格式是什麼樣的呢，Redis又做了哪些工作讓RDB能夠更快的dump和載入呢，下面我們深入RDB檔案，來看一看其內部結構。

首先我們來看一個RDB檔案的概況圖：

----------------------------# RDB檔案是二進位的，所以並不存在斷行符號換行來分隔一行一行.52 45 44 49 53              # 以字串 "REDIS" 開頭30 30 30 33                 # RDB 的版本號碼，大端儲存，比如左邊這個表示版本號碼為0003----------------------------FE 00                       # FE = FE表示資料庫編號，Redis支援多個庫，以數字編號，這裡00表示第0個資料庫----------------------------# Key-Value 對儲存開始了FD $length-encoding         # FD 表示到期時間，到期時間是用 length encoding 編碼儲存的，後面會講到$value-type                 # 1 個位元組用於表示value的類型，比如set,hash,list,zset等$string-encoded-key         # Key 值，通過string encoding 編碼，同樣後面會講到$encoded-value              # Value值，根據不同的Value類型採用不同的編碼方式----------------------------FC $length-encoding         # FC 表示毫秒級的到期時間，後面的具體時間用length encoding編碼儲存$value-type                 # 同上，也是一個位元組的value類型$string-encoded-key         # 同樣是以 string encoding 編碼的 Key值$encoded-value              # 同樣是以對應的資料類型編碼的 Value 值----------------------------$value-type                 # 下面是沒有到期時間設定的 Key-Value對，為防止衝突，資料類型不會以 FD, FC, FE, FF 開頭$string-encoded-key$encoded-value----------------------------FE $length-encoding         # 下一個庫開始，庫的編號用 length encoding 編碼----------------------------...                         # 繼續儲存這個資料庫的 Key-Value 對FF                          ## FF：RDB檔案結束的標誌

下面我們對上面的內容進行詳細講解

Magic Number

第一行就不用講了，REDIS字串用於標識是Redis的RDB檔案

版本號碼

用了4個位元組儲存版本號碼，以大端（big endian）方式儲存和讀取

資料庫編號

以一個位元組的0xFE開頭，後面儲存資料庫的具體編號，資料庫的編號是一個數字，通過 “Length Encoding” 方式編碼儲存，“Length Encoding” 我們後面會講到。

Key-Value值對

值對包括下面四個部分

1. Key 到期時間，這一項是可有可無的
2. 一個位元組表示value的類型
3. Key的值，Key都是字串，通過 “Redis String Encoding” 來儲存
4. Value的值，通過 “Redis Value Encoding” 來根據不同的資料類型做不同的儲存

Key到期時間

到期時間由 0xFD 或 0xFC開頭用於標識，分別表示秒級的到期時間和毫秒級的到期時間，後面的具體時間是一個UNIX時間戳記，秒級或毫秒級的。具體時間戳記的值通過“Redis Length Encoding” 編碼儲存。在匯入RDB檔案的過程中，會通過到期時間判斷是否已到期並需要忽略。

Value類型

Value類型用一個位元組進行儲存，目前包括以下一些值：

• 0 = “String Encoding”
• 1 = “List Encoding”
• 2 = “Set Encoding”
• 3 = “Sorted Set Encoding”
• 4 = “Hash Encoding”
• 9 = “Zipmap Encoding”
• 10 = “Ziplist Encoding”
• 11 = “Intset Encoding”
• 12 = “Sorted Set in Ziplist Encoding”

Key

Key值就是簡單的 “String Encoding” 編碼，具體可以看後面的描述

Value

上面列舉了Value的9種類型，實際上可以分為三大類

• type = 0, 簡單字串
• type 為  9, 10, 11 或 12, value字串在讀取出來後需要先解壓
• type 為 1, 2, 3 或 4, value是字串序列，這一系列的字串用於構建list，set，hash 和 zset 結構

Length Encoding

上面說了很多 Length Encoding ，現在就為大家講解。可能你會說，長度用一個int儲存不就行了嗎？但是，通常我們使用到的長度可能都並不大，一個int 4個位元組是否有點浪費呢。所以Redis採用了變長編碼的方法，將不同大小的數字編碼成不同的長度。

1. 首先在讀取長度時，會讀一個位元組的資料，其中前兩位用於進行變長編碼的判斷
2. 如果前兩位是 0 0，那麼下面剩下的 6位就表示具體長度
3. 如果前兩位是 0 1，那麼會再讀取一個位元組的資料，加上前面剩下的6位，共14位用於表示具體長度
4. 如果前兩位是 1 0，那麼剩下的 6位就被廢棄了，取而代之的是再讀取後面的4 個位元組用於表示具體長度
5. 如果前兩位是 1 1，那麼下面的應該是一個特殊編碼，剩下的 6位用於標識特殊編碼的種類。特殊編碼主要用於將數字存成字串，或者編碼後的字串。具體見 “String Encoding”

這樣做有什麼好處呢，實際就是節約空間：

1. 0 – 63的數字只需要一個位元組進行儲存
2. 而64 – 16383 的數字只需要兩個位元組進行儲存
3. 16383 - 2^32 -1 的數字只需要用5個位元組（1個位元組的標識加4個位元組的值）進行儲存

String Encoding

Redis的 String Encoding 是二進位安全的，也就是說他沒有任何特殊分隔字元用於分隔各個值，你可以在裡面儲存任何東西。它就是一串位元組碼。

下面是 String Encoding 的三種類型

1. 長度編碼的字串
2. 數字替代字串：8位，16位或者32位的數字
3. LZF 壓縮的字串

長度編碼字串

長度編碼字串是最簡單的一種類型，它由兩部分組成，一部分是用 “Length Encoding” 編碼的字串長度，第二部分是具體的位元組碼。

數字替代字串

上面說到過 Length Encoding 的特殊編碼，就在這裡用上了。所以數字替代字串是以 1 1 開頭的，然後讀取這個位元組剩下的6 位，根據不同的值標識不同的數字類型：

• 0 表示下面是一個8 位的數字
• 1 表示下面是一個16 位的數字
• 2 表示下面是一個32 位的數字

LZF壓縮字串

和資料替代字串一樣，它也是以1 1 開頭的，然後剩下的6 位如果值為4，那麼就表示它是一個壓縮字串。壓縮字串解析規則如下：

1. 首先按 Length Encoding 規則讀取壓縮長度 clen
2. 然後按 Length Encoding 規則讀取非壓縮長度
3. 再讀取第二個 clen
4. 擷取到上面的三個資訊後，再通過LZF演算法解碼後面clen長度的位元組碼

List Encoding

Redis List 結構在RDB檔案中的儲存，是依次儲存List中的各個元素的。其結構如下：

1. 首先按 Length Encoding 讀取這個List 的長度 size
2. 然後讀取 size個 String Encoding的值
3. 然後再用這些讀到的 size 個值重新構建 List就完成了

Set Encoding

Set結構和List結構一樣，也是依次儲存各個元素的

Sorted Set Encoding

todo

Hash Encoding

1. 首先按 Length Encoding 讀出hash 結構的大小 size
2. 然後讀取2×size 個 String Encoding的字串（因為一個hash項包括key和value兩項）
3. 將上面讀取到的2×size 個字串解析為hash 和key 和 value
4. 然後將上面的key value對儲存到hash結構中

Zipmap Encoding

參見本站之前的文章：Redis zipmap記憶體布局分析

待續&歡迎投稿

Ziplist Encoding

Intset Encoding

Sorted Set as Ziplist Encoding

來源：RDB_File_Format.textile

Redis持久化機制