Redis Bigkey

目录

[优雅的 key](#优雅的 key)

[拒绝 Bigkey](#拒绝 Bigkey)

[Bigkey 的危害](#Bigkey 的危害)

[如何发现 Bigkey](#如何发现 Bigkey)

[如何删除 Bigkey](#如何删除 Bigkey)


优雅的 key

Redis 的 key 虽然可以自定义,但是最好遵循以下几条约定

  • 遵循基本格式:[业务名称]:[数据名]:[id]

  • 长度不超过 44 个字节

  • 不包含特殊字符

key 是 string 类型,低层编码包含 int embstr 和 raw 三种。embstr 在小于 44 字节使用,采用连续内存空间,内存占用更小

拒绝 Bigkey

Bigkey 通常以 key 的大小和 key 中的成员的数量来决定的,比如一个 key 的大小就占用了 5 M 或者说其内部成员超过一万个等,我们其实更加推荐单个 key 的 val 值小于 10KB ,对于几个类型的 key 我们建议元素的数量小于 1000 个

说了这么多,我们可以使用 memory usage key 来查看一个 key 包括其中的元素的一共占用多少个字节,或者 strlen key 也可以查看一个 key 的字节长度

Bigkey 的危害

  • 网络阻塞:对 Bigkey 执行请求时,少量的 QPS 就可能导致带宽使用率占满,导致 Redis 实例,乃至整个物理机变慢

  • 数据倾斜:Bigkey 所在的 Redis 实例内存使用率远超其他实例,无法使数据分片的内存资源达到均衡

  • Redis 阻塞:对元素较多的 hash , list , zset 等做运算会比较耗时,使得主进程堵塞

  • CPU 压力:对 Bigkey 的数据序列化和反序列化会导致 CPU 的使用率飙升,影响其实例和本机的其他应用

如何发现 Bigkey

  • redis-cli --bigkeys:利用这条命令就可以遍历 redis 内所有的 key 并返回 key 的整体统计信息与每个数据的 Top1 的 big key,但是这个会整个扫描 redis 中所有的 key 这样相对来说还是比较耗时的

  • scan 扫描:自己编码,利用 scan 扫描 redis 中所有的 key ,利用 strlen ,hlen 等命令来查看一个 key 的实际长度,这个命令只会扫描一部分 key ,这个范围由使用者自行定义,一般这个用的相对比较多

  • 使用第三方工具:如 Redis-Rdb-Tools 分析 RDB 快照文件,全面分析内存情况

  • 网络监控:自定义网络监控,监控进出 Redis 的网络数据,超出预警时主动报警

如何删除 Bigkey

Bigkey 内存占用较多,即便删除这样的 key 也是比较耗时的,这同样也会导致主线程阻塞,引发一系列问题

在 redis 3.0 版本以前,如果是集合类型,都是先遍历 big key 的元素,再逐个删除,最后再删除 key

来到 redis 4.0 及以后官方就提供了异步删除的命令 :unlink

恰当的数据类型

比如存储一个对象类型的数据,我们推荐三种存储方式

  • json 字符串:实现简单粗暴,缺点:数据耦合吗,不够灵活

  • 字段打散:可以灵活访问对象中的任意字段,缺点:占用空间大,没办法做到统一控制

  • hash:低层使用 ziplist ,占用空间小,可以灵活的访问对象中的任意字段,缺点:代码相对复杂

这么对比下来,hash 完美胜出,但是这还不是最优解,下面是 hash 可能还存在的问题

hash 的 entry 数量超过 500 时,会使用哈希表而不是 Ziplist ,这样也会导致内存占用过大的问题,但是我们可以通过 hash-max-ziplist-entries 配置 entry 上限,但是 entry 过多的话还是会导致 bigkey 的问题再次出现

那么如何优化呢?

拆分 string 类型,假如有 hash 类型的 key ,其中有 100 万对 field 和 value ,field 是自增 id,这个 key 存在什么问题?如何优化呢?

有一个方案就是将每一个 hash 再次才分成多个小的 hash ,这样外层的一个 key 就可以掌管多个内部的 key ,也就是相当于掌管里面所有的 hash ,我们只需要对内部的 hash 的做优化就可以了,如果内部 hash 过于庞大的话,再考虑对外部的 hash 做优化就可以基本解决这个问题

  • key 的最佳实践

    • 固定格式的 key

    • 足够精简,不超过 44 个字节

    • 不包含特殊字符

  • value 的最佳实践

    • 合理拆分数据,拒绝 big key

    • 选择适合的数据类型

    • hash 结构的 entry 最好不要超过 1000

    • 设置合适的超时时间

相关推荐
得物技术9 分钟前
基于Redis内核的热key统计实现方案|得物技术
redis
Allen Bright26 分钟前
Redis主从架构
数据库·redis·架构
ZHOU西口30 分钟前
MySQL系列之远程管理(安全)
数据库·mysql·安全·tls·加密连接·require_secure
fcopy38 分钟前
Golang项目:实现生产者消费者模式
缓存·golang
Karoku0661 小时前
【docker集群应用】Docker网络与资源控制
运维·数据库·docker·容器
2301_793086871 小时前
springboot+redis+lua实现分布式锁
spring boot·redis·lua
扬子鳄0081 小时前
Spring Boot自动配置机制
java·数据库·spring boot
秋意钟2 小时前
sql漏洞
数据库·oracle
cdut_suye2 小时前
C++11新特性探索:Lambda表达式与函数包装器的实用指南
开发语言·数据库·c++·人工智能·python·机器学习·华为
点点滴滴的记录2 小时前
延迟队列调研
redis