大key的标准
一般的业务场景下，对并发和容量要求都不大：
单个string的value超过1MB
容器数据结构元素数量超过10000
在高并发且低延迟的场景里：
单个string的value超过10KB
容器数据结构元素数量超过5k或是整体value超过10MB
阿里云的云Redis：
Key本身的数据量过大：一个String类型的Key，它的值为5 MB。
Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10,000个。
Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有2,000个但这些成员的Value（值）总大小为100 MB。
大Key的影响
读取成本高
时延高，因为执行命令时间更长
消耗更多的带宽，导致自身服务变慢，从而影响相关服务
大Key相关操作容易阻塞，从而导致无法正常响应
慢查询变多
删除的时候容易导致主库长时间的阻塞，进而可能引发同步中断或主从切换
占用更多的存储空间，内存达到maxmemory参数定义的上限引发操作阻塞或重要的key被逐出，甚至是OOM
集群架构下，某个数据分片的内存使用率远超其他数据分片，导致数据分片的内存资源分配不均衡
大key产生的原因
业务设计不合理：最常见的原因，不经过合理的拆分，就把大json塞在一个key里，甚至塞二进制文件数据。没有对key中的成员进行合理的拆分，造成个别key中的成员数量过多。
没有处理好value的动态增长问题。如果一直添加value数据的话，没有定期的删除机制、合理的过期机制，或是没有设定合适的阈值，早晚会变成大key。例如：微博明星的粉丝列表、热门评论、直播弹幕
程序bug：某些异常情况导致某些key的生命周期超出预期，或是value数量异常增长。使用LIST类型key的业务消费侧发生代码故障，造成对应的key的成员只增不减。
如何找到大key
云Redis提供的服务
云服务提供的实时Top Key统计服务或是离线全量Key分析服务
通过redis-cli的bigkeys命令
Redis提供了bigkeys参数能够使redis-cli以遍历的方式分析Redis实例中的所有key，并返回key的整体统计信息与每个数据类型中Top1的大key，bigkeys只能分析并输入六种数据类型（STRING,LIST,HASH,SET,ZSET,STREAM），命令示例
redis-cli -h r-***************.redis.rds.aliyuncs.com -a <password> --bigkeys
注意：若只需要分析STRING类型的大key或是找出成员数量超过10个的HASH Key，则bigkeys参数无法直接实现该类需求。
Redis RDB Tools工具
支持定制化分析的开源工具 GitHub - sripathikrishnan/redis-rdb-tools: Parse Redis dump.rdb files, Analyze Memory, and Export Data to JSON 通过分析RDB文件，扫描出Redis的大key
可以根据自己的精细化需求，全面地分析所有Key的内存占用情况，而且对线上服务无影响。但是因为RDB文件较大时耗时较长。
