Redis的五种对象类型及其底层实现

我就是我 2022-09-25 14:20 215阅读 0赞

http://blog.csdn.net/caishenfans/article/details/44784131

# Redis对象类型简介    #

Redis是一种key/value型[数据库][Link 1]，其中，每个key和value都是使用对象表示的。比如，我们执行以下代码：

**\[plain\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  redis>SET message "hello redis"

其中的key是message，是一个包含了字符串"message"的对象。而value是一个包含了"hello redis"的对象。

Redis共有五种对象的类型，分别是：

*  <table> 
     <thead> 
      <tr> 
       <th>类型常量</th> 
       <th>对象的名称</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td><code>REDIS_STRING</code></td> 
       <td>字符串对象</td> 
      </tr> 
      <tr> 
       <td><code>REDIS_LIST</code></td> 
       <td>列表对象</td> 
      </tr> 
      <tr> 
       <td><code>REDIS_HASH</code></td> 
       <td>哈希对象</td> 
      </tr> 
      <tr> 
       <td><code>REDIS_SET</code></td> 
       <td>集合对象</td> 
      </tr> 
      <tr> 
       <td><code>REDIS_ZSET</code></td> 
       <td>有序集合对象</td> 
      </tr> 
     </tbody> 
    </table>

Redis中的一个对象的结构体表示如下：

**\[cpp\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  /\*
2.   \* Redis 对象
3.   \*/
4.  **typedef****struct** redisObject \{ 
5.  
6.  // 类型
7.   unsigned type:4; 
8.  
9.  // 不使用(对齐位)
10.  unsigned notused:2; 
11. 
12. // 编码方式
13.  unsigned encoding:4; 
14. 
15. // LRU 时间（相对于 server.lruclock）
16.  unsigned lru:22; 
17. 
18. // 引用计数
19. **int** refcount; 
20. 
21. // 指向对象的值
22. **void** \*ptr; 
23. 
24. \} robj;

type表示了该对象的对象类型，即上面五个中的一个。但为了提高存储效率与程序执行效率，每种对象的底层[数据结构][Link 2]实现都可能不止一种。encoding就表示了对象底层所使用的编码。下面先介绍每种底层数据结构的实现，再介绍每种对象类型都用了什么底层结构并分析他们之间的关系。

# Redis对象底层数据结构 #

底层数据结构共有八种，如下表所示：

<table style="color:rgb(54,46,43); font-family:Arial; font-size:14px; line-height:26px"> 
 <thead> 
  <tr> 
   <th>编码常量</th> 
   <th>编码所对应的底层数据结构</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><code>REDIS_ENCODING_INT</code></td> 
   <td><code>long</code>&nbsp;类型的整数</td> 
  </tr> 
  <tr> 
   <td><code>REDIS_ENCODING_EMBSTR</code></td> 
   <td><code>embstr</code>&nbsp;编码的简单动态字符串</td> 
  </tr> 
  <tr> 
   <td><code>REDIS_ENCODING_RAW</code></td> 
   <td>简单动态字符串</td> 
  </tr> 
  <tr> 
   <td><code>REDIS_ENCODING_HT</code></td> 
   <td>字典</td> 
  </tr> 
  <tr> 
   <td><code>REDIS_ENCODING_LINKEDLIST</code></td> 
   <td>双端链表</td> 
  </tr> 
  <tr> 
   <td><code>REDIS_ENCODING_ZIPLIST</code></td> 
   <td>压缩列表</td> 
  </tr> 
  <tr> 
   <td><code>REDIS_ENCODING_INTSET</code></td> 
   <td>整数集合</td> 
  </tr> 
  <tr> 
   <td><code>REDIS_ENCODING_SKIPLIST</code></td> 
   <td>跳跃表和字典</td> 
  </tr> 
 </tbody> 
</table>

## 字符串对象 ##

字符串对象的编码可以是int、raw或者embstr。

如果一个字符串的内容可以转换为long，那么该字符串就会被转换成为long类型，对象的ptr就会指向该long，并且对象类型也用int类型表示。

普通的字符串有两种，embstr和raw。embstr应该是Redis 3.0新增的数据结构,在2.8中是没有的。如果字符串对象的长度小于39字节，就用embstr对象。否则用传统的raw对象。可以从下面这段代码看出：

**\[cpp\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \#define REDIS\_ENCODING\_EMBSTR\_SIZE\_LIMIT 39
2.  robj \*createStringObject(**char** \*ptr, **size\_t** len) \{ 
3.  **if** (len <= REDIS\_ENCODING\_EMBSTR\_SIZE\_LIMIT) 
4.  **return** createEmbeddedStringObject(ptr,len); 
5.  **else**
6.  **return** createRawStringObject(ptr,len); 
7.  \}

embstr的好处有如下几点：

*  embstr的创建只需分配一次内存，而raw为两次（一次为sds分配对象，另一次为objet分配对象，embstr省去了第一次）。
 *  相对地，释放内存的次数也由两次变为一次。
 *  embstr的objet和sds放在一起，更好地利用缓存带来的优势。

需要注意的是，redis并未提供任何修改embstr的方式，即embstr是只读的形式。对embstr的修改实际上是先转换为raw再进行修改。

raw和embstr的区别可以用下面两幅图所示：

![Center][]

![Center 1][]

## 列表对象 ##

列表对象的编码可以是ziplist或者linkedlist。

ziplist是一种压缩链表，它的好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。当列表对象元素不大，每个元素也不大的时候，就采用ziplist存储。但当数据量过大时就ziplist就不是那么好用了。因为为了保证他存储内容在内存中的连续性，插入的复杂度是O(N)，即每次插入都会重新进行realloc。如下图所示，对象结构中ptr所指向的就是一个ziplist。整个ziplist只需要malloc一次，它们在内存中是一块连续的区域。

![Center 2][]

linkedlist是一种双向链表。它的结构比较简单，节点中存放pre和next两个指针，还有节点相关的信息。当每增加一个node的时候，就需要重新malloc一块内存。

![Center 3][]

## 哈希对象    ##

哈希对象的底层实现可以是ziplist或者hashtable。

ziplist中的哈希对象是按照key1,value1,key2,value2这样的顺序存放来存储的。当对象数目不多且内容不大时，这种方式效率是很高的。

hashtable的是由dict这个结构来实现的

**\[cpp\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **typedef****struct** dict \{ 
2.   dictType \*type; 
3.  **void** \*privdata; 
4.   dictht ht\[2\]; 
5.  **long** rehashidx; /\* rehashing not in progress if rehashidx == -1 \*/
6.  **int** iterators; /\* number of iterators currently running \*/
7.  \} dict;

dict是一个字典，其中的指针dicht ht\[2\] 指向了两个哈希表

**\[cpp\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **typedef****struct** dictht \{ 
2.   dictEntry \*\*table; 
3.   unsigned **long** size; 
4.   unsigned **long** sizemask; 
5.   unsigned **long** used; 
6.  \} dictht;

dicht\[0\] 是用于真正存放数据，dicht\[1\]一般在哈希表元素过多进行rehash的时候用于中转数据。

dictht中的table用语真正存放元素了，每个key/value对用一个dictEntry表示，放在dictEntry数组中。

![Center 4][]

## 集合对象    ##

集合对象的编码可以是intset或者hashtable。

intset是一个整数集合，里面存的为某种同一类型的整数，支持如下三种长度的整数：

**\[cpp\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \#define INTSET\_ENC\_INT16 (sizeof(int16\_t))
2.  \#define INTSET\_ENC\_INT32 (sizeof(int32\_t))
3.  \#define INTSET\_ENC\_INT64 (sizeof(int64\_t))

intset是一个有序集合，查找元素的复杂度为O(logN)，但插入时不一定为O(logN)，因为有可能涉及到升级操作。比如当集合里全是int16\_t型的整数，这时要插入一个int32\_t，那么为了维持集合中数据类型的一致，那么所有的数据都会被转换成int32\_t类型，涉及到内存的重新分配，这时插入的复杂度就为O(N)了。是intset不支持降级操作。

## 有序集合对象    ##

有序集合的编码可能两种，一种是ziplist，另一种是skiplist与dict的结合。

ziplist作为集合和作为哈希对象是一样的，member和score顺序存放。按照score从小到大顺序排列。它的结构不再复述。

skiplist是一种跳跃表，它实现了有序集合中的快速查找，在大多数情况下它的速度都可以和平衡树差不多。但它的实现比较简单，可以作为平衡树的替代品。它的结构比较特殊。下面分别是跳跃表skiplist和它内部的节点skiplistNode的结构体：

**\[cpp\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  /\*
2.   \* 跳跃表
3.   \*/
4.  **typedef****struct** zskiplist \{ 
5.  // 头节点，尾节点
6.  **struct** zskiplistNode \*header, \*tail; 
7.  // 节点数量
8.   unsigned **long** length; 
9.  // 目前表内节点的最大层数
10. **int** level; 
11. \} zskiplist; 
12. /\* ZSETs use a specialized version of Skiplists \*/
13. /\*
14.  \* 跳跃表节点
15.  \*/
16. **typedef****struct** zskiplistNode \{ 
17. // member 对象
18.  robj \*obj; 
19. // 分值
20. **double** score; 
21. // 后退指针
22. **struct** zskiplistNode \*backward; 
23. // 层
24. **struct** zskiplistLevel \{ 
25. // 前进指针
26. **struct** zskiplistNode \*forward; 
27. // 这个层跨越的节点数量
28.  unsigned **int** span; 
29.  \} level\[\]; 
30. \} zskiplistNode;

head和tail分别指向头节点和尾节点，然后每个skiplistNode里面的结构又是分层的(即level数组)

用图表示，大概是下面这个样子：

![Center 5][]

每一列都代表一个节点，保存了member和score，按score从小到大排序。每个节点有不同的层数，这个层数是在生成节点的时候随机生成的数值。每一层都是一个指向后面某个节点的指针。这种结构使得跳跃表可以跨越很多节点来快速访问。

前面说到了，有序集合ZSET是有跳跃表和hashtable共同形成的。

**\[cpp\]** [view plain][] [copy][view plain]

[print][view plain] [?][view plain] [![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  **typedef****struct** zset \{ 
2.  // 字典
3.   dict \*dict; 
4.  // 跳跃表
5.   zskiplist \*zsl; 
6.  \} zset;

为什么要用这种结构呢。试想如果单一用hashtable，那可以快速查找、添加和删除元素，但没法保持集合的有序性。如果单一用skiplist，有序性可以得到保障，但查找的速度太慢O（logN）。

# 结尾 #

简单介绍了Redis的五种对象类型和它们的底层实现。事实上，Redis的高效性和灵活性正是得益于对于同一个对象类型采取不同的底层结构，并在必要的时候对二者进行转换；以及各种底层结构对内存的合理利用。

[Link 1]: http://lib.csdn.net/base/14
[view plain]: http://blog.csdn.net/caishenfans/article/details/44784131#
[CODE]: https://code.csdn.net/assets/CODE_ico.png
[CODE_CODE]: https://code.csdn.net/snippets/633335
[ico_fork.svg]: https://code.csdn.net/assets/ico_fork.svg
[ico_fork.svg 1]: https://code.csdn.net/snippets/633335/fork
[Link 2]: http://lib.csdn.net/base/31
[Center]: /images/20220717/0b2be56cbea040819e3f4586a705957d.png
[Center 1]: /images/20220717/71fab1cf19a7427696b8be71fe205192.png
[Center 2]: /images/20220717/3448a235974d421b9485317583d7b2b1.png
[Center 3]: /images/20220717/fb05d8903e544898a8ba03fe3520e650.png
[Center 4]: /images/20220717/f050f92374c54ac581e7305ef44afece.png
[Center 5]: /images/20220717/449cf023f6614bfc99e6a5fe62a52ca8.png