key redis 模糊查询个数_value中存储过多的元素-Redis大key多key拆分方案

项目中存在Redis大key问题,由于存储了大量学生ID,违反了阿里云Redis开发规范。文章提出了一种拆分方案,通过计算学生ID模除固定桶数确定归属key,并维护一个集合存储所有key。不适合的场景如SPOP需确保随机性,需要额外处理。
摘要由CSDN通过智能技术生成

背景

在我的项目中,会存在一个DG下拥有10w+的学生,每个学生在进入直播之前,都需要通过校验,查询是否是这个直播所关联DG下的学生;为了提高并发,我们把大纲和学生的关系存入Redis中,使用set存储,那么一个DG的key会存储过多的元素(学生ID),形成Redis大key的情况。

在阿里云 Redis 的开发规范, 对value设计有以下建议:

  • 1)【强制】:拒绝 bigkey(防止网卡流量、慢查询) string 类型控制在 10KB 以内,hash、list、set、zset 元素个数不要超过 5000。

反例:一个包含 200 万个元素的 list。

非字符串的 bigkey,不要使用 del 删除,使用 hscan、sscan、zscan 方式渐进式删除,同时要注意防止 bigkey 过期时间自动删除问题 (例如一个 200 万的 zset 设置 1 小时过期,会触发 del 操作,造成阻塞,而且该操作不会不出现在慢查询中 (latency 可查)),查找方法和删除方法

value中存储过多的元素拆分方案

类似这种场景,可以将这些元素分拆。

现在,固定一个桶(bucket)的数量,比如 5000, 每次存取的时候,先在本地计算field的hash值,模除 5000, 确定了该field落在哪个key上。

以上的DG学生场景,我们根据学生ID模除5000,确定该学生落在哪个key上;

为了方便获取大纲下所有的学生ID,那么维护一个key来存储大纲学生key的集合(学生ID模除 5000的值)

下图简要说明我们是怎么设计实现的:

79df2934edfb32c2dfdc7958024bc141.png

value中存储过多的元素拆分方案图解

  1. 我们定义每个key为一个桶,那么这个桶 bucket=学生ID模除5000
  2. 为了快速查询所有桶,把桶的序号存储在 her:sy:{syllabusId}:b key的set集合中
  3. 其中 syllabusId 为DG

不适合的场景

如果要保证 SPOP 的数据的确是集合中的一个随机元素,这个就需要一些附加的属性,或者是在key的拼接上做一些工作

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值