Redis常用数据类型
Redis 发展到现在已经有 9 种数据类型了,其中最基础、最常用的数据类型有 5 种,它们分别是:字符串类型、哈希表类型、列表类型、集合类型、有序集合类型,而在这 5 种数据类型中最常用的是字符串类型,所以我们先从字符串的使用开始说起。
字符串类型的全称是 Simple Dynamic Strings 简称 SDS,中文意思是:简单动态字符串。它是以键值对 key-value 的形式进行存储的,根据 key 来存储和获取 value 值,它的使用相对来说比较简单,但在实际项目中应用非常广泛。
字符串使用与内部实现原理
字符串类型能做什么?
字符串类型的使用场景有很多,但从功能的角度来区分,大致可分为以下两种:
- 字符串存储和操作;
- 整数类型和浮点类型的存储和计算。
字符串最常用的业务场景有以下几个。
页面数据缓存
我们知道,一个系统最宝贵的资源就是数据库资源,随着公司业务的发展壮大,数据库的存储量也会越来越大,并且要处理的请求也越来越多,当数据量和并发量到达一定级别之后,数据库就变成了拖慢系统运行的“罪魁祸首”,为了避免这种情况的发生,我们可以把查询结果放入缓存(Redis)中,让下次同样的查询直接去缓存系统取结果,而非查询数据库,这样既减少了数据库的压力,同时也提高了程序的运行速度。
介于以上这个思路,我们可以把文章详情页的数据放入缓存系统。具体的做法是先将文章详情页序列化为字符串存入缓存,再从缓存中读取到字符串,反序列化成对象,然后再赋值到页面进行显示 (当然也可以用哈希类型进行存储,这会在下一篇文章中讲到),这样我们就实现了文章详情页的缓存功能,架构流程对比图如下所示。
原始系统运行流程图:
引入缓存系统后的流程图:
数字计算与统计
Redis 可以用来存储整数和浮点类型的数据,并且可以通过命令直接累加并存储整数信息,这样就省去了每次先要取数据、转换数据、拼加数据、再存入数据的麻烦,只需要使用一个命令就可以完成此流程,具体实现过程本文下半部分会讲。这样我们就可以使用此功能来实现访问量的统计,当有人访问时访问量 +1 就可以了。
共享 Session 信息
通常我们在开发后台管理系统时,会使用 Session 来保存用户的会话(登录)状态,这些 Session 信息会被保存在服务器端,但这只适用于单系统应用,如果是分布式系统此模式将不再适用。
例如用户一的 Session 信息被存储在服务器一,但第二次访问时用户一被分配到服务器二,这个时候服务器并没有用户一的 Session 信息,就会出现需要重复登录的问题。分布式系统每次会把请求随机分配到不同的服务器,因此我们需要借助缓存系统对这些 Session 信息进行统一的存储和管理,这样无论请求发送到那台服务器,服务器都会去统一的缓存系统获取相关的 Session 信息,这样就解决了分布式系统下 Session 存储的问题。
分布式系统单独存储 Session 流程图:
分布式系统使用同一的缓存系统存储 Session 流程图:
字符串如何使用?
通常我们会使用两种方式来操作 Redis:第一种是使用命令行来操作,例如 redis-cli;另一种是使用代码的方式来操作,下面我们分别来看。
命令行操作方式
字符串的操作命令有很多,但大体可分为以下几类:
- 单个键值对操作
- 多个键值对操作
- 数字统计
我们本文使用 redis-cli 来实现对 Redis 的操作,在使用命令之前,先输入 redis-cli
来链接到 Redis 服务器。
单个键值对操作
添加键值对
语法:set key value [expiration EX seconds|PX milliseconds] [NX|XX] 示例:
1 | 127.0.0.1:6379> set k1 val1 |
获取键值对
语法:get key 示例:
1 | 127.0.0.1:6379> get k1 |
给元素追加值
语法:append key value 示例:
1 | 127.0.0.1:6379> get k1 |
查询字符串的长度
语法:strlen key 示例:
1 | 127.0.0.1:6379> strlen k1 |
多个键值对操作
创建一个或多个键值对
语法:mset key value [key value …] 示例:
1 | 127.0.0.1:6379> mset k2 v2 k3 v3 |
小贴士:mset 是一个原子性(atomic)操作,所有给定 key 都会在同一时间内被设置,不会出现某些 key 被更新,而另一些 key 没被更新的情况。
查询一个或多个元素
语法:mget key [key …] 示例:
1 | 127.0.0.1:6379> mget k2 k3 |
数字统计
在 Redis 中可以直接操作整型和浮点型,例如可以直接使用命令来加、减值。
给整数类型的值加 1
语法:incr key 示例:
1 | 127.0.0.1:6379> get k1 |
给整数类型的值减 1
语法:decr key 示例:
1 | 127.0.0.1:6379> get k1 |
根据 key 减去指定的值
语法:decrby key decrement 示例:
1 | 127.0.0.1:6379> get k1 |
如果 key 不存在,则会先初始化此 key 为 0 ,然后再执行减法操作:
1 | 127.0.0.1:6379> get k2 |
根据 key 加指定的整数值
语法:incrby key increment 示例:
1 | 127.0.0.1:6379> get k1 |
如果 key 不存在,则会先初始化此 key 为 0 ,然后再执行加整数值的操作:
1 | 127.0.0.1:6379> get k3 |
根据 key 加上指定的浮点数
语法:incrbyfloat key increment 示例:
1 | 127.0.0.1:6379> get k3 |
如果 key 不存在,则会先初始化此 key 为 0 ,然后再执行加浮点数的操作:
1 | 127.0.0.1:6379> get k4 |
代码操作方式
本文我们使用 Java 语言来实现对 Redis 的操作,首先我们在项目中添加对 Jedis 框架的引用,如果是 Maven 项目,我们会在 pom.xml 文件中添加如下信息:
1 | <dependency> |
Jedis 是 Redis 官方推荐的 Java 客户端开发包,用于实现快速简单的操作 Redis。添加完 Jedis 之后,我们来写具体的操作代码,操作函数与命令方式的调用比较相似,如下代码所示:
1 | import redis.clients.jedis.Jedis; |
代码实战
本文的上半部分我们讲到了字符串的很多种使用场景,本小节就以字符串存储用户对象信息为例,我们先将用户对象信息序列化为字符串存储在 Redis,再从 Redis 中取出字符串并反序列化为对象信息为例,使用 Java 语言来实现。
首先添加 JSON 转换类,用于对象和字符串之间的序列化和反序列化,我们这里采用 Google 的 Gson 来实现,首先在 pom.xml 文件中添加如下引用:
1 | <!-- https://mvnrepository.com/artifact/com.google.code.gson/gson --> |
添加完 Gson 引用之后,我们来写具体的业务代码,先见用户信息序列化之后存储在 Redis 中:
1 | Jedis jedis = new Jedis("xxx.xxx.xxx.xxx", 6379); |
当使用用户信息时,我们从 Redis 反序列化出来,代码如下:
1 | String getUserData = jedis.get("user"); |
以上两个步骤就完成了用户信息存放至 Redis 中的过程,也是常用的经典使用场景之一。
字符串的内部实现
源码分析
Redis 3.2 之前 SDS 源码如下:
1 | struct sds{ |
可以看出 Redis 3.2 之前 SDS 内部是一个带有长度信息的字节数组,存储结构如下图所示:
为了更加有效的利用内存,Redis 3.2 优化了 SDS 的存储结构,源码如下:
1 | typedef char *sds; |
这样就可以针对不同长度的字符串申请相应的存储类型,从而有效的节约了内存使用。
数据类型
我们可以使用 object encoding key
命令来查看对象(键值对)存储的数据类型,当我们使用此命令来查询 SDS 对象时,发现 SDS 对象竟然包含了三种不同的数据类型:int、embstr 和 raw。
int 类型
1 | 127.0.0.1:6379> set key 666 |
embstr 类型
1 | 127.0.0.1:6379> set key abc |
raw 类型
1 | 127.0.0.1:6379> set key abcdefghigklmnopqrstyvwxyzabcdefghigklmnopqrs |
int 类型很好理解,整数类型对应的就是 int 类型,而字符串则对应是 embstr 类型,当字符串长度大于 44 字节时,会变为 raw 类型存储。
为什么是 44 字节?
在 Redis 中,如果 SDS 的存储值大于 64 字节时,Redis 的内存分配器会认为此对象为大字符串,并使用 raw 类型来存储,当数据小于 64 字节时(字符串类型),会使用 embstr 类型存储。既然内存分配器的判断标准是 64 字节,那为什么 embstr 类型和 raw 类型的存储判断值是 44 字节?
这是因为 Redis 在存储对象时,会创建此对象的关联信息,redisObject 对象头和 SDS 自身属性信息,这些信息都会占用一定的存储空间,因此长度判断标准就从 64 字节变成了 44 字节。
在 Redis 中,所有的对象都会包含 redisObject 对象头。我们先来看 redisObject 对象的源码:
1 | typedef struct redisObject { |
它的参数说明如下:
- type:对象的数据类型,例如:string、list、hash 等,占用 4 bits 也就是半个字符的大小;
- encoding:对象数据编码,占用 4 bits;
- lru:记录对象的 LRU(Least Recently Used 的缩写,即最近最少使用)信息,内存回收时会用到此属性,占用 24 bits(3 字节);
- refcount:引用计数器,占用 32 bits(4 字节);
- *ptr:对象指针用于指向具体的内容,占用 64 bits(8 字节)。
redisObject 总共占用 0.5 bytes + 0.5 bytes + 3 bytes + 4 bytes + 8 bytes = 16 bytes(字节)。
了解了 redisObject 之后,我们再来看 SDS 自身的数据结构,从 SDS 的源码可以看出,SDS 的存储类型一共有 5 种:SDSTYPE5、SDSTYPE8、SDSTYPE16、SDSTYPE32、SDSTYPE64,在这些类型中最小的存储类型为 SDSTYPE5,但 SDSTYPE5 类型会默认转成 SDSTYPE8,以下源码可以证明,如下图所示:
那我们直接来看 SDSTYPE8 的源码:
1 | struct __attribute__ ((__packed__)) sdshdr8 { |
可以看出除了内容数组(buf)之外,其他三个属性分别占用了 1 个字节,最终分隔字符等于 64 字节,减去 redisObject 的 16 个字节,再减去 SDS 自身的 3 个字节,再减去结束符 \0
结束符占用 1 个字节,最终的结果是 44 字节(64-16-3-1=44),内存占用如下图所示:
小结
本文介绍了字符串的定义及其使用,它的使用主要分为:单键值对操作、多键值对操作、数字统计、键值对过期操作、字符串操作进阶等。同时也介绍了字符串使用的三个场景,字符串类型可用作为:页面数据缓存,可以缓存一些文章详情信息等;数字计算与统计,例如计算页面的访问次数;也可以用作 Session 共享,用来记录管理员的登录信息等。同时我们深入的介绍了字符串的五种数据存储结构,以及字符串的三种内部数据类型,如下图所示:
同时我们也知道了 embstr 类型向 raw 类型转化,是因为每个 Redis 对象都包含了一个 redisObject 对象头和 SDS 自身属性占用了一定的空间,最终导致数据类型的判断长度是 44 字节。
哈希表使用与内部实现原理
字典类型 (Hash) 又被成为散列类型或者是哈希表类型,它是将一个键值 (key) 和一个特殊的“哈希表”关联起来,这个“哈希表”表包含两列数据:字段和值。例如我们使用字典类型来存储一篇文章的详情信息,存储结构如下图所示:
同理我们也可以使用字典类型来存储用户信息,并且使用字典类型来存储此类信息,是不需要手动序列化和反序列化数据的,所以使用起来更加的方便和高效。
基础使用
首先我们使用命令行工具 redis-cli,来对字典类型进行相关的操作。
插入单个元素
语法:hset key field value 示例:
1 | 127.0.0.1:6379> hset myhash key1 value1 |
当某键不存在时,插入数据
语法:hsetnx key field value 示例:
1 | 127.0.0.1:6379> hsetnx myhash k4 v4 |
如果尝试插入已存在的键,不会改变原来的值,示例如下:
1 | 127.0.0.1:6379> hsetnx myhash k4 val4 |
尝试修改已经存在的 k4 赋值为 val4,但并没有生效,查询 k4 的结果依然是原来的值 v4。
查询单个元素
语法:hget key field 示例:
1 | 127.0.0.1:6379> hget myhash key1 |
删除 key 中的一个或多个元素
语法:hdel myhash field [field …] 示例:
1 | 127.0.0.1:6379> hdel myhash key1 key2 |
注意:不能使用类似于 hdel myhash
的命令删除整个 Hash 值的。
某个整数值累加计算
语法:hincrby key field increment 示例:
1 | 127.0.0.1:6379> hset myhash k3 3 |
代码实战
接下来我们用 Java 代码实现对 Redis 的操作,同样我们先引入 Jedis 框架 ,接下来再用代码来对字典类型进行操作,示例代码如下:
1 | import redis.clients.jedis.Jedis; |
从代码中可以看出,在 Jedis 中我们可以直接使用 Map 来接收 Redis 中读取的字典类型的数据,省去了手动转化的麻烦,还是比较方便的。
数据结构
字典类型本质上是由数组和链表结构组成的,来看字典类型的源码实现:
1 | typedef struct dictEntry { // dict.h |
字典类型的数据结构,如下图所示:
通常情况下字典类型会使用数组的方式来存储相关的数据,但发生哈希冲突时才会使用链表的结构来存储数据。
哈希冲突
字典类型的存储流程是先将键值进行 Hash 计算,得到存储键值对应的数组索引,再根据数组索引进行数据存储,但在小概率事件下可能会出完全不相同的键值进行 Hash 计算之后,得到相同的 Hash 值,这种情况我们称之为哈希冲突。
哈希冲突一般通过链表的形式解决,相同的哈希值会对应一个链表结构,每次有哈希冲突时,就把新的元素插入到链表的尾部,请参考上面数据结构的那张图。
键值查询的流程如下:
- 通过算法 (Hash,计算和取余等) 操作获得数组的索引值,根据索引值找到对应的元素;
- 判断元素和查找的键值是否相等,相等则成功返回数据,否则需要查看 next 指针是否还有对应其他元素,如果没有,则返回 null,如果有的话,重复此步骤。
键值查询流程,如下图所示:
渐进式rehash
Redis 为了保证应用的高性能运行,提供了一个重要的机制——渐进式 rehash。 渐进式 rehash 是用来保证字典缩放效率的,也就是说在字典进行扩容或者缩容是会采取渐进式 rehash 的机制。
扩容
当元素数量等于数组长度时就会进行扩容操作,源码在 dict.c 文件中,核心代码如下:
1 | int dictExpand(dict *d, unsigned long size) |
从以上源码可以看出,如果需要扩容则会申请一个新的内存地址赋值给 ht[1],并把字典的 rehashindex 设置为 0,表示之后需要进行 rehash 操作。
缩容
当字典的使用容量不足总空间的 10% 时就会触发缩容,Redis 在进行缩容时也会把 rehashindex 设置为 0,表示之后需要进行 rehash 操作。
渐进式rehash流程
在进行渐进式 rehash 时,会同时保留两个 hash 结构,新键值对加入时会直接插入到新的 hash 结构中,并会把旧 hash 结构中的元素一点一点的移动到新的 hash 结构中,当移除完最后一个元素时,清空旧 hash 结构,主要的执行流程如下:
- 扩容或者缩容时把字典中的字段 rehashidx 标识为 0;
- 在执行定时任务或者执行客户端的 hset、hdel 等操作指令时,判断是否需要触发 rehash 操作(通过 rehashidx 标识判断),如果需要触发 rehash 操作,也就是调用 dictRehash 函数,dictRehash 函数会把 ht[0] 中的元素依次添加到新的 Hash 表 ht[1] 中;
- rehash 操作完成之后,清空 Hash 表 ht[0],然后对调 ht[1] 和 ht[0] 的值,把新的数据表 ht[1] 更改为 ht[0],然后把字典中的 rehashidx 标识为 -1,表示不需要执行 rehash 操作。
使用场景
哈希字典的典型使用场景如下:
- 商品购物车,购物车非常适合用哈希字典表示,使用人员唯一编号作为字典的 key,value 值可以存储商品的 id 和数量等信息;
- 存储用户的属性信息,使用人员唯一编号作为字典的 key,value 值为属性字段和对应的值;
- 存储文章详情页信息等。
小结
本文我们学习了字典类型的操作命令和在代码中的使用,也明白了字典类型实际是由数组和链表组成的,当字典进行扩容或者缩容时会进行渐进式 rehash 操作,渐进式 rehash 是用来保证 Redis 运行效率的,它的执行流程是同时保留两个哈希表,把旧表中的元素一点一点的移动到新表中,查询的时候会先查询两个哈希表,当所有元素都移动到新的哈希表之后,就会删除旧的哈希表。
列表使用与内部实现原理
列表类型 (List) 是一个使用链表结构存储的有序结构,它的元素插入会按照先后顺序存储到链表结构中,因此它的元素操作 (插入\删除) 时间复杂度为 O(1),所以相对来说速度还是比较快的,但它的查询时间复杂度为 O(n),因此查询可能会比较慢。
基础使用
列表类型的使用相对来说比较简单,对它的操作就相当操作一个没有任何 key 值的 value 集合,如下图所示:
给列表添加一个或多个元素
语法:lpush key value [value …] 示例:
1 | 127.0.0.1:6379> lpush list 1 2 3 |
给列表尾部添加一个或多个元素
语法:rpush key value [value …] 示例:
1 | 127.0.0.1:6379> rpush list2 1 2 3 |
返回列表指定区间内的元素
语法:lrange key start stop 示例:
1 | 127.0.0.1:6379> lrange list 0 -1 |
其中 -1 代表列表中的最后一个元素。
获取并删除列表的第一个元素
语法:lpop key 示例:
1 | 127.0.0.1:6379> lrange list 0 -1 |
获取并删除列表的最后一个元素
语法:rpop key 示例:
1 | 127.0.0.1:6379> lrange list 0 -1 |
根据下标获取对应的元素
语法:lindex key index 示例:
1 | 127.0.0.1:6379> rpush list3 a b c |
代码实战
下面来看列表类型在 Java 中的使用,同样先添加 Jedis 框架,使用代码如下:
1 | public class ListExample { |
程序运行结果如下:
2 Sql [Sql, Java] [Sql, MySQL, Java]
内部实现
我们先用 debug encoding key
来查看列表类型的内部存储类型,如下所示:
1 | 127.0.0.1:6379> object encoding list |
从结果可以看出,列表类型的底层数据类型是 quicklist。
quicklist (快速列表) 是 Redis 3.2 引入的数据类型,早期的列表类型使用的是ziplist (压缩列表) 和双向链表组成的,Redis 3.2 改为用 quicklist 来存储列表元素。
我们来看下 quicklist 的实现源码:
1 | typedef struct quicklist { // src/quicklist.h |
从以上源码可以看出 quicklist 是一个双向链表,链表中的每个节点实际上是一个 ziplist,它们的结构如下图所示:
ziplist 作为 quicklist 的实际存储结构,它本质是一个字节数组,ziplist 数据结构如下图所示:
其中的字段含义如下:
- zlbytes:压缩列表字节长度,占 4 字节;
- zltail:压缩列表尾元素相对于起始元素地址的偏移量,占 4 字节;
- zllen:压缩列表的元素个数;
- entryX:压缩列表存储的所有元素,可以是字节数组或者是整数;
- zlend:压缩列表的结尾,占 1 字节。
源码解析
下面我们来看一下更多关于列表类型的源码实现。
添加功能源码分析
quicklist 添加操作对应函数是 quicklistPush,源码如下:
1 | void quicklistPush(quicklist *quicklist, void *value, const size_t sz, |
以 quicklistPushHead 为例,源码如下:
1 | int quicklistPushHead(quicklist *quicklist, void *value, size_t sz) { |
quicklistPushHead 函数的执行流程,先判断 quicklist 的 head 节点是否可以插入数据,如果可以插入则使用 ziplist 的接口进行插入,否则就新建 quicklistNode 节点进行插入。
函数的入参是待插入的 quicklist,还有需要插入的值 value 以及他的大小 sz。
函数的返回值为 int,0 表示没有新建 head,1 表示新建了 head。 quicklistPushHead 执行流程,如下图所示:
删除功能源码分析
quicklist 元素删除分为两种情况:单一元素删除和区间元素删除,它们都位于 src/quicklist.c 文件中。
单一元素删除
单一元素的删除函数是 quicklistDelEntry,源码如下:
1 | void quicklistDelEntry(quicklistIter *iter, quicklistEntry *entry) { |
可以看出 quicklistDelEntry 函数的底层,依赖 quicklistDelIndex 函数进行元素删除。
区间元素删除
区间元素删除的函数是 quicklistDelRange,源码如下:
1 | // start 表示开始删除的下标,count 表示要删除的个数 |
从上面代码可以看出,quicklist 在区间删除时,会先找到 start 所在的 quicklistNode,计算删除的元素是否小于要删除的 count,如果不满足删除的个数,则会移动至下一个 quicklistNode 继续删除,依次循环直到删除完成为止。
quicklistDelRange 函数的返回值为 int 类型,当返回 1 时表示成功的删除了指定区间的元素,返回 0 时表示没有删除任何元素。
更多源码
除了上面介绍的几个常用函数之外,还有一些更多的函数,例如:
- quicklistCreate:创建 quicklist;
- quicklistInsertAfter:在某个元素的后面添加数据;
- quicklistInsertBefore:在某个元素的前面添加数据;
- quicklistPop:取出并删除列表的第一个或最后一个元素;
- quicklistReplaceAtIndex:替换某个元素。
使用场景
列表的典型使用场景有以下两个:
- 消息队列:列表类型可以使用 rpush 实现先进先出的功能,同时又可以使用 lpop 轻松的弹出(查询并删除)第一个元素,所以列表类型可以用来实现消息队列;
- 文章列表:对于博客站点来说,当用户和文章都越来越多时,为了加快程序的响应速度,我们可以把用户自己的文章存入到 List 中,因为 List 是有序的结构,所以这样又可以完美的实现分页功能,从而加速了程序的响应速度。
小结
通过本文我们可以知道列表类型并不是简单的双向链表,而是采用了 quicklist 的数据结构对数据进行存取,quicklist 是 Redis 3.2 新增的数据类型,它的底层采取的是压缩列表加双向链表的存储结构,quicklist 为了存储更多的数据,会对每个 quicklistNode 节点进行压缩,这样就可以有效的存储更多的消息队列或者文章的数据了。
集合使用与内部实现原理
集合类型 (Set) 是一个无序并唯一的键值集合。
之所以说集合类型是一个无序集合,是因为它的存储顺序不会按照插入的先后顺序进行存储,如下代码所示:
1 | 127.0.0.1:6379> sadd myset v2 v1 v3 #插入数据 v2、v1、v3 |
从上面代码执行结果可以看出,myset 的存储顺序并不是以插入的先后顺序进行存储的。
集合类型和列表类型的区别如下:
- 列表可以存储重复元素,集合只能存储非重复元素;
- 列表是按照元素的先后顺序存储元素的,而集合则是无序方式存储元素的。
基础使用
集合类型的功能比列表类型丰富一些,集合类型可以用来统计多个集合的交集、错集和并集,如下代码所示。
添加一个或多个元素
语法:sadd key member [member …] 示例:
1 | 127.0.0.1:6379> sadd myset v1 v2 v3 |
查询集合所有元素
语法:smembers key 示例:
1 | 127.0.0.1:6379> smembers myset |
查询集合的成员数量
语法:scard key 示例:
1 | 127.0.0.1:6379> scard myset |
查询集合中是否包含某个元素
语法:sismember key member 示例:
1 | 127.0.0.1:6379> sismember myset v1 |
从一个集合中移动一个元素到另一个集合
语法:smove source destination member 示例:
1 | 127.0.0.1:6379> smembers myset |
移除集合中一个或多个元素
语法:srem key member [member …] 示例:
1 | 127.0.0.1:6379> smembers myset |
注意:使用 srem 指令,不存在的元素将会被忽略。
代码实战
下面来看集合类型在 Java 中的使用,同样先添加 Jedis 框架,使用代码如下:
1 | import redis.clients.jedis.Jedis; |
内部实现
集合类型是由 intset (整数集合) 或 hashtable (普通哈希表) 组成的。当集合类型以 hashtable 存储时,哈希表的 key 为要插入的元素值,而哈希表的 value 则为 Null,如下图所示:
当集合中所有的值都为整数时,Redis 会使用 intset 结构来存储,如下代码所示:
1 | 127.0.0.1:6379> sadd myset 1 9 3 -2 |
从上面代码可以看出,当所有元素都为整数时,集合会以 intset 结构进行(数据)存储。 当发生以下两种情况时,会导致集合类型使用 hashtable 而非 intset 存储: 1)当元素的个数超过一定数量时,默认是 512 个,该值可通过命令 set-max-intset-entries xxx
来配置。 2)当元素为非整数时,集合将会使用 hashtable 来存储,如下代码所示:
1 | 127.0.0.1:6379> sadd myht "redis" "db" |
从上面代码可以看出,当元素为非整数时,集合会使用 hashtable 进行存储。
源码解析
集合源码在 t_set.c 文件中,核心源码如下:
1 | /* |
以上这些代码验证了,我们上面所说的内容,当元素都为整数并且元素的个数没有到达设置的最大值时,键值的存储使用的是 intset 的数据结构,反之到元素超过了一定的范围,又或者是存储的元素为非整数时,集合会选择使用 hashtable 的数据结构进行存储。
使用场景
集合类型的经典使用场景如下:
- 微博关注我的人和我关注的人都适合用集合存储,可以保证人员不会重复;
- 中奖人信息也适合用集合类型存储,这样可以保证一个人不会重复中奖。
小结
通过本文我们知道了,集合类型是由整数集合 (intset) 或者是哈希表 (hashtable) 组成的,集合类型比较适合用来数据去重和保障数据的唯一性,除此之外,集合类型还可以用来统计多个集合的交集、错集和并集 (见附录)。当我们存储的数据是无序并且需要去重的情况下,比较适合使用集合类型进行存储。
有序集合使用与内部实现原理
有序集合类型 (Sorted Set) 相比于集合类型多了一个排序属性 score(分值),对于有序集合 ZSet 来说,每个存储元素相当于有两个值组成的,一个是有序结合的元素值,一个是排序值。有序集合的存储元素值也是不能重复的,但分值是可以重复的。
当我们把学生的成绩存储在有序集合中时,它的存储结构如下图所示:
下面我们先从有序集合的使用开始说起。
基础使用
添加一个或多个元素
语法:zadd key [NX|XX] [CH] [INCR] score member [score member …] 示例:
1 | 127.0.0.1:6379> zadd zset1 10 java |
可以看出有序集合的添加是 zadd 键值 分值1 元素值1 分值2 元素值2
的形式添加的。
查询所有元素列表
语法:zrange key start stop [WITHSCORES] 示例:
1 | 127.0.0.1:6379> zrange zset 0 -1 |
其中 -1 表示最后一个元素,查询结果包含开始和结束元素。
删除一个或多个元素(根据元素值)
语法:zrem key member [member …] 示例:
1 | 127.0.0.1:6379> zrangebyscore zset1 0 -1 #查询所有元素 |
删除命令中如果包含了不存在的元素,并不会影响命令的正常执行,不存在的元素将会被忽略。
查询某元素的 score 值
语法:zscore key member 示例:
1 | 127.0.0.1:6379> zscore zset1 redis |
查询 score 区间内元素
语法:zrangebyscore key min max [WITHSCORES] [LIMIT offset count] 示例:
1 | 127.0.0.1:6379> zrangebyscore zset1 3 10 |
查询某元素排名
语法:zrank key member 示例:
1 | 127.0.0.1:6379> zadd zset 5 redis 10 java 8 mysql #创建有序集合 |
可以看出,排名是从 0 开始的,排名可以理解为元素排序后的下标值。
代码实战
下面来看有序集合在 Java 中的使用,同样先添加 Jedis 框架,示例代码如下:
1 | import redis.clients.jedis.Jedis; |
内部实现
有序集合是由 ziplist (压缩列表) 或 skiplist (跳跃表) 组成的。
ziplist
当数据比较少时,有序集合使用的是 ziplist 存储的,如下代码所示:
1 | 127.0.0.1:6379> zadd myzset 1 db 2 redis 3 mysql |
从结果可以看出,有序集合把 myset 键值对存储在 ziplist 结构中了。 有序集合使用 ziplist 格式存储必须满足以下两个条件:
- 有序集合保存的元素个数要小于 128 个;
- 有序集合保存的所有元素成员的长度都必须小于 64 字节。
如果不能满足以上两个条件中的任意一个,有序集合将会使用 skiplist 结构进行存储。 接下来我们来测试以下,当有序集合中某个元素长度大于 64 字节时会发生什么情况? 代码如下:
1 | 127.0.0.1:6379> zadd zmaxleng 1.0 redis |
通过以上代码可以看出,当有序集合保存的所有元素成员的长度大于 64 字节时,有序集合就会从 ziplist 转换成为 skiplist。
小贴士:可以通过配置文件中的 zset-max-ziplist-entries(默认 128)和 zset-max-ziplist-value(默认 64)来设置有序集合使用 ziplist 存储的临界值。
skiplist
skiplist 数据编码底层是使用 zset 结构实现的,而 zset 结构中包含了一个字典和一个跳跃表,源码如下:
1 | typedef struct zset { |
更多关于跳跃表的源码实现,会在后面的章节详细介绍。
跳跃表实现原理
跳跃表的结构如下图所示:
根据以上图片展示,当我们在跳跃表中查询值 32 时,执行流程如下:
- 从最上层开始找,1 比 32 小,在当前层移动到下一个节点进行比较;
- 7 比 32 小,当前层移动下一个节点比较,由于下一个节点指向 Null,所以以 7 为目标,移动到下一层继续向后比较;
- 18 小于 32,继续向后移动查找,对比 77 大于 32,以 18 为目标,移动到下一层继续向后比较;
- 对比 32 等于 32,值被顺利找到。
从上面的流程可以看出,跳跃表会想从最上层开始找起,依次向后查找,如果本层的节点大于要找的值,或者本层的节点为 Null 时,以上一个节点为目标,往下移一层继续向后查找并循环此流程,直到找到该节点并返回,如果对比到最后一个元素仍未找到,则返回 Null。
为什么是跳跃表?而非红黑树?
因为跳跃表的性能和红黑树基本相近,但却比红黑树更好实现,所有 Redis 的有序集合会选用跳跃表来实现存储。
使用场景
有序集合的经典使用场景如下:
- 学生成绩排名
- 粉丝列表,根据关注的先后时间排序
小结
通过本文的学习我们了解到,有序集合具有唯一性和排序的功能,排序功能是借助分值字段 score 实现的,score 字段不仅可以实现排序功能,还可以实现数据的赛选与过滤的功能。我们还了解到了有序集合是由 压缩列表 (ziplist) 或跳跃列表 (skiplist) 来存储的,当元素个数小于 128 个,并且所有元素的值都小于 64 字节时,有序集合会采取 ziplist 来存储,反之则会用 skiplist 来存储,其中 skiplist 是从上往下、从前往后进行元素查找的,相比于传统的普通列表,可能会快很多,因为普通列表只能从前往后依次查找。