目录
[优雅的 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
-
设置合适的超时时间
-