大KEY判定条件

• 单个String类型的Key大小达到20KB并且OPS高

• 单个String达到100KB

• 集合类型的Key总大小达到1MB

• 集合类型的Key中元素超过8000个

大KEY影响

• 严重影响 QPS 、TP99 等指标，对大Key进行的慢操作会导致后续的命令被阻塞，从而导致一系列慢查询。

• hgetall 、 smembers 等时间复杂度O(N)的命令使用不当，容易造成使用率过高。

• 大Key发生热点，大 String，value 大于 20K。当OPS为 10000，流量即为 200M, 达到单实例的流量配额. 导致 JIMDB 无法正常提供服务。

• 集群各分片内存使用不均。某个分片占用内存较高或OOM，发送缓存区增大等，导致该分片其他Key被逐出，同时也会造成其他分片的资源浪费。

• 集群各分片的带宽使用不均。某个分片被流控，其他分片则没有这种情况，且影响宿主机上的其它应用。

• 数据迁移失败 过大的Key（如超过1G），在迁移、缩容、扩容，主从全量同步在序列化过程中，内存上涨，数据同步失败，且存在 OOM 风险

大KEY扫描入口

泰山平台-存储服务-JIMDB集群列表-拓扑

• 全集群扫描

• 只有集群的拥有者才可以进行全集群扫描，扫描后点击查看扫描进度进行扫描结果的下载，可以单个实例进行下载，也可以通过“下载扫描结果”一次性下载所有实例

• 单实例扫描

• • 

大KEY处理建议

• String类型的大Key：可以尝试将对象分拆成几个Key-Value， 使用MGET或者多个GET组成的pipeline获取值，分拆单次操作的压力，对于集群来说可以将操作压力平摊到多个分片上，降低对单个分片的影响。

• 集合类型的大Key，并且需要整存整取要在设计上严格禁止这种场景的出现，如无法拆分，有效的方法是将该大Key从JIMDB去除，单独放到其他存储介质上。

• 集合类型的大Key，每次只需操作部分元素：将集合类型中的元素分拆。以Hash类型为例，可以在客户端定义一个分拆Key的数量N，每次对HGET和HSET操作的field计算哈希值并取模N，确定该field落在哪个Key上。

• 禁止使用DEL直接删除大Key，可能会造成JIMDB阻塞,建议使用SCAN的方式进行循序渐进式删除。

• 有些大Key是累积产生的，建议合理设置过期时间并对过期数据定期清理