缓存有大key?你得知道的一些手段
内容提要
系统内缓存CPU使用率超过报警阀值，需要解决大key使用问题。大key定义为单个String类型Key大小达到20KB且OPS高、单个String达到100KB、集合类型Key总大小达到1MB、集合类型Key中元素超过5000个。大key导致客户端超时阻塞、网络阻塞、工作线程阻塞和内存分布不均。处理方法包括删除不再使用的key、平铺缓存Set和HASH类型的大key、分割大对象为多个key-value、压缩数据大小、定期清理过期key。
延伸解读
大key的判定标准与业务影响
文章明确了大key的量化标准：单个String达到20KB且OPS高或100KB，集合类型总大小1MB或元素超5000个。这些阈值并非随意设定，而是基于Redis单线程模型下的性能考量。大key会引发客户端超时、网络阻塞、工作线程阻塞及内存分布不均，尤其在集群分片中可能导致OOM或数据逐出。理解这些标准有助于在监控中提前识别风险，而非等到CPU报警才被动处理。
平铺与拆分：两种降低单key压力的思路
针对Set/HASH元素过多，文章建议将统一key下的field拆分为独立key，例如品牌名称缓存从hGet改为get。对于复杂大对象如订单，则拆分为多个key-value，通过mGet/mSet批量操作。这两种方式本质都是分散单次操作压力，但需注意：平铺后key数量增加，可能带来管理成本；拆分后需保证数据一致性，且mGet结果顺序必须与传入key顺序对应，否则会解析错误。
压缩数据的收益与CPU代价
文章通过实测数据展示了压缩效果：625KB数据可压缩至约1.7KB，但压缩耗时随数据量增长，解压也需CPU。因此压缩适合存储大但访问频率不高的场景，若调用量大或处于黄金链路，必须配合压测评估接口性能变化。此外，压缩和解压频率过高会抵消内存收益，需权衡存储成本与计算成本。
历史数据迁移与缓存雪崩预防
在将HASH平铺为独立key时，文章强调必须先刷新历史数据再上线新代码，否则新key无数据会导致请求穿透到数据库，引发缓存雪崩。刷新过程通过hGetAll遍历旧key并逐个set新key，需注意此操作可能耗时较长，建议在低峰期执行，并考虑分批处理以避免阻塞Redis。同时，旧key确认无使用后再删除，避免误删仍被依赖的数据。
Q&A
什么是大key，它的定义是什么？
大key是指单个String类型Key大小达到20KB且OPS高，单个String达到100KB，集合类型Key总大小达到1MB，集合类型Key中元素超过5000个。
大key会导致哪些问题？
大key会导致客户端超时阻塞、网络阻塞、工作线程阻塞和内存分布不均。
如何处理大key问题？
处理大key的方法包括删除不再使用的key、平铺缓存Set和HASH类型的大key、分割大对象为多个key-value、压缩数据大小、定期清理过期key。
为什么要定期清理过期key？
定期清理过期key可以避免Redis性能下降，保持系统的高效运行。
如何将复杂的大对象优化为多个key-value？
可以将复杂的大对象分拆成多个key-value，使用mGet和mSet操作降低单个redis的IO影响。
压缩数据有什么好处？
压缩数据可以显著减少存储大小，但需注意压缩和解压的频率对CPU性能的影响。
