热 Key 与热点数据是什么
热 Key 指少数键承载远高于平均水平的访问量，例如首页配置、爆款商品、活动库存。它在不同层造成不同问题：缓存层上，热点键所在的分片负载远高于其他分片，扩容对缓解热点无效；存储层上，同键的并发更新造成行锁竞争与排队。治理思路是分层摊平：读侧用进程内本地缓存与热点键多副本分流，写侧用合并写与延迟聚合降低竞争，同时从数据分布上评估分片键是否需要调整。
基本信息
| 识别口径 | 单键访问量占比、分片负载偏离度、行锁等待与冲突率 |
|---|---|
| 缓存侧 | 本地缓存承接读、热点键复制到多个分片随机读取 |
| 存储侧 | 合并写、延迟聚合或改写为异步累加 |
| 隔离手段 | 热点依赖独立实例或线程池，限制影响面 |
| 根因治理 | 评估分片键与数据分布，必要时改键或加盐 |
典型使用场景
- 大促爆款商品：详情与库存查询集中，需要提前复制与预热
- 首页与活动页配置：读取极高频、变更少，用本地缓存最合适
- 秒杀库存扣减：同键并发更新造成行锁排队，需合并写或拆分库存
- 排行榜与计数：单键高频自增，可先本地聚合再批量写
- 热点账号与话题：社交场景中少数对象承载大部分流量
- 定时任务集中处理：同一批键在短时间内被反复读写
治理要点
治理要点
# 1 识别：按 key 维度统计访问量与分片负载，列出头部键
# 2 读侧分流：进程内本地缓存（设短过期）承接极高频小对象读
# 3 读扩散：热点键复制 N 份（如 key:1 到 key:N），读侧随机选择
# 4 写侧合并：短窗口内聚合同键写请求，再单次提交，降低行锁竞争
# 5 隔离：热点依赖使用独立实例或独立线程池，避免波及普通请求
# 6 根因：评估分片键，必要时改键或加盐，避免结构性热点
# 7 活动准备：按历史访问榜预判热点并提前预热，活动后复盘更新清单问题层次与对策
| 层次 | 表现 | 对策 |
|---|---|---|
| 本地缓存 | 热点数据频繁回源 | 本地缓存加短过期，更新时主动失效 |
| 缓存分片 | 单分片负载远高于其他分片 | 热点键多副本读扩散随机选择 |
| 存储行锁 | 同键并发更新排队与超时 | 写合并、延迟聚合或改用累加式更新 |
| 资源竞争 | 热点请求挤占普通请求资源 | 独立实例或独立线程池隔离 |
| 数据分布 | 分片键倾斜形成结构性热点 | 改分片键或加盐，重新评估分布 |
热点的另一类来源是数据分布倾斜：分片键设计不当会造成结构性热点，这种情况下横向扩容无法缓解，只能从分片规则上解决。
本地缓存的热点数据要设短过期并支持主动失效：只靠过期会导致更新后各实例数据长期不一致，用户在不同页面上看到不同结果。