Redis五种数据结构(String List Set ZSet Hash)详解

矫情吗；* 2024-03-22 12:45 38阅读 0赞

#### 文章目录 ####

*   *  1 String
     *  2 List
     *  3 Set
     *  4 ZSet
     *  5 Hash

Redis中的任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象，源码如下：

1、什么是redisObject：

从Redis的使用者的角度来看，⼀个Redis节点包含多个database（非cluster模式下默认是16个，cluster模式下只能是1个），而一个database维护了从key space到object space的映射关系。这个映射关系的key是string类型，⽽value可以是多种数据类型，比如：  
string, list, hash、set、sorted set等。我们可以看到，key的类型固定是string，而value可能的类型是多个。  
⽽从Redis内部实现的⾓度来看，database内的这个映射关系是用⼀个dict来维护的。dict的key固定用⼀种数据结构来表达就够了，这就是动态字符串sds。而value则比较复杂，为了在同⼀个dict内能够存储不同类型的value，这就需要⼀个通⽤的数据结构，这个通用的数据结构就是robj，全名是redisObject。

![1653986956618][]

Redis的编码方式

Redis中会根据存储的数据类型不同，选择不同的编码方式，共包含11种不同类型：

<table> 
 <thead> 
  <tr> 
   <th><strong>编号</strong></th> 
   <th><strong>编码方式</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>0</td> 
   <td>OBJ_ENCODING_RAW</td> 
   <td>raw编码动态字符串</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>OBJ_ENCODING_INT</td> 
   <td>long类型的整数的字符串</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>OBJ_ENCODING_HT</td> 
   <td>hash表（字典dict）</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>OBJ_ENCODING_ZIPMAP</td> 
   <td>已废弃</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>OBJ_ENCODING_LINKEDLIST</td> 
   <td>双端链表</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>OBJ_ENCODING_ZIPLIST</td> 
   <td>压缩列表</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>OBJ_ENCODING_INTSET</td> 
   <td>整数集合</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>OBJ_ENCODING_SKIPLIST</td> 
   <td>跳表</td> 
  </tr> 
  <tr> 
   <td>8</td> 
   <td>OBJ_ENCODING_EMBSTR</td> 
   <td>embstr的动态字符串</td> 
  </tr> 
  <tr> 
   <td>9</td> 
   <td>OBJ_ENCODING_QUICKLIST</td> 
   <td>快速列表</td> 
  </tr> 
  <tr> 
   <td>10</td> 
   <td>OBJ_ENCODING_STREAM</td> 
   <td>Stream流</td> 
  </tr> 
 </tbody> 
</table>

五种数据结构

Redis中会根据存储的数据类型不同，选择不同的编码方式。每种数据类型的使用的编码方式如下：

<table> 
 <thead> 
  <tr> 
   <th><strong>数据类型</strong></th> 
   <th><strong>编码方式</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>OBJ_STRING</td> 
   <td>int、embstr、raw</td> 
  </tr> 
  <tr> 
   <td>OBJ_LIST</td> 
   <td>LinkedList和ZipList(3.2以前)、QuickList（3.2以后）</td> 
  </tr> 
  <tr> 
   <td>OBJ_SET</td> 
   <td>intset、HT</td> 
  </tr> 
  <tr> 
   <td>OBJ_ZSET</td> 
   <td>ZipList、HT、SkipList</td> 
  </tr> 
  <tr> 
   <td>OBJ_HASH</td> 
   <td>ZipList、HT</td> 
  </tr> 
 </tbody> 
</table>

### 1 String ###

String是Redis中最常见的数据存储类型：

其基本编码方式是RAW，基于简单动态字符串（SDS）实现，存储上限为512mb。

如果存储的SDS长度小于44字节，则会采用EMBSTR编码，此时object head与SDS是一段连续空间。申请内存时只需要调用一次内存分配函数，效率更高。

（1）底层实现⽅式：动态字符串sds 或者 long  
String的内部存储结构⼀般是SDS（Simple Dynamic String，可以动态扩展内存），但是如果⼀个String类型的value的值是数字，那么Redis内部会把它转成long类型来存储，从⽽减少内存的使用。

![1653987103450][]

如果存储的字符串是整数值，并且大小在LONG\_MAX范围内，则会采用INT编码：直接将数据保存在RedisObject的ptr指针位置（刚好8字节），不再需要SDS了。

![1653987159575][]

![1653987172764][]

![1653987202522][]

确切地说，String在Redis中是⽤⼀个robj来表示的。

用来表示String的robj可能编码成3种内部表⽰：`OBJ_ENCODING_RAW`，`OBJ_ENCODING_EMBSTR`，`OBJ_ENCODING_INT`。  
其中前两种编码使⽤的是SDS来存储，最后⼀种OBJ\_ENCODING\_INT编码直接把string存成了long型。

在对string进行incr, decr等操作的时候，如果它内部是OBJ\_ENCODING\_INT编码，那么可以直接行加减操作；

如果它内部是OBJ\_ENCODING\_RAW或OBJ\_ENCODING\_EMBSTR编码，那么Redis会先试图把sds存储的字符串转成long型，如果能转成功，再进行加减操作。

对⼀个内部表示成long型的string执行append, setbit, getrange这些命令，针对的仍然是string的值（即⼗进制表示的字符串），而不是针对内部表⽰的long型进⾏操作。比如字符串”32”，如果按照字符数组来解释，它包含两个字符，它们的ASCII码分别是0x33和0x32。当我们执行命令setbit key 7 0的时候，相当于把字符0x33变成了0x32，这样字符串的值就变成了”22”。

⽽如果将字符串”32”按照内部的64位long型来解释，那么它是0x0000000000000020，在这个基础上执⾏setbit位操作，结果就完全不对了。

因此，在这些命令的实现中，会把long型先转成字符串再进行相应的操作。

### 2 List ###

Redis的List类型可以从首、尾操作列表中的元素：

![1653987240622][]

哪一个数据结构能满足上述特征？

*  LinkedList ：普通链表，可以从双端访问，内存占用较高，内存碎片较多
 *  ZipList ：压缩列表，可以从双端访问，内存占用低，存储上限低
 *  QuickList：LinkedList + ZipList，可以从双端访问，内存占用较低，包含多个ZipList，存储上限高

Redis的List结构类似一个双端链表，可以从首、尾操作列表中的元素：

在3.2版本之前，Redis采用ZipList和LinkedList来实现List，当元素数量小于512并且元素大小小于64字节时采用ZipList编码，超过则采用LinkedList编码。

在3.2版本之后，Redis统一采用QuickList来实现List：

![1653987313461][]

### 3 Set ###

Set是Redis中的单列集合，满足下列特点：

*  不保证有序性
 *  保证元素唯一
 *  求交集、并集、差集

![1653987342550][]

可以看出，Set对查询元素的效率要求非常高，思考一下，什么样的数据结构可以满足？  
HashTable，也就是Redis中的Dict，不过Dict是双列集合（可以存键、值对）

Set是Redis中的集合，不一定确保元素有序，可以满足元素唯一、查询效率要求极高。  
为了查询效率和唯一性，set采用HT编码（Dict）。Dict中的key用来存储元素，value统一为null。

当存储的所有数据都是整数，并且元素数量不超过`set-max-intset-entries`时，Set会采用IntSet编码，以节省内存

![1653987388177][]

结构如下：

![1653987454403][]

### 4 ZSet ###

ZSet也就是SortedSet，其中每一个元素都需要指定一个score值和member值：

*  可以根据score值排序后
 *  member必须唯一
 *  可以根据member查询分数

![1653992091967][]

因此，zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求。之前学习的哪种编码结构可以满足？

*  SkipList：可以排序，并且可以同时存储score和ele值（member）, **没办法实现高效的键唯一性检查**
 *  HT（Dict）：可以键值存储，并且可以根据key找value, **不能排序**

小孩子才做选择, Zest: “我全都要!”

![1653992121692][]

![1653992172526][]

可以看到ZSet的性能很高, 但是费内存.

当元素数量不多时，HT和SkipList的优势不明显，而且更耗内存。因此zset还会采用ZipList结构来节省内存，不过需要**同时**满足两个条件：

*  元素数量小于`zset_max_ziplist_entries`，默认值128
 *  每个元素都小于`zset_max_ziplist_value`字节，默认值64

ziplist本身没有排序功能，而且没有键值对的概念，因此需要有ZSet通过编码实现：

*  ZipList是连续内存，因此score和element是紧挨在一起的两个entry， element在前，score在后
 *  score越小越接近队首，score越大越接近队尾，按照score值升序排列

![1653992238097][]

![1653992299740][]

### 5 Hash ###

Hash结构与Redis中的Zset非常类似：

*  都是键值存储
 *  都需求根据键获取值
 *  键必须唯一

区别如下：

*  zset的键是member，值是score；hash的键和值都是任意值
 *  zset要根据score排序；hash则无需排序

（1）底层实现方式：压缩列表ziplist 或者 字典dict

当Hash中数据项比较少的情况下，Hash底层才⽤压缩列表ZipList进⾏存储数据以节省内存. ZipList中相邻的两个entry分别保存field和value

随着数据的增加，底层的ziplist就可能会转成dict，触发条件有两个：

*  ZipList中的元素数量超过了`hash-max-ziplist-entries`( 默认为512)
 *  ZipList中的任意Entry大小超过了`hash-max-ziplist-value` (默认为64字节)

当满足上面两个条件其中之⼀的时候，Redis就使⽤dict字典来实现hash。  
Redis的hash之所以这样设计，是因为当ziplist变得很⼤的时候，它有如下几个缺点：

*  每次插⼊或修改引发的realloc操作会有更⼤的概率造成内存拷贝，从而降低性能。
 *  ⼀旦发生内存拷贝，内存拷贝的成本也相应增加，因为要拷贝更⼤的⼀块数据。
 *  当ziplist数据项过多的时候，在它上⾯查找指定的数据项就会性能变得很低，因为ziplist上的查找需要进行遍历。

总之，ziplist本来就设计为各个数据项挨在⼀起组成连续的内存空间，这种结构并不擅长做修改操作。⼀旦数据发⽣改动，就会引发内存realloc，可能导致内存拷贝。

hash结构如下：

![1653992339937][]

zset集合如下：

![1653992360355][]

因此，Hash底层采用的编码与Zset也基本一致，只需要把排序有关的SkipList去掉即可：

Hash结构默认采用ZipList编码，用以节省内存。 ZipList中相邻的两个entry 分别保存field和value

当数据量较大时，Hash结构会转为HT编码，也就是Dict，触发条件有两个：

*  ZipList中的元素数量超过了`hash-max-ziplist-entries`（默认512）
 *  ZipList中的任意entry大小超过了`hash-max-ziplist-value`（默认64字节）

![image-20230505194018667][]

![image-20230505194234497][]

![image-20230505194250446][]

![1653992413406][]

[1653986956618]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/af3cbc49d43e467b9b49bd62b4292781.png
[1653987103450]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/8aa080089d1d44a0be93b9e1c4b194f8.png
[1653987159575]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/9af7d5622be44293aa70ec5b0453cddb.png
[1653987172764]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d1ec7577b6b046bb8bfcbcc1dfe0e388.png
[1653987202522]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c8d51554022948a498ad81afa99a4f70.png
[1653987240622]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/3978c9cf30504913b469591f0505c792.png
[1653987313461]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/595443f85351420d96233c5f35350537.png
[1653987342550]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/c967abf1948a46edafbc6b563ab466f2.png
[1653987388177]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/372248735c9045048f01cd4f35f1d4f7.png
[1653987454403]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f0c26d842dfa40578c7e63236ac34b20.png
[1653992091967]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d42ab31e19404584a7e379176f72ed6e.png
[1653992121692]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/22157252240f4d81b8d49e7a4a3fd086.png
[1653992172526]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/7703ca2030b84d58a46cb5c1ed20bcde.png
[1653992238097]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/4dad99bf97d94750815c6f0611d6ef33.png
[1653992299740]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/0f0affd839274eeca3e6b80df0105073.png
[1653992339937]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d3e114e14f3a49869c27f9902f776d07.png
[1653992360355]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/01f11123d4c24cc28d05c204a2c74748.png
[image-20230505194018667]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/1d297d0f6ad94994a6a9af64faa73293.png
[image-20230505194234497]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/4b1d0239d0af48a2bd4997eb84e2a245.png
[image-20230505194250446]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/54627ec7277c499b8e6ae86b9231925a.png
[1653992413406]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/f7a19582b2794af2b22831d48b8269e6.png