RDB文件是在redis的“快照”的模式下才會產生,那么如果我們理解了RDB文件的結構,是不是讓我們對“快照”模式能做到一個心中有數呢???
一、RDB結構剖析
首先呢,我們要對RDB文件有一個概念性的認識,比如下面畫的圖一樣:
從圖中,我們大概看到了RDB文件的一個簡要的存儲模式,但為了更好的方便對照,我準備save一個empty database,對比一下看看效果:
然后我們用winHex打開dump.rdb文件,看看它的16進制。
好了,該打開的我都打開了,下面我們一一來比較一下。
1. Redis參數: 可以看到在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。。。
二、帶數據的RDB文件結構演示
好了,上面我已經演示了除Database之外的所有參數,下面我們來set一個最簡單的string類型,看看database結構是否如圖所示。
用WinHex打開dump.rdb文件如下:
為了方便對照,我在圖中標記了一下Database開始的位置,也就是十六進制的 FE。。。
1. database [selectDB]: 可以看到,selectDB其實就是一個無法用unicode標記出來的一個字節(jié),十六進制就是FE,當redis碰到這個字符的時候就知道自己該干嘛了。。。。要準備執(zhí)行select命令了。。。
2. database[db_number]: 在FE之后,我們看到了十六進制的 ”03“,也就是切換到第三個數據庫中,還記得嗎? 我之前在set數據的時候,曾今執(zhí)行過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】,其中l(wèi)en就是key的長度,你也可以看到,winHex中表示的是 “04”,也就是說name的長度為4。對吧。。。
5.database[pairs][key][value] 同樣的道理,這里的模式也是【len,value】,前面為value的length,后面為value的具體值。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。
您可能感興趣的文章:- Redis 徹底禁用RDB持久化操作
- 淺談Redis中的RDB快照
- Redis 通過 RDB 方式進行數據備份與還原的方法
- Redis持久化RDB和AOF區(qū)別詳解
- Redis打開rdb文件常用方法詳解
- redis學習之RDB、AOF與復制時對過期鍵的處理教程
- Redis兩種持久化方案RDB和AOF詳解
- Redis RDB技術底層原理詳解