热 key 的处置思路
定位到热 key 之后，处置的方向取决于读还是写：读热点用分摊，把一次访问复制成多份，本地缓存或键的多副本都能把压力摊到多台机器；写热点要合并，把高频写收敛成低频写或按业务维度分桶，让不同请求落到不同的键上。极端场景下可以把热点数据前移到网关或 CDN，让 Redis 根本不承受这份流量。
基本信息
| 适用平台 | Redis 全版本；Cluster 下需注意槽位分布 |
|---|---|
| 读热点手段 | 本地缓存、键多副本、客户端缓存 |
| 写热点手段 | 合并写、批量提交、按业务分桶 |
| 失效手段 | Pub/Sub 广播或 Client Tracking |
| 注意 | 多副本之间的数据同步延迟必须可控 |
典型使用场景
- 秒杀商品详情被全站高频读取，单个键承载数万 QPS
- 全局配置或开关类数据被所有实例频繁读取
- 排行榜或计数器单键高频更新，写集中在一个分片
- 大促前对已知热点做预案，提前铺开多副本
- 热点变更频率低但读取量极大的字典类数据
读热点：多副本与本地缓存
读热点：多副本与本地缓存
# 方案一：键拆成多个副本，读请求随机打散
# key:hot:config:1 ... key:hot:config:10
GET hot:config:3 # 客户端随机选择一个副本读取
# 写时同步更新全部副本，或维护基准键并异步分发
SET hot:config:3 "v2"
SET hot:config:7 "v2"
# 方案二：本地缓存挡掉绝大部分读，短 TTL 兜底
# 变更时通过广播通知各节点失效
PUBLISH cache:invalidate "hot:config"
# 方案三：写热点合并
# 高频写先在应用侧聚合，再按固定间隔批量落库/落 Redis处置手段对照
| 手段 | 适用 | 代价 |
|---|---|---|
| 本地缓存 | 读多写少且可容忍秒级延迟 | 多节点数据短暂不一致 |
| 多副本 key | 读取极高但不便本地缓存 | 写路径要同步全部副本 |
| 写合并与批量 | 计数、库存类高频写 | 实时性下降，需要缓冲层 |
| 按业务分桶 | 账户余额、库存等可拆分计数的场景 | 汇总读取逻辑变复杂 |
| 前移到网关或 CDN | 静态或变化极少的热点数据 | 更新链路需要额外设计 |
热 key 方案要按读写比例设计：配置类读多写少适合本地缓存；库存类写热点建议分桶加异步汇总，硬扛单键写入最终一定会在峰值崩掉。
多副本方案必须同步所有副本再认为写成功：不同步就上线会出现部分读请求命中旧值，且这类不一致只在热点被分散访问时才暴露。