概念

Redis作為一個(gè)開(kāi)源的用C編寫(xiě)的非關(guān)系型數(shù)據(jù)庫(kù)，基于優(yōu)秀的CRUD效率，常用于軟件系統(tǒng)的緩存，其本身提供了以下五種數(shù)據(jù)格式：

• string：字符串
• list：列表
• hash：散列表
• set：無(wú)序集合
• zset：有序集合

接下來(lái)我們就要針對(duì)這五種數(shù)據(jù)結(jié)構(gòu)，來(lái)分析其底層的結(jié)構(gòu)
這里選用的版本是redis-5.0.4，所以可能有很多地方和如今網(wǎng)絡(luò)上的其他博文不太一致，不同的地方我會(huì)在文中指出
string
因?yàn)閞edis使用c語(yǔ)言開(kāi)發(fā)，所以自然沒(méi)有java和c++的那些字符串類庫(kù)，在redis中，其自己定義了一種字符串格式，叫做SDS（Simple Dynamic String），即簡(jiǎn)單動(dòng)態(tài)字符串
這個(gè)結(jié)構(gòu)定義在sds.h中：

typedef char *sds;

但是這個(gè)sds類型僅作為參數(shù)和返回值使用，并不是真正用于操作的類型，真正核心的部分是下面的這些類：

struct __attribute__ ((__packed__)) sdshdr5 {unsigned char flags; char buf[]; }; struct __attribute__ ((__packed__)) sdshdr8 {uint8_t len; uint8_t alloc; unsigned char flags; char buf[]; }; struct __attribute__ ((__packed__)) sdshdr16 {uint16_t len;uint16_t alloc; unsigned char flags;char buf[]; }; struct __attribute__ ((__packed__)) sdshdr32 {uint32_t len;uint32_t alloc; unsigned char flags; char buf[]; }; struct __attribute__ ((__packed__)) sdshdr64 {uint64_t len; uint64_t alloc;unsigned char flags; char buf[]; };

除掉第一個(gè)結(jié)構(gòu)體（已經(jīng)棄用），sds具體類型的結(jié)構(gòu)可以分為以下部分：

• len：已使用的長(zhǎng)度，即字符串的真實(shí)長(zhǎng)度
• alloc：除去標(biāo)頭和終止符(’\0’)后的長(zhǎng)度
• flags：低3位表示字符串類型，其余5位未使用（我暫時(shí)沒(méi)發(fā)現(xiàn)redis在哪里使用過(guò)這個(gè)屬性）
• buf[]：存儲(chǔ)字符數(shù)據(jù)

這里和老版本做一下對(duì)比，因?yàn)槲沂诸^只有4.x和5.x的版本，它們sds的實(shí)現(xiàn)是一致的，但是據(jù)其他人說(shuō)sds之前的版本實(shí)現(xiàn)方式不同，有時(shí)間我會(huì)去下載下來(lái)看一下，其將字符串分為以下部分：

• len：buf中已經(jīng)占有的長(zhǎng)度（表示此字符串的實(shí)際長(zhǎng)度）
• free：buf中未使用的緩沖區(qū)長(zhǎng)度
• buf[]：實(shí)際保存字符串?dāng)?shù)據(jù)的地方

redis同時(shí)寫(xiě)重寫(xiě)了大量的與sds類型相關(guān)的方法，那redis為什么要這么下功夫呢，有以下4個(gè)優(yōu)點(diǎn)：

• 降低獲取字符串長(zhǎng)度的時(shí)間復(fù)雜度到O(1)
• 減少了修改字符串時(shí)的內(nèi)存重分配次數(shù)
• 兼容c字符串的同時(shí)，提高了一些字符串工具方法的效率
• 二進(jìn)制安全（數(shù)據(jù)寫(xiě)入的格式和讀取的格式一致）

list
我們查看源文件可以看到有兩個(gè)list，一個(gè)是ziplist，字面意是壓縮列表，另一個(gè)是quicklist，字面意是快速列表，在redis中直接使用的是quicklist，但是我們先來(lái)看ziplist
ziplist
ziplist并不是一個(gè)類名，其結(jié)構(gòu)是下面這樣的： …
其中各部分代表的含義如下：

• zlbytes：4個(gè)字節(jié)（32bits），表示ziplist占用的總字節(jié)數(shù)
• zltail：4個(gè)字節(jié)（32bits），表示ziplist中最后一個(gè)節(jié)點(diǎn)在ziplist中的偏移字節(jié)數(shù)
• entries：2個(gè)字節(jié)（16bits），表示ziplist中的元素?cái)?shù) entry：長(zhǎng)度不定，表示ziplist中的數(shù)據(jù)
• zlend：1個(gè)字節(jié)（8bits），表示結(jié)束標(biāo)記，這個(gè)值固定為ff（255）

這些數(shù)據(jù)均為小端存儲(chǔ)，所以可能有些人查看數(shù)據(jù)的二進(jìn)制流與其含義對(duì)應(yīng)不上，其實(shí)是因?yàn)樽x數(shù)據(jù)的方式錯(cuò)了
ziplist內(nèi)部采取數(shù)據(jù)壓縮的方式進(jìn)行存儲(chǔ)，壓縮方式就不是重點(diǎn)了，我們僅從宏觀來(lái)看，ziplist類似一個(gè)封裝的數(shù)組，通過(guò)zltail可以方便地進(jìn)行追加和刪除尾部數(shù)據(jù)、使用entries可以方便地計(jì)算長(zhǎng)度
但是其依然有數(shù)組的缺點(diǎn)，就是當(dāng)插入和刪除數(shù)據(jù)時(shí)會(huì)頻繁地引起數(shù)據(jù)移動(dòng)，所以就引出了quicklist數(shù)據(jù)類型
quicklist
其核心數(shù)據(jù)結(jié)構(gòu)如下：

typedef struct quicklist {quicklistNode *head;quicklistNode *tail;unsigned long count; /* ziplist所有節(jié)點(diǎn)的個(gè)數(shù) */unsigned long len; /* quicklistNode節(jié)點(diǎn)的個(gè)數(shù) */int fill : 16; /* 單個(gè)節(jié)點(diǎn)的填充因子 */unsigned int compress : 16; /* 壓縮端結(jié)點(diǎn)的深度 */ } quicklist;

我們可以明顯地看出，quicklist是一個(gè)雙向鏈表的結(jié)構(gòu)，但是內(nèi)部又涉及了ziplist，我們可以這么說(shuō)，在宏觀上，quicklist是一個(gè)雙向鏈表，在微觀上，每一個(gè)quicklist的節(jié)點(diǎn)都是一個(gè)ziplist
在redis.conf中，可以使用下面兩個(gè)參數(shù)來(lái)進(jìn)行優(yōu)化：

• list-max-ziplist-size：表示每個(gè)quicklistNode的字節(jié)大小。默認(rèn)為2，表示8KB
• list-compress-depth：表示quicklistNode節(jié)點(diǎn)是否要壓縮。默認(rèn)為0，表示不壓縮

這種存儲(chǔ)方式的優(yōu)點(diǎn)和鏈表的優(yōu)點(diǎn)一致，就是插入和刪除的效率很高，而鏈表查詢的效率又由ziplist來(lái)進(jìn)行彌補(bǔ)，所以quicklist就成為了list數(shù)據(jù)結(jié)構(gòu)的首選
hash
hash這種結(jié)構(gòu)在redis的使用時(shí)最為常見(jiàn)，在redis中，hash這種結(jié)構(gòu)有兩種表示：zipmap和dict
zipmap
zipmap其格式形如下面這樣： <zmlen><len>"foo"<len><free>"bar"<len>"hello"<len><free>"world"
各部分的含義如下：

• zmlen：1個(gè)字節(jié)，表示zipmap的總字節(jié)數(shù)
• len：1~5個(gè)字節(jié)，表示接下來(lái)存儲(chǔ)的字符串長(zhǎng)度
• free：1個(gè)字節(jié)，是一個(gè)無(wú)符號(hào)的8位數(shù)，表示字符串后面的空閑未使用字節(jié)數(shù)，由于修改與鍵對(duì)應(yīng)的值而產(chǎn)生

這其中相鄰的兩個(gè)字符串就分別是鍵和值，比如在上面的例子中，就表示"foo" => "bar", "hello" => "world"這樣的對(duì)應(yīng)關(guān)系

這種方式的缺點(diǎn)也很明顯，就是查找的時(shí)間復(fù)雜度為O(n)，所以只能當(dāng)作一個(gè)輕量級(jí)的hashmap來(lái)使用
dict
這種方式就適于存儲(chǔ)大規(guī)模的數(shù)據(jù)，其格式如下：

typedef struct dict {dictType *type;/* 指向自定義類型的指針，可以存儲(chǔ)各類型數(shù)據(jù) */void *privdata; /* 私有數(shù)據(jù)的指針 */dictht ht[2];/* 兩個(gè)hash表，一般只有h[0]有效，h1[1]只在rehash的時(shí)候才有值 */long rehashidx; /* -1：沒(méi)有在rehash的過(guò)程中，大于等于0：表示執(zhí)行rehash到第幾步 */unsigned long iterators; /* 正在遍歷的迭代器個(gè)數(shù) */ } dict;

如果我們不想更深入的話了解到這種程度就可以了，其中真正存儲(chǔ)數(shù)據(jù)的是dictEntry結(jié)構(gòu)，如下：

typedef struct dictEntry {void *key;union {void *val;uint64_t u64;int64_t s64;double d;} v;struct dictEntry *next; } dictEntry;

很明顯是一個(gè)鏈表，我們知道這是采用鏈?zhǔn)浇Y(jié)構(gòu)存儲(chǔ)就足夠了
這種方式會(huì)消耗較多的內(nèi)存，所以一般數(shù)據(jù)較少時(shí)會(huì)采用輕量級(jí)的zipmap
set
在redis中，我們可以查看intset.h文件，這是一個(gè)存儲(chǔ)整數(shù)的集合，其結(jié)構(gòu)如下：

typedef struct intset {uint32_t encoding;uint32_t length;int8_t contents[]; } intset;

其中各字段含義如下：

• encoding：數(shù)據(jù)編碼格式，表示每個(gè)數(shù)據(jù)元素用幾個(gè)字節(jié)存儲(chǔ)（可取的值有2、4，和8）
• length：元素個(gè)數(shù)
• contents：柔性數(shù)組，這部分內(nèi)存單獨(dú)分配，不包含在intset中

具體的操作我們就不詳細(xì)展開(kāi)了，了解集合這種數(shù)據(jù)結(jié)構(gòu)的應(yīng)該都很清楚，我們這里說(shuō)一下，intset有一個(gè)數(shù)據(jù)升級(jí)的概念，比方說(shuō)我們有一個(gè)16位整數(shù)的set，這時(shí)候插入了一個(gè)32位整數(shù)，所以就導(dǎo)致整個(gè)集合都升級(jí)為32位整數(shù)，但是反過(guò)來(lái)卻不行，這也就是柔性數(shù)組的由來(lái)
如果集合過(guò)大，會(huì)采用dict的方式來(lái)進(jìn)行存儲(chǔ)
zset
zset，有很多地方也叫做sorted set，是一個(gè)鍵值對(duì)的結(jié)構(gòu)，其鍵被稱為member，也就是集合元素（zset依然是set，所以member不能相同），其對(duì)應(yīng)的值被稱為score，是一個(gè)浮點(diǎn)數(shù)，可以理解為優(yōu)先級(jí)，用于排列zset的順序
其也有兩種存儲(chǔ)方式，一種是ziplist/zipmap的格式，這種方式我們就不過(guò)多介紹了，只需要了解這種格式將數(shù)據(jù)按照score的順序排列即可
另一種存儲(chǔ)格式是采用了skiplist，意為跳躍表，可以看成平衡樹(shù)映射的數(shù)組，其查找的時(shí)間復(fù)雜度和平衡樹(shù)基本沒(méi)有差別，但是實(shí)現(xiàn)更為簡(jiǎn)單，形如下面這樣的結(jié)構(gòu)（圖來(lái)源跳躍表的原理）：

總結(jié)

以上是生活随笔為你收集整理的浅谈Redis五种数据结构的底层原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。