Redis 热 Key 治理发现热点只是第一步一、热 Key 会把集群打成单点Redis 集群看起来是分布式的但一个热 Key 会把压力集中到单个分片。热门商品、配置项、活动库存、排行榜和登录态都可能成为热点。热 Key 的问题不只是延迟升高还可能导致某个节点 CPU 飙高、网络打满进而影响同分片其他 key。治理热 Key 不能只靠扩容。扩容能增加整体容量但单个 key 仍然落在一个分片上。真正的治理要从发现、拆分、缓存策略和降级一起做。二、治理链路监控发现到业务拆分flowchart TD A[Redis 指标异常] -- B[热 Key 发现] B -- C[业务归因] C -- D[本地缓存] C -- E[Key 拆分] C -- F[请求合并] F -- G[降级保护]热 Key 发现可以用 Redis 自带命令、代理层统计、客户端埋点或云厂商工具。只知道某个 key 热还不够要知道它来自哪个接口、哪个业务活动、读写比例和峰值时段。没有业务归因就只能临时救火。读热点和写热点治理不同。读热点可以考虑本地缓存、多级缓存、请求合并和副本读写热点更麻烦可能需要业务拆分、异步聚合或改变数据模型。把写热点当读热点处理容易造成一致性问题。三、代码示例请求合并降低穿透下面是一个简化思路同一时刻同一个 key 只让一个请求回源。public Product getProduct(String id) { String key product: id; Product cached redis.get(key); if (cached ! null) { return cached; } return singleFlight.doOnce(key, () - { Product product database.findProduct(id); redis.setex(key, 60, product); return product; }); }请求合并能减少缓存失效瞬间的回源压力但不能解决长期热读。长期热 Key 可以加本地缓存TTL 设短一点接受秒级延迟。核心是让每次请求不都打到同一个 Redis 分片。Key 拆分适合计数和排行榜等场景。比如把一个全局计数拆成多个 shard key写入时随机分片读取时聚合。代价是读取更复杂数据不再天然强一致。业务必须接受这种取舍。四、降级策略热点活动要提前预案热点通常不是完全随机的。大促、直播、秒杀、新功能发布都会制造热点。活动前要压测热点 key准备本地缓存、限流、降级页面和只读模式。等节点 CPU 打满后再查已经晚了。监控要按分片看。集群平均 CPU 30% 没意义单分片 95% 才是事故信号。网络、慢命令、key 访问频率和连接数都要拆分到节点维度。最后治理后要复盘 key 设计。为什么这个 key 会热是否可以按租户、区域、业务维度拆是否可以把实时查询改成异步刷新热 Key 是症状数据模型才是根。热 Key 治理也要注意一致性。加本地缓存后更新传播会变慢Key 拆分后读取聚合可能出现短暂不一致。不要只看 Redis 压力下降还要看业务是否能接受这些延迟。架构优化的每一步都要把收益和代价写清楚。五、总结Redis 热 Key 治理要从发现走到业务归因再选择本地缓存、请求合并、Key 拆分、限流和降级。扩容只能缓解整体压力不能消除单 key 热点。热点治理的最终答案通常在业务模型里。