热点 Key 如何发现和治理？

简化版

热点 Key 是少量键承受远高于平均值的访问，可能先打满单分片 CPU、网卡或连接，而全局指标仍正常。发现要结合客户端按 Key 采样、代理/服务端统计和分片 max/avg 倾斜；治理按读写语义选择本地缓存、请求合并、只读副本、Key 拆分或限流，并处理一致性与热点转移。

详细版

热度没有统一 QPS 阈值，应以单 Key 占分片容量比例和 SLO 影响判断。读热点常见于爆款商品、配置和榜单，写热点常见于计数器、秒杀库存和同一用户状态；读热点容易复制分散，写热点必须保持原子语义，不能随便拆成多个可写副本。

发现手段分三层：客户端 SDK 对 key hash/前缀做有界采样，避免记录敏感明文；代理聚合各实例流量；Redis 侧看 --hotkeys（需 LFU policy）、MONITOR 的短时诊断、commandstats 与节点 CPU/网络倾斜。服务端采样可能有成本，不能长期全量 MONITOR。

治理先快速限流和保护下游，再根据类型处理：静态读热点用 L1 本地缓存和失效通知；可容忍旧值的热点做多副本/多 Key 读取；高并发回源用 singleflight；计数写用分片计数后异步聚合；库存等强一致写保持权威点并在入口削峰。全过程监控热点 QPS、命中、分片资源和一致性误差。

完整版教学

一、热点为何会绕过集群平均容量

哈希分片只能把不同 Key 分散，同一个 Key 始终落到一个 slot/节点。集群有 20 个分片并不意味着一个 Key 能自动使用 20 倍能力；某 Key 占 8 万 QPS 时，它可能打满单节点，而其他 19 个节点仍很空闲。

因此平均 CPU 30% 没有安全意义。要比较最热分片与平均分片、单 Key QPS 占节点吞吐比例，以及该 Key 的响应字节。大而热的 Key 会同时占 CPU、网络和客户端缓冲。

记忆钩子：分片解决“很多 Key 怎么分”，热点治理解决“同一个 Key 怎么扛”。

二、读热点和写热点必须分开

读热点通常允许复制：同一份商品信息可放进每个应用本地缓存，或从多个只读副本读取。写热点要求多个并发更新协调；简单复制会产生冲突和丢失更新，尤其是库存、余额和锁。

热点类型	例子	主要瓶颈	常见方向
小对象读热点	配置、商品基础信息	QPS/包率	L1 缓存、请求合并
大对象读热点	大榜单、聚合页	带宽/缓冲	拆字段、CDN/对象存储
可合并写热点	浏览计数	单 Key 写 QPS	分桶计数、异步聚合
强一致写热点	秒杀库存	串行化/锁竞争	排队、预分桶、限流
突发热点	新闻事件	检测速度	动态识别与自动策略

治理方案先由一致性要求决定，不能看到热点就统一加本地缓存。

三、客户端侧怎样低成本发现

客户端最接近业务 Key，可在 SDK 按固定概率采样并聚合 Count-Min Sketch、TopK 或滑动窗口。为了避免高基数指标爆炸，不要把原始 Key 直接作为 Prometheus label；可记录 hash、业务前缀和受控 TopN，并由安全工具按需解析。

假设总流量 100 万 QPS，1% 采样得到约 1 万样本/秒。某 Key 占 10% 流量，期望每秒约 1000 个样本，足以快速识别；占十万分之一的普通 Key 期望很低，不会挤满 TopN。

采样需要按实例汇总，否则某 Key 分散在 100 个应用后，每个实例看起来不热。窗口也不能只算累计值，应有 10 秒、1 分钟等短周期捕捉突发。

四、服务端与代理怎样交叉验证

代理层可以统计路由后的 Key hash、命令、请求与字节，是跨客户端的统一视角。Redis redis-cli --hotkeys 依赖 LFU 计数且是扫描式诊断；MONITOR 会返回所有命令，生产长期使用开销和敏感信息风险很高，只适合受控短时排查。

若不能拿到 Key 级数据，可先通过节点 CPU、网络、ops 和 slot QPS 找到热点分片，再在该分片做限时采样。结合应用 trace 判断是单 Key 还是大范围命令变化。

全局告警 -> 找 max/avg 倾斜 -> 锁定节点/slot
        -> 客户端/代理 TopK -> 确认业务 owner
        -> 读写与 value 大小分类 -> 选择治理

五、读热点有哪些治理层次

第一层是进程内 L1 缓存，能把 100 个应用实例对 Redis 的 10 万 QPS 降到按刷新频率访问，但需要 TTL、容量、版本和失效通知。第二层是 singleflight，合并同实例同 Key 的并发加载。第三层是复制为多个物理 Key或只读副本随机读取。

复制 Key 如 hot:k:0..15 适合基本只读且允许短暂不一致的数据。更新时要写/删 16 份，存在写扩散；可用版本化 Key和后台发布新版本，读端只读取已完成版本，避免半数新半数旧。

对于大静态内容，Redis 可能不是最佳承载，CDN 或对象存储更适合高带宽分发。治理不是一定留在原组件内。

六、写热点怎样守住正确性

可交换、可结合的计数可分成 16 个桶，写入按请求哈希分散，读取求和；代价是读扩散和短暂误差。库存不能简单分桶后各自随意扣减，除非先把总库存按桶预分配，并设计桶间调拨与售罄收口。

假设库存 1000 件分 10 桶，每桶 100，某桶先卖完而其他桶还有余量，入口需换桶或后台调拨；若每桶都错误地认为有 1000，就会超卖十倍。强一致热点常需要入口排队、令牌预发和条件扣减，而不是无限横向复制。

UPDATE stock
SET available = available - 1
WHERE sku_id = 42 AND available >= 1;

写入结果还需幂等，防止超时重试重复扣减。

七、自动治理与恢复

热点策略要有触发、最大持续时间和退出条件。检测到突发热点可临时提高 L1 TTL、开启请求合并或限流，但不能让旧值策略永久存在。热点下降后逐步退出，避免同时失效导致回源峰值。

指标包括 Top Key QPS/bytes、分片 max/avg、L1 命中、失效延迟、分桶误差、限流数和回源 QPS。演练热点瞬间放大 20 倍、热点 Key 转移以及更新期间一致性，验证自动策略不会保护错对象。

top_key_qps: 82000
top_key_bytes_per_sec: 94000000
max_shard_to_avg_qps: 4.8
l1_hit_rate: 96.2%
hot_policy_expires_in_seconds: 420

八、常见误区与追问

误区：哈希分片会自动把热点 Key 分散。 同一个 Key 只能落到一个路由位置，必须在业务层复制或拆分。
误区：长期使用 MONITOR 是安全的热点监控方案。 它开销高且可能暴露参数，应使用采样、代理统计或短时诊断。
误区：本地缓存适合所有热点。 高风险实时数据和高频写数据会产生一致性问题，需按语义选择。
误区：把计数拆成多 Key 就没有代价。 写被分散，但读取需要聚合，并产生精度、新鲜度和调桶问题。
追问：Hot Key 与 Big Key 有何区别？ Hot Key 是访问频率/带宽集中，Big Key 是单值体积或成员多，可以分别存在也可叠加。
追问：为何不把原始 Key 放监控标签？ 高基数会拖垮监控系统，还可能泄露用户或业务信息。
追问：突发热点如何在秒级发现？ 客户端短窗口采样 TopK、代理聚合和分片倾斜告警结合，并预置自动限流/本地缓存策略。

九、加强记忆

热点治理按“找最大不看平均、先分读写、再分散或串行”推进。客户端与代理采样定位 Key，服务端资源倾斜交叉验证；读热点可复制、本地缓存和合并请求，写热点只有可合并数据才适合分桶，强一致写要排队限流并守住原子条件。自动策略还必须能过期和安全退出。

简化版

详细版