IT工程師數位筆記本

        接著上一篇說，這里我們來繼續分析一下RDB文件存儲結構，首先大家都知道RDB文件是在redis的“快照”的模式下才會產生，那么如果

我們理解了RDB文件的結構，是不是讓我們對“快照”模式能做到一個心中有數呢？？？

一：RDB結構剖析

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

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

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

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

1. Redis參數： 可以看到在16進制的前5個字節中，是“REDIS"五個大字母，這個的作用顯而易見，肯定就是判斷當前的文件是否為“RDB

                      文件“，這樣才方便用常量的時間來判別。。。

2. db_version： 在Redis字符之后，我們看到了占用4個字節的0006，這個就是RDB文件結構圖中的 db_version。對吧，同樣也很簡單，

                        就是判斷當前Redis的版本號，對否？？？

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

4. EOF：   從winHex上面你是否看到了，它占用一個字節的空間，就是一個“y”上面加了兩點，由于用unicode無法表示，所以出現了這么個

　　　　　 亂碼，當然16進制可以標識，就是所謂的“FF”，看到了沒有？？？ 那么它的作用就是標識database的結束。

5. checksum： 從名字上你就可以看得到，它就是一個校驗和，原理當然就是看文件是否損壞，或者是否被修改，這樣有點像現在的OAuth驗證，

　　　　          對吧，它占用了8個字節，也就是最后的：DC  B3  43  F0 5A DC F2  56。。。

二：帶數據的RDB文件結構演示

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

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

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

1.  database [selectDB]： 可以看到，selectDB其實就是一個無法用unicode標記出來的一個字節，十六進制就是FE，當redis碰到這個字符

                                      的時候就知道自己該干嘛了。。。。要準備執行select命令了。。。

2.  database[db_number]： 在FE之后，我們看到了十六進制的 ”03“，也就是切換到第三個數據庫中，還記得嗎？ 我之前在set數據的時候，

                                         曾今執行過 select 3，也就是將數據set到第3號數據庫中，如果你忘記了，沒關系，我用redis客戶端打開給你看~~

3. database[pairs][type]:  當你知道select哪一號數據庫之后，接下來的操作就是怎么去分析key,value數據了，在key/value數據中，第一個

                                      就是type，其實這個type就是你的value的encoding類型，可以看到在winHex中表示的0，也就是以下的源碼：

4. database[pairs][key][len]：  在type之后，就是所謂的key，而key的組合模式是【len，value】,其中len就是key的長度，你也可以看到，

                                              winHex中表示的是 “04”，也就是說name的長度為4。對吧。。。

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

好了，大概就說這么多了，希望對你有幫助。。。  

           ~~~~~圣誕快樂~~~~~