Redis热点问题老是犯，咋整才靠谱有效呢？

多位一线运维和架构师的经验总结，以及《Redis开发与运维》等实践指南的核心思想）

Redis热点问题确实让人头疼，数据访问一窝蜂地涌向某个特定的Key，导致单个实例压力山大，响应变慢甚至挂掉，整个应用都可能被拖垮，这事儿不能只靠理论，得来点实实在在的、能落地的办法。

第一招，最直接：别让热点Key太孤单，给它找个“分身”。

这就是“读写分离”和“缓存多副本”的思路，如果你的热点Key主要是读操作非常频繁（比如爆款商品的详情信息），那么最简单的办法就是做主从复制（Replication），你给这个Redis实例配几个从节点，让读请求分散到这些从节点上去，主节点只负责写，这样压力就分摊了，很多客户端本身就支持配置多个读地址,改下配置就能见效。

但有时候，主从复制还不够，或者热点Key的写操作也很多，这时候可以玩得更“野”一点，就是在业务代码层面做文章，在设置这个热点Key的时候，你不用一个Key，而是同时设置多个Key，比如原来的热点Key叫 hot_item:12345，你现在可以同时设置 hot_item:12345_copy1、hot_item:12345_copy2 ... hot_item:12345_copyN，每次写的时候，同时更新这几个Key；读的时候，随机选一个副本Key来读，这样就把请求打散到Redis实例内不同的数据片上了，这个方法简单粗暴，但非常有效，前提是你要在应用层处理好多副本的写入和随机读取的逻辑。（来源：某电商平台应对秒杀场景的实战方案）

第二招，把突然的高峰“烫平”，别让它一下冲垮系统。

热点问题往往伴随着“秒杀”或者“热点事件”这种瞬间的极高并发，这时候，另一个关键思路是“削峰填谷”，你不能让十万个请求在同一毫秒去访问Redis,得让它们排排队。

一个核心武器是“应用层本地缓存”，比如用Guava Cache或者Caffeine，对于极少变化的热点数据（比如商品基础信息），可以在应用服务器的本地内存里也存一份，并设置一个短暂的过期时间（比如几秒钟），这样，绝大部分读请求在本地就直接返回了，根本不会走到Redis那里，Redis的压力自然骤减,这相当于在Redis前面加了一道屏障。

另一个武器是“消息队列”配合“缓存预热”，对于可预知的热点（比如定时开始的抢购），可以提前把数据加载到Redis里，在真正的高峰期，写请求可以先扔到消息队列（如Kafka、RocketMQ）里排队，让后端服务慢慢消费，匀速地去更新Redis,避免瞬间的写压力击穿缓存。

第三招，提前发现“火苗”，别等烧起来再救火。

事后补救总是被动，最好能提前感知到哪里可能要“热”了,这就需要监控和发现机制。

Redis自带的redis-cli --hotkeys命令可以帮你快速找出当前的热点Key，但对于生产环境，这不够自动化，你需要搭建更完善的监控，可以通过监控Redis每个实例的网络流量、CPU使用率、Key的访问频率来判断，如果发现某个实例的指标远高于其他实例,那它很可能承载了热点Key。

更高级的做法是在代理层（如果用了Proxy的话）或者客户端埋点，统计所有Key的访问频次，然后上报给监控系统，一旦发现某个Key的访问量在短时间内异常飙升，监控系统就立刻告警，这样你就能在问题发生前采取行动，比如立刻给它做多副本或者进行限流。（来源：开源监控工具RedisInsight的设计理念）

第四招，终极方案：从架构上动手术，分而治之。

如果以上方法都感觉是“打补丁”，那说明你的数据量和并发量可能真的需要更根本的解决方案了——数据分片（Sharding）。

也就是把整个Redis数据集拆分成多个部分，分布到不同的Redis实例上，你可以用Redis Cluster集群模式，或者通过像Codis这样的代理中间件来实现，分片的规则可以是根据Key的哈希值，或者其他业务逻辑，这样，理论上每个实例只保存一部分数据，也只承担一部分请求，即使出现热点Key，也只会影响其中一个分片，而不会拖垮整个Redis服务，这是解决热点问题的根本性架构手段,但代价是系统复杂度会升高。

别指望一个方法能通吃，靠谱有效的做法是“组合拳”：

1. 日常防护： 做好监控,心里有数。
2. 读多热点： 主从分离 + 应用层多副本,分散压力。
3. 瞬间高峰： 本地缓存 + 消息队列,削峰填谷。
4. 根本解决： 数据量巨大时,采用集群分片。

最关键的是，你要根据自己的业务场景，选择最适合、最经济的一两种或几种方法结合起来用，平时多压测，看看系统的瓶颈在哪,真遇到问题时才不会慌。