RDB文件是在redis的“快照”的模式下才會產(chǎn)生，那么如果我們理解了RDB文件的結構，是不是讓我們對“快照”模式能做到一個心中有數(shù)呢？？？

一、RDB結構剖析

　　首先呢，我們要對RDB文件有一個概念性的認識，比如下面畫的圖一樣：

從圖中，我們大概看到了RDB文件的一個簡要的存儲模式，但為了更好的方便對照，我準備save一個empty database，對比一下看看效果：

然后我們用winHex打開dump.rdb文件，看看它的16進制。

好了，該打開的我都打開了，下面我們一一來比較一下。

1. Redis參數(shù)： 可以看到在16進制的前5個字節(jié)中，是“REDIS"五個大字母，這個的作用顯而易見，肯定就是判斷當前的文件是否為“RDB文件“，這樣才方便用常量的時間來判別。。。

2. db_version： 在Redis字符之后，我們看到了占用4個字節(jié)的0006，這個就是RDB文件結構圖中的 db_version。對吧，同樣也很簡單，就是判斷當前Redis的版本號，對否？？？

3. database： 由于我演示的是一個empty database，自然沒有相應的結構，等下我們再插入記錄，再對比一下。

4. EOF： 從winHex上面你是否看到了，它占用一個字節(jié)的空間，就是一個“y”上面加了兩點，由于用unicode無法表示，所以出現(xiàn)了這么個亂碼，當然16進制可以標識，就是所謂的“FF”，看到了沒有？？？ 那么它的作用就是標識database的結束。

5. checksum： 從名字上你就可以看得到，它就是一個校驗和，原理當然就是看文件是否損壞，或者是否被修改，這樣有點像現(xiàn)在的OAuth驗證，對吧，它占用了8個字節(jié)，也就是最后的：DC B3 43 F0 5A DC F2 56。。。

二、帶數(shù)據(jù)的RDB文件結構演示

好了，上面我已經(jīng)演示了除Database之外的所有參數(shù)，下面我們來set一個最簡單的string類型，看看database結構是否如圖所示。

用WinHex打開dump.rdb文件如下：

為了方便對照，我在圖中標記了一下Database開始的位置，也就是十六進制的 FE。。。

1. database [selectDB]： 可以看到，selectDB其實就是一個無法用unicode標記出來的一個字節(jié)，十六進制就是FE，當redis碰到這個字符的時候就知道自己該干嘛了。。。。要準備執(zhí)行select命令了。。。

2. database[db_number]： 在FE之后，我們看到了十六進制的 ”03“，也就是切換到第三個數(shù)據(jù)庫中，還記得嗎？ 我之前在set數(shù)據(jù)的時候，曾今執(zhí)行過select 3，也就是將數(shù)據(jù)set到第3號數(shù)據(jù)庫中，如果你忘記了，沒關系，我用redis客戶端打開給你看~~

3. database[pairs][type]: 當你知道select哪一號數(shù)據(jù)庫之后，接下來的操作就是怎么去分析key,value數(shù)據(jù)了，在key/value數(shù)據(jù)中，第一個就是type，其實這個type就是你的value的encoding類型，可以看到在winHex中表示的0，也就是以下的源碼：

4.database[pairs][key][len]： 在type之后，就是所謂的key，而key的組合模式是【len，value】,其中l(wèi)en就是key的長度，你也可以看到，winHex中表示的是 “04”，也就是說name的長度為4。對吧。。。

5.database[pairs][key][value] 同樣的道理，這里的模式也是【len，value】，前面為value的length，后面為value的具體值。

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論