Redis热点缓存老是出问题，咋整才好解决这些烦人的瓶颈呢

第一，你得先知道热点在哪，不能瞎忙活。

很多时候,我们感觉系统卡顿了，猜到可能是Redis的某个热点key扛不住了，但具体是哪个key？访问有多频繁？你心里是没数的，第一步必须是“监控和发现”，你不能等到服务器报警了才去翻日志，那太被动了。

这里有个土办法但很有效：提前在业务代码里埋点，对那些你怀疑可能是热点的key（比如秒杀的商品ID、全站通知等），每次访问时都用一个计数器记录一下，当某个key在短时间内访问次数暴增，超过你设定的阈值（比如正常情况每秒几十次，突然变成每秒几万次），就立刻报警通知你，更省事的办法是利用Redis 4.0以上版本自带的redis-cli --hotkeys功能，它能帮你快速找出当前实例中的热点key。（来源：Redis官方文档）

除了主动发现,监控Redis的各项指标也是必须的。CPU使用率、网络输入/输出流量、延迟时间（latency），如果CPU飙高，同时延迟猛增，那八成是某个热点key正在被疯狂读取或写入，市面上有很多现成的监控工具，比如Prometheus配上Grafana做图表，能让你一眼看清Redis的健康状况。

第二，找到了热点，接下来就是对症下药。

最常见的场景是热点读，就是同一个key被海量用户同时来读，比如一个大V发了条微博，几百万粉丝同时刷新首页都要拉取这条内容。

• 最简单的招数：本地缓存。 在查询Redis之前，先加一层本地缓存（比如用Caffeine或Guava Cache），让请求先打到应用服务器本地内存里，如果本地有，就直接返回，根本不用去烦Redis，这样就把绝大部分压力消化在了应用层，但要注意，本地缓存的数据一致性是个问题，如果数据更新不频繁（比如商品名称、配置信息），或者允许短时间的不一致（比如新闻头条），用这招效果立竿见影。（来源：常见的分布式缓存架构设计）
• 对付超级热点：Key拆分。 如果一个key实在太热，比如秒杀场景下的“商品库存_1001”，你可以把它拆成多个key，原来叫 stock_1001，现在你把它拆成 stock_1001_segment1， stock_1001_segment2 ... stock_1001_segment10，相当于把一份库存分散到10个key里，用户来查询或扣减库存时，通过一个简单的哈希算法（比如用户ID尾号）路由到其中一个key上操作，这样就把对一个点的压力，分散到了10个点上，性能能提升很多倍，这增加了业务逻辑的复杂性，比如计算总库存时需要把10个key的值加起来。

另一种烦人的场景是热点写，比如微博热搜榜，每秒钟有无数点赞、转发，都要去更新同一条微博的计数。

• 核心思路：化多为少，合并写操作。 别来一次请求就直接写一次Redis，可以在应用层做一个“蓄水池”，比如用一个内存队列，把一段时间内（比如100毫秒）对这个key的所有更新操作（1，+1，+1）先收集起来，然后由一个后台线程定时地合并成一次更新操作（比如直接+3）去写Redis，这样就把成千上万次的写请求，合并成了少数几次，极大地减轻了Redis的压力，这种技术通常叫“写缓冲”或“合并写”。（来源：高并发系统设计经验）

第三，有些问题是Redis本身部署和用法不对造成的。

• 别用大Key和慢查询给自己挖坑。 一个value存了几兆甚至几十兆的数据（比如一个超长的列表或集合），这就是“大Key”，每次读取网络传输压力大，删除它可能导致Redis卡顿，同样，用keys *这种命令，或者在Redis里做复杂的计算，都是“慢查询”，会阻塞住其他请求，解决办法就是拆分大Key，避免使用阻塞命令，用scan代替keys。
• 检查你的持久化设置。 如果用的是AOF持久化，并且配置了appendfsync always（每次写操作都刷盘），虽然数据最安全，但会对性能有较大影响，对于缓存场景，数据可以丢失一点，通常建议用appendfsync everysec（每秒刷盘），在性能和数据安全间取得平衡。
• 升级硬件或架构。 如果经过上面优化，单机Redis还是顶不住，那就得考虑“升舱”了，一是垂直扩展：升级CPU更好的服务器，或者使用更高速的SSD硬盘，二是水平扩展：采用Redis集群模式，把数据分片到多个节点上，这样单个热点的压力就不会集中在一台机器上了，对于纯热点读，还可以部署多个只读副本（从节点），通过读写分离来分担主节点的压力。

总结一下解决这个烦人问题的核心思路：

1. 先诊断： 靠监控工具和命令，精准定位到是哪个key在“发烧”。
2. 再下药： 热点读多用本地缓存和Key拆分；热点写想办法合并操作。
3. 查基础： 确保没有大Key、慢查询这些低级错误，持久化配置合理。
4. 最终手段： 前面都搞不定，就考虑升级硬件或部署集群架构。

解决缓存热点没有一劳永逸的银弹,关键是根据你的具体业务场景，灵活组合使用这些方法，平时多预防，出事才能快速定位和解决。