接著上一篇說，這裡我們來繼續分析一下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的具體值。。。
好了，大概就說這麼多了，希望對你有幫助。。。
~~~~~聖誕快樂~~~~~
