废话不多说直接上类型
string(字符串)
hash(哈希)
list(列表)
set(集合)
zset(有序集合)
stream(流)
geospatial(地理)
bitmap(位图)
bitfield(位域)
hyperloglog(基数统计)
string是redis最基本的类型,可以存储任意类型的数据,文本,数字,图片,序列化的对象,一个string最大可以存储512M的数据
string底层实现是SDS(simple dynamic string) 是一个动态字符串结构,由长度,空闲空间,以及字节数组三部分构成
SDS有三种编码格式 分别为 embstr,raw,int。其中embstr,raw存储字符串,int存储整形
embstr: 占用64Bytes得空间,存储44Bytes的数据
raw 存储大于44Bytes的数据
embstr 结构存储小于等于44个字节的字符串,embstr 每次开辟64个byte的空间
前19个byte用于存储embstr 结构
中间的44个byte存储数据
最后为\0符号
raw结构:
在存储字符串时候,redis会根据数据的长度来判断使用哪种结构,小于44个字节就是用embstr
大于就会使用raw结构
1.缓存数据
2.计数器 利用incr 和decr实现原子性的加减操作
3.分布式锁,setnx命令实现互斥访问
4.限流 利用expire命令实现时间窗口的访问控制
hash是一个键值对集合,可以存储多个字段和值,类似于map对象,一个hash类型的键最多可以有2^32-1个字段
Hash类型底层实现有三种:
配置信息,利用 hmset 和 hmget 命令实现批量设置和获取配置项。
hash一共两种结构 ziplist(redis7.0之前) listpack(7.0之后) 和hashtable
从ziplist或者listpack转换成hashtable是通过元素数量或者单个key或者value的长度决定的
hash-max-ziplist-entries
:表示当hash中的元素数量小于或等于该值时,使用ziplist编码,否则使用hashtable编码。ziplist是一种压缩列表,它可以节省内存空间,但是访问速度较慢。hashtable是一种哈希表,它可以提高访问速度,但是占用内存空间较多。默认值为512。
hash-max-ziplist-value
:表示当 hash中的每个元素的 key
和 value
的长度都小于或等于该值时,使用 ziplist编码,否则使用 hashtable编码。默认值为 64。
ziplist/listpack都是hash结构用来存储少量数据的结构。从Redis7.0后,hash默认使用listpack结构。因为 ziplist有一个致命的缺陷,就是连锁更新,当一个节点的长度发生变化时,可能会导致后续所有节点的长度字段都要重新编码,这会造成极差的性能
ziplist是一种紧凑的链表结构,他将所有的字段和值顺序的存储在一块连续的内存中
ziplist每个entry都包含previous_entry_length来记录上一个节点的大小,长度是1个byte或者5个byte
如果前一个节点的长度小于254byte 采用1个byte存储这个长度值
如果前一个节点长度大于等于254byte则采用5个byte来保存这个长度值,第一个byte为0xfe后面四个byte才是真实的长度数据
假设,现有有N个连续、长度为250~253个byte的entry,因此entry的previous_entry_length属性占用1个btye
当第一个字节大于等于254bytes导致第二节,previous_entry_length变为5个bytes,第二节的长度由250变为254。而第二节长度的增加必然会影响第三节的previous_entry_length。ziplist这种特殊套娃的情况下产生的连续多次空间扩展操作成为连锁更新。新增、删除都可能导致连锁更新的产生。
由于ziplist需要倒着遍历,所以需要用previous_entry_length记录前一个entry的长度。而listpack可以通过total_bytes和end计算出来。所以previous_entry_length不需要了。
listpack 的设计彻底消灭了 ziplist 存在的级联更新行为,元素与元素之间完全独立,不会因为一个元素的长度变长就导致后续的元素内容会受到影响。
与ziplist做对比的话,牺牲了内存使用率,避免了连锁更新的情况。从代码复杂度上看,listpack相对ziplist简单很多,再把增删改统一做处理,从listpack的代码实现上看,极简且高效。
hashtable是一种散列结构,将字段和值分别存储在两个数组中,通过哈市哈桑农户计算字段在数组中给的索引
ziplist废弃是因为:
ziplist在field个数太大、key太长、value太长三者有其一的时候会有以下问题:
ziplist每次插入都有开辟空间,连续的
查询的时候,需要从头开始计算,查询速度变慢
hashtable通过rehash进行渐进式扩容,rehash会冲洗你计算hash值,且奖hash桶的容量扩大
rehash步骤
扩展哈希和收缩哈希都是通过执行rehash
来完成,这其中就涉及到了空间的分配和释放,主要经过以下五步:
为字典dict的ht[1]哈希表分配空间,其大小取决于当前哈希表已保存节点数(即:ht[0].used):
如果是扩展操作则ht[1]的大小为2的n次方中第一个大于等于ht[0].used * 2
属性的值(比如used=3,此时ht[0].used * 2=6
,故2的3次方为8就是第一个大于used * 2的值(2 的 2 次方 6))。
如果是收缩操作则ht[1]大小为 2 的 n 次方中第一个大于等于ht[0].used
的值
将字典中的属性rehashidx
的值设置为0,表示正在执行rehash
操作
将ht[0]中所有的键值对依次重新计算哈希值,并放到ht[1]数组对应位置,每完成一个键值对的rehash
之后rehashidx的值需要自增1
当ht[0]中所有的键值对都迁移到ht[1]之后,释放ht[0],并将ht[1]修改为ht[0],然后再创建一个新的ht[1]数组,为下一次rehash做准备
将字典中的属性rehashidx
设置为-1,表示此次rehash
操作结束,等待下一次rehash
Redis中的这种重新哈希的操作因为不是一次性全部rehash
,而是分多次来慢慢的将ht[0]中的键值对rehash
到ht[1],故而这种操作也称之为渐进式rehash
。渐进式rehash
可以避免集中式rehash
带来的庞大计算量,是一种分而治之的思想。
在渐进式rehash
过程中,因为还可能会有新的键值对存进来,此时Redis的做法是新添加的键值对统一放入ht[1]中,这样就确保了ht[0]键值对的数量只会减少。
当正在执行rehash
操作时,如果服务器收到来自客户端的命令请求操作,则会先查询ht[0],查找不到结果再到ht[1]中查询
list是一个有序的字符串列表,它按照插入顺序排序,并且支持在两端插入活删除元素,一个lsit可以存储2^32-1个元素
edis3.2
以后,list 类型的底层实现只有一种结构,就是quicklist。版本不同时,底层实现是不同的。
list 类型的应用场景主要是实现队列和栈,比如:
消息队列,利用 lpush 和 rpop 命令实现生产者消费者模式。
最新消息,利用 lpush 和 ltrim 命令实现固定长度的时间线。
历史记录,利用 lpush 和 lrange 命令实现浏览记录或者搜索记录。
在讲解list结构之前,需要先说明一下list结构编码的更替,如下
在Redis3.2
之前,list使用的是linkedlist
和ziplist
在Redis3.2~Redis7.0
之间,list使用的是quickList
,是linkedlist
和ziplist
的结合
在Redis7.0
之后,list使用的也是quickList
,只不过将ziplist
转为listpack
,它是listpack、linkedlist结合版
redis3.2版本之前linkedlist和ziplist可以选择切换
ziplist转为linkedlist的条件可在redis.conf配置
list-max-ziplist-entries 512
list-max-ziplist-value 64
quicklist(ziplist和linklist的结合)
quicklist
存储了一个双向列表,每个列表的节点是一个ziplist
,所以实际上quicklist
并不是一个新的数据结构,它就是linkedlist
和ziplist
的结合,然后被命名为快速列表。
ziplist内部entry个数可在redis.conf配置
list-max-ziplist-size -2
# -5: 每个ziplist最多为 64 kb <-- 影响正常负载,不推荐
# -4: 每个ziplist最多为 32 Kb <-- 不推荐
# -3: 每个ziplist最多为 16 Kb <-- 最好不要使用
# -2: 每个ziplist最多为 8 Kb <-- 好
# -1: 每个ziplist最多为 4 Kb <-- 好
# 正数为ziplist内部entry个数
ziplist通过特定的LZF压缩算法来将节点进行压缩存储,从而更进一步的节省空间,而很多场景都是两端元素访问率最高,我们可以通过配置list-compress-depth
来排除首尾两端不压缩的entry个数。
list-compress-depth 0
# - 0:不压缩(默认值)
# - 1:首尾第 1 个元素不压缩
# - 2:首位前 2 个元素不压缩
# - 3:首尾前 3 个元素不压缩
# - 以此类推
和Hash结构一样,因为ziplist
有连锁更新问题,redis7.0
将ziplist
替换为listpack
,下面是新quickList的结构图
set是一个无序去重的集合,一个set类型的键值醉倒可以存储2^32-1个元素
set类型的底层实现有两种:
intset 整型集合
hashtable (hash表)哈希表和 hash 类型的哈希表相同,它将元素存储在一个数组中,并通过哈希函数计算元素在数组中的索引
Redis 会根据 set 中元素的数量和类型来选择合适的编码方式,当 set 达到一定的阈值时,会自动转换编码方式。
set 类型的应用场景主要是利用集合的特性,比如:
去重,利用 sadd 和 scard 命令实现元素的添加和计数。
交集,并集,差集,利用 sinter,sunion 和 sdiff 命令实现集合间的运算。
随机抽取,利用 srandmember 命令实现随机抽奖或者抽样。
在讲解set结构之前,需要先说明一下set结构编码的更替,如下
在Redis7.2
之前,set使用的是intset
和hashtable
在Redis7.2
之后,set使用的是intset
、listpack
、hashtable
intset
是一种紧凑的数组结构,它只保存int
类型的数据,它将所有的元素按照从小到大的顺序存储在一块连续的内存中。intset
会根据传入的数据大小,encoding
分为int16_t
、int32_t
、int64_t
在Redis7.2
之前,当一个集合满足以下两个条件时,Redis 会选择使用intset
编码:
集合对象保存的所有元素都是整数值
集合对象保存的元素数量小于等于512
个(默认)
intset最大元素数量可在redis.conf配置
set-max-intset-entries 512
在redis7.2
之前,sds
类型的数据会直接放入到编码结构式为hashtable
的set
中。其中,sds
其实就是redis
中的string
类型。
而在redis7.2
之后,sds类型的数据,首先会使用listpack
结构当 set
达到一定的阈值时,才会自动转换为hashtable
。
添加listpack
结构是为了提高内存利用率和操作效率,因为 hashtable 的空间开销和碰撞概率都比较高。
hashtable 的空间开销高
hashtable 的空间开销高是因为它需要预先分配一个固定大小的数组来存储键值对,而这个数组的大小通常要大于实际存储的元素个数,以保证较低的装载因子。装载因子是指 hashtable 中已经存储的元素个数和数组大小的比值,它反映了 hashtable 的空间利用率
如果装载因子过高,那么 hashtable 的性能会下降,因为碰撞的概率会增加
如果装载因子过低,那么 hashtable 的空间利用率会下降,因为数组中会有很多空闲的位置
因此,hashtable 需要在装载因子和空间利用率之间做一个平衡,通常装载因子的推荐值是 0.75
hashtable 的碰撞概率高
hashtable
的碰撞概率高是因为它使用了一个散列函数来将任意长度的键映射到一个有限范围内的整数,作为数组的索引
散列函数的设计很重要,它应该尽可能地保证不同的键能够均匀地分布在数组中,避免出现某些位置过于拥挤,而其他位置过于稀疏的情况。然而,由于散列函数的输出范围是有限的,而键的取值范围是无限的,所以不可能完全避免两个不同的键被散列到同一个位置上,这就产生了碰撞。碰撞会影响 hashtable 的性能,因为它需要额外的处理方式来解决冲突,比如开放寻址法或者链地址法
举例说明,假设有一个大小为8的hashtable
,使用取模运算作为散列函数,即h(k) = k mod 8。现在有四个键:5,13,21,29,它们都被散列到索引1
处
这就是一个碰撞的例子,因为四个键都映射到了同一个索引。这种情况可能是由于以下原因造成的:
散列函数的选择不合适,没有充分利用hashtable的空间。
键的分布不均匀,有些区间的键出现的频率更高。
hashtable的大小太小,不能容纳所有的键。
为了解决碰撞,redis
采用了链地址法。就是在每个索引处维护一个链表,存储所有散列到该索引的键。但是,如果链表过长,查找效率会降低。因此,一般建议保持hashtable的负载因子(即键的数量除以hashtable的大小)在一定范围内,比如0.5到0.75之间。如果负载因子过高或过低,可以通过扩容或缩容来调整hashtable的大小
intset 、listpack和hashtable这三者的转换时根据要添加的数据、当前set
的编码和阈值决定的。
如果要添加的数据是整型,且当前set
的编码为intset
,如果超过阈值由intset
直接转为hashtable
阈值条件为:
set-max-intset-entries
,intset
最大元素个数,默认512
如果要添加的数据是字符串,分为三种情况
阈值条件为:
set-max-listpack-entries
:最大元素个数,默认128set_max_listpack_value
:最大元素大小,默认64 以上两个条件需要同时满足才能进行编码转换
当前set
的编码为intset
:如果没有超过阈值,转换为listpack
;否则,直接转换为hashtable
当前set
的编码为listpack
:如果超过阈值,就转换为hashtable
当前set
的编码为hashtable
:直接插入,编码不会进行转换
这玩意面试老问,一定要好好看啊!!!!
Redis 中zset是一种有序集合类型,可以存储不重复的字符串元素,并且给每个元素赋予一个权重值(score)Redis通过权重来为集合中的元素进行从小到大排序,zset的成员是唯一的,但是权重值是可以重复的,一个zset最多可以存储2^32-1个元素
zset 类型的应用场景主要是利用分数和排序的特性,比如:
排行榜,利用 zadd 和 zrange 命令实现分数的更新和排名的查询
延时队列,利用 zadd 和 zpopmin 命令实现任务的添加和执行,并且可以定期地获取已经到期的任务
访问统计,可以使用 zset 来存储网站或者文章的访问次数,并且可以按照访问量进行排序和筛选。
底层原理
Redis在存储zset结构的数据,为了达到内存和性能的平衡, 针对少量存储和大量存储分别设计了两种结构分别为:
当 zset
中的元素个数和元素值的长度比较小的时候,Redis
使用ziplist/listpack
来节省内存空间。当 zset
中的元素个数和元素值的长度达到一定阈值时,Redis
会自动将ziplist/listpack
转换为skiplist
,以提高操作效率
具体来说,当zset同时满足一下两个条件,会使用listpack作为底层结构
元素个数小于 zset_max_listpack_entries
,默认值为 128
元素值的长度小于zset_max_listpack_value
,默认值为 64
当 zset
中不满足以上两个条件时,会使用 skiplist
作为底层结构。
跳跃表是一种随机化的数据结构,实际上就是一种可以进行二分查找的有序链表,跳跃表在原有的有序链表上面增加了多级索引,通过索引来实现快速查找,跳跃表不仅能提高搜索性能,同时也可以提高插入和删除操作的性能
优点:
缺点
skiplist
有一个层数上的问题,当层数过多,会影响查询效率。而Redis
使用了一个随机函数来决定每个节点的层数,这个随机函数的期望值是 1/(1-p)
,其中 p
是一个概率常数,Redis
中默认为 0.25
。这样可以保证跳跃表的平均高度为 log (1/p) n
,其中 n
是节点数。Redis 还限制了跳跃表的最大层数为 32 ,这样可以避免过高的索引层造成空间浪费
stream是一个类似日志的数据结构,可以记录一系列的键值对,每个键值对都有一个唯一的ID,Y一个stream类型的键最多可以存储2^64-1个键值对
stram类型的底层是rax(基数树)是一种压缩的前缀树结构,他将所有的兼职的对按照ID的字典存储在一个树形结构中,rax可以快速定位,插入,删除任意位置的键值对
stream 类型的应用场景主要是实现事件驱动的架构,比如:
消息队列,利用 xadd 和 xread 命令实现生产者消费者模式。
操作日志,利用 xadd 和 xrange 命令实现操作记录和回放。
数据同步,利用 xadd 和 xreadgroup 命令实现多个消费者组之间的数据同步。
typedef struct raxNode {
uint32_t iskey:1; /* Does this node contain a key? */
uint32_t isnull:1; /* Associated value is NULL (don't store it). */
uint32_t iscompr:1; /* 前缀是否压缩 */
uint32_t size:29; /* Number of children, or compressed string len. */
unsigned char data[];
} raxNode;
iskey 是否包含key
isnull 是否存储了value值
iscompr 前缀是否压缩,决定了size存储的是什么以及data的数据结构
iscompr=0 非压缩节点,size是孩子节点的数量 据格式为[header strlen=0][abc][a-ptr][b-ptr][c-ptr](value-ptr?)
。其有size个字符,
iscompr 压缩节点,size是一压缩的字符串长度 数据格式为[header strlen=3][xyz][z-ptr](value-ptr?)
。
举例说明
只插入foot
其中,z-ptr
指向的叶子节点的iskey=1
,标识foot
这个key。
插入foot后,插入footer
与foot节点中每个字符进行比较,获得最大公共前缀foot
将er作为foot的子节点,其iskey=1
,标识foot
这个key
将er的子节点的iskey=1
,标识footer
这个key
插入foot后,插入fo
与foot节点中每个字符进行比较,获得最大公共前缀fo
将foot拆成fo和ot
将ot作为fo的子节点,其iskey=1
,标识fo
这个key
设置ot的子节点的iskey=1
,标识foot
这个key
插入foot后,插入foobar
HyperLogLog 是一种概率数据结构,用于在恒定的内存大小下估计集合的基数(不同元素的个数)。它不是一个独立的数据类型,而是一种特殊的 string 类型,它可以使用极小的空间来统计一个集合中不同元素的数量,也就是基数。一个 hyperloglog 类型的键最多可以存储 12 KB 的数据.
hyperloglog 类型的底层实现是 SDS(simple dynamic string),它和 string 类型相同,只是在操作时会使用一种概率算法来计算基数。hyperloglog 的误差率为 0.81%,也就是说如果真实基数为 1000,那么 hyperloglog 计算出来的基数可能在 981 到 1019 之间
hyperloglog 类型的应用场景主要是利用空间换时间和精度,比如:
统计网站的独立访客数(UV)
统计在线游戏的活跃用户数(DAU)
统计电商平台的商品浏览量
统计社交网络的用户关注数
统计日志分析中的不同事件数
需要统计某商品用户的关注数
PFADD goodA "1"
PFADD goodA "2"
PFCOUNT goodA
2
用于存储和查询地理空间位置的数据类型,基于sorted set 数据结构实现,利用geohash算法iang经纬度编码为二进制字符串,并作为sorted set 的score值
GEOADD key longitude latitude member [longitude latitude member …]
:将一个或多个地理空间位置(经度、纬度、名称)添加到指定的 key 中
GEOPOS key member [member …]
:返回一个或多个地理空间位置的经纬度
GEODIST key member1 member2 [unit]
:返回两个地理空间位置之间的距离,可以指定单位(m, km, mi, ft)
GEORADIUS key longitude latitude radius unit [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
:返回指定圆心和半径内的地理空间位置,可以指定返回坐标、距离、哈希值、数量、排序方式等,也可以将结果存储到另一个 key 中
GEORADIUSBYMEMBER key member radius unit [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
: 返回以指定成员为圆心的指定半径内的地理空间位置,其他参数同 GEORADIUS
bitmap
不是一个独立的数据类型,而是一种特殊的 string 类型,它可以将一个 string 类型的值看作是一个由二进制位组成的数组,并提供了一系列操作二进制位的命令。一个 bitmap 类型的键最多可以存储 2^32 - 1 个二进制位。
bitmap 类型的底层实现是 SDS(simple dynamic string),它和 string 类型相同,只是在操作时会将每个字节拆分成 8 个二进制位。
bitmap 类型的应用场景主要是利用二进制位的特性,比如:
统计用户活跃度,利用 setbit 和 bitcount 命令实现每天或每月用户登录次数的统计。
实现布隆过滤器,利用 setbit 和 getbit 命令实现快速判断一个元素是否存在于一个集合中。
实现位图索引,利用 bitop 和 bitpos 命令实现对多个条件进行位运算和定位
假如需要统计每个用户的当天登录次数统计。
首先,需要规定bitmap的格式,假设为{userid}:{年份}:{第几天} {秒数} {是否登录}
将userid
为100的用户,记录他在2024年第100天中第1秒,是否登录
SETBIT 100:2024:100:1;1
将userid
为100的用户,记录他在2024年第100天中第10240 秒,是否登录
SETBIT 100:2024:100:10240:1
统计userid
为100的用户,在2024年第100天的登录次数
BITCOUNT 100:2024:100
bitfield
结构是基于字符串类型的一种扩展,可以让你对一个字符串中的任意位进行设置,增加和获取操作,就像一个位数组一样
可以操作任意位长度的整数,从无符号的1位整数到有符号的63位整数。这些值是使用二进制编码的Redis
字符串来存储的
bitfield
结构支持原子的读,写和增加操作,使它们成为管理计数器和类似数值的好选择
Bitfield
的使用场景与bitmap
类似,主要是一些需要用不同位长度的整数来表示状态或属性的场合,例如:
用一个32位的无符号整数来表示用户的金币数量,用一个32位的无符号整数来表示用户杀死的怪物数量,可以方便地对这些数值进行设置,增加和获取
用一个16位的有符号整数来表示用户的等级,用一个16位的有符号整数来表示用户的经验值,可以方便地对这些数值进行设置,增加和获取
用一个8位的无符号整数来表示用户的性别,用一个8位的无符号整数来表示用户的年龄,可以方便地对这些数值进行设置,增加和获取
bitfield
和bitmap
都是基于string
类型的位操作,但是有一些区别:
bitmap
只能操作1位的无符号整数,而bitfield
可以操作任意位长度的有符号或无符号整数
bitmap
只能设置或获取指定偏移量上的位,而bitfield
可以对指定偏移量上的位进行增加或减少操作
bitmap
可以对多个字符串进行位运算,而bitfield
只能对单个字符串进行位操作
bitmap
的偏移量是从0开始的,而bitfield
的偏移量是从最高有效位开始的
例如,使用bitfield
存储用户的个人信息,
用一个8位的无符号整数来表示用户的性别,0表示男,1表示女
用一个8位的无符号整数来表示用户的年龄,范围是0-255
用一个16位的无符号整数来表示用户的身高,单位是厘米,范围是0-65535
用一个16位的无符号整数来表示用户的体重,单位是克,范围是0-65535
假设有一个用户,性别是女,年龄是25,身高是165厘米,体重是50千克,可以用以下命令来存储和获取这些信息:
BITFIELD user:1:info SET u8 #0 1 SET u8 #1 25 SET u16 #2 165 SET u16 #3 50000
获取这个用户的信息,性别,年龄,身高,体重
BITFIELD user:1:info GET u8 #0 GET u8#1 GET u16 #2 GET u16 #3