要点

1. 预防策略：通过监控系统和设置告警机制，提前发现并预防大Key和热Key问题。
2. 治理方法：采用技术手段进行优化，例如采集热Key信息并实现本地缓存、提前进行数据分片，或启用读写分离架构。

## 核心定义
- 大Key：Value过大（String>1MB/集合>5000元素）→ 内存压力、操作阻塞
- 热Key：QPS>10000 → 单点瓶颈、缓存击穿
- 大热Key：数据量+访问频次叠加 → 服务阻塞、系统崩溃
## 产生原因
- 大Key：误用存储、规划不足、数据未清理、消费侧故障
- 热Key：爆款/活动/热点事件导致访问量突增
## 业务影响
- 大Key：内存不均、OOM、命令延迟、持久化/复制延迟
- 热Key：CPU/带宽耗尽、缓存击穿、存储层过载、业务超卖
## 优化方案
- 大Key：清理过期数据、压缩序列化、拆分Key、转存OSS+异步删除
- 热Key：本地缓存、Key拆分分摊流量、读写分离、Sentinel限流、热Key复制
## 预防策略
- 监控告警：设置阈值告警
- 提前规划：合理设计Key结构
- 容量评估：高并发场景资源预判

定义概述

大Key 定义

大Key（Big Key）的核心特征是Key所存储的Value体积过大。通常基于静态经验阈值判断，例如：

• String类型的Value长度超过1MB。
• 集合类型（如Hash、List、Set）的元素数量超过5000个，或总内存占用超过100MB。

热Key 定义

热Key（Hot Key）的核心特征是Key被访问的频率极高，远超集群平均水平。通常基于静态QPS阈值判断，例如单个Key的请求量超过10000 QPS。

对业务的影响

Tair和Redis的最小数据分布粒度为Key，单个Key存储在特定数据分片中且不可拆分。业务规划不足、无效数据堆积或访问量突增等因素会导致大Key和热Key问题。

产生原因

• 业务上线前规划不足，未合理拆分Key成员，导致成员数量过多。<br>
• 未定期清理无效数据，导致HASH类型Key成员持续增加。<br>
• LIST类型Key的消费侧代码故障，导致成员只增不减。 | | 热Key | - 预期外访问量陡增（如爆款商品、热点新闻、直播活动点赞、游戏区域战斗等）。 |

带来的影响