Redis调优-BigKey如何处理？(2)

Redis调优-BigKey如何处理

127.0.0.1:6379> dbsize
(integer) 1000000

尝试用keys *遍历，耗时8.55s

由此可见，生产环境的数据量可能不止这些。可想遍历一次可能的耗时。

那么，如何正确遍历呢？ 使用SCAN命令。

SCAN cursor [MATCH pattern] [COUNT count] [TYPE type]

SCAN 命令是一个基于游标的迭代器，每次被调用之后， 都会向用户返回一个新的游标， 用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数， 以此来延续之前的迭代过程。

简单演示

127.0.0.1:6379> scan 2 match * count 10
1) "720898"
2)  1) "key772152"
    2) "key318823"
    3) "key851172"
    4) "key137276"
    5) "key658069"
    6) "key486655"
    7) "key795861"
    8) "key300972"
    9) "key488665"
   10) "key479460"
   11) "key15673"

什么是大Key，多大是大Key?

注意：Redis中的大key，实际上指的是key所关联的value值特别大，或者是某种数据结构（如hash, set, zset, list）中存储了过多的元素。

详情可参照《阿里Redis开发规范》

一般来讲，String类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。

为什么会产生BigKey？

大key的产生一般与业务方设计有关，对vaule的动态增长问题预估不足。造成大key问题的原因有：

• 数据结构设计不合理。在不适用的场景下使用Redis，易造成Key的value过大，如使用String类型的Key存放大体积二进制文件型数据；
• 业务规划设计不足。没有对Key中的成员进行合理的拆分将大key变成小key，从而造成个别Key中一直往value里面塞数据，没有删除机制，未定期清理无效数据，导致不断增加。
• 上线前期预估不足。如头条重大新闻，造成value值动态突增。如：百度热搜

• 汇总统计类，随着时间推移value逐渐增加

产生大Key会有什么问题？

• 内存不足（因为redis基于内存）
• 删除超时
• 网络阻塞
• 集群节点容量倾斜甚至宕机

因此需引起足够重视。

如何判定redis变慢了？

1. Redis 基准性能测试

• 测试基准

了解Redis 在生产环境服务器上的基准性能，才能进一步评估，当其延迟达到什么程度时，才认为Redis确实变慢了。例如：按自身硬件配置，可能延迟是