Redis–14–BigKey 和热点Key

本文介绍: bigkey是指key 对应的value所占的内存空间比较大，例如一个字符串类型的value 可以最大存到512MB，一个列表类型的val ue最多可以存储23-1个元素。如果按照数据结构来细分的话，一般分为字符串类型 bigkey和非字符串类型 bigkey。字符串类型：体现在单个val ue值很大，一般认为超过10KB就是bigkey，但这个值和具体的OPS相关。非字符串类型：哈希、列表、集合、有序集合,体现在元素个数过多。bigkey无论是空间复杂度和时间复杂度都不太友好，下面我们将介绍它的危害。

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

Bi gKe y

如果按照数据结构来细分的话，一般分为字符串类型bigkey和非字符串类型bi g key。

字符串类型：体现在单个val ue值很大，一般认为超过10KB就是bi g key，但这个值和具体的OPS相关。

非字符串类型：哈希、列表、集合、有序集合,体现在元素个数过多。

bi g key无论是空间复杂度和时间复杂度都不太友好，下面我们将介绍它的危害。

b i g key的危害体现在三个方面:

假设一个big k e y为1MB，每秒访问量为1000，那么每秒产生1000MB 的流量,对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署,也就是说一个bigk e y 可能会对其他实例造成影响,其后果不堪设想。

bigk e y的存在并不是完全致命的：

如果这个bigkey存在但是几乎不被访问,那么只有内存空间不均匀的问题存在,相对于另外两个问题没有那么重要紧急,但是如果bigkey是一个热点key(频繁访问)，那么其带来的危害不可想象,所以在实际开发和运维时一定要密切关注bigkey的存在。

redis–cli –bigkeys可以命令统计bigkey的分布。

但是在生产环境中，开发和运维人员更希望自己可以定义bigkey的大小，而且更希望找到真正的bigkey都有哪些,这样才可以去定位、解决、优化问题。

如果是要遍历多个，则尽量不要使用keys的命令，可以使用 scan的命令来减少压力。

Redis 从2.8版本后，提供了一个新的命令 sc an，它能有效的解决keys命令存在的问题。和keys命令执行时会遍历所有键不同,sc an采用渐进式遍历的方式来解决 keys命令可能带来的阻塞问题，但是要真正实现keys的功能,需要执行多次 sc an。可以想象成只扫描一个字典中的一部分键，直到将字典中的所有键遍历完毕。sc an的使用方法如下:

scan cursor [match pattern] [count number]

Matc h pattern ：是可选参数,它的作用的是做模式的匹配,这点和keys的模式匹配很像。

Count number ：是可选参数,它的作用是表明每次要遍历的键个数,默认值是10,此参数可以适当增大。

可以看到，第一次执行sc an 0，返回结果分为两个部分:

第二个部分是10个键。接下来继续

直到得到结果 cursor变为0，说明所有的键已经被遍历过了。

除了scan 以外，Redis提供了面向哈希类型、集合类型、有序集合的扫描遍历命令，解决诸如hgetall、smembers、zrange 可能产生的阻塞问题，对应的命令分别是hscan、ss can、zscan，它们的用法和scan基本类似，请自行参考Redis官网。

渐进式遍历可以有效的解决keys命令可能产生的阻塞问题，但是scan并非完美无瑕，如果在scan 的过程中如果有键的变化(增加、删除、修改)，那么遍历效果可能会碰到如下问题:新增的键可能没有遍历到，遍历出了重复的键等情况，也就是说scan并不能保证完整的遍历出来所有的键，这些是我们在开发时需要考虑的。