Redis热点问题怎么破？那些实用又接地气的解决办法分享

（来源：知乎专栏《高并发架构设计》）

Redis热点问题说白了就是某个Key突然被疯狂访问，就像超市搞特价时一大群人挤在同一个货架前，结账系统直接卡死，我见过最离谱的案例是电商平台秒杀月饼，一个商品Key每秒被点击几十万次，Redis直接告警，差点让整个活动崩掉，解决这种问题不能光靠加机器,得用巧劲。

实战中常见的三种热点场景

1. 瞬时热点（来源：某社交平台技术复盘） 比如明星官宣结婚，全网同时刷热搜榜，那个存储热搜列表的Redis Key瞬间变成"烫手山芋"，这种热点往往来得快去的也快,但爆发时杀伤力极强。

2. 持续热点（来源：某电商大促技术方案） 像双11爆款商品页面，可能连续几小时被高频访问，更麻烦的是某些基础数据，比如全国省份列表Key，虽然平时没事,但遇到全员推送活动时就成了瓶颈。

3. 意外热点（来源：某资讯平台故障报告） 曾经有新闻APP因为某个突发新闻的配图ID被重复使用，导致这张图片的缓存Key被刷爆，这种热点完全无法预测,全靠系统自愈能力。

接地气的解决方案

1. 本地缓存兜底（来源：某短视频APP架构设计） 在业务服务本地用Guava或Caffeine加一层短时缓存，设置2-3秒过期，当Redis热点Key请求打到服务器时，同一台机器的后续请求直接走本地缓存，我们实践后发现，这招能扛住80%的突发流量,特别适合热点商品详情页。

2. Key分片降温（来源：某票务系统优化案例） 把hot_product:123这个Key拆成hot_product:123_v1、hot_product:123_v2...hot_product:123_v5，然后在代码里随机访问其中一个分片，就像把排队人群分流到5个窗口，虽然数据有冗余，但Redis压力直接降到1/5。

3. 逻辑过期策略（来源：某在线教育平台实战） 不给Key设置物理过期时间，而是在Value里藏个时间戳，当发现Key变热点时，后台异步更新缓存，前台永远返回旧数据,我们用这招解决了课程目录缓存更新时的数据库雪崩问题。

4. 客户端限流（来源：某金融系统架构文档） 在SDK层面对单个Key的访问频率计数，超过阈值就直接返回默认值，比如验证码短信发送接口，同一个手机号60秒内最多读1次Redis,多余的请求根本到不了服务器。

5. 热点探测三板斧（来源：某云服务商最佳实践）

   • 监控告警：给Redis实例的QPS设置突增告警，我们团队用10秒内增长50%作为阈值
   • 实时分析：用Redis自带的hotkeys命令定时扫描（生产环境慎用）
   • 业务预测：提前给促销商品分配独立的Redis集群，就像春节前给热门航线加开航班

血泪教训总结

1. 永远别把热点Key和大Value绑在一起，有个团队把500KB的商品详情和库存数据放在同一个Key里，结果秒杀时网络带宽先被打满
2. 热点Key不要用持久化策略，曾经有系统因为热点Key频繁触发AOF重写导致CPU飙高
3. 解铃还须系铃人，最终解决了一个历史热点问题后发现是前端代码循环调用API导致的

最后分享个真实场景（来源：某团队内部技术沙龙）：我们发现某个Key每秒访问6万次，查到最后居然是某个实习生写的JavaScript脚本里用setInterval每秒请求60次，而该页面被1千多个用户长期打开，所以解决热点问题有时候不是技术问题,是管理问题。