服务器局部热点没有玄学，先盯监控曲线，再用日志和命令逐层下钻，最后用缓存、限流和分片把压力从单点摊开，核心思路就这四步。
服务器CPU使用率高怎么排查：先分清是“真忙”还是“假忙”
定位局部热点,第一步不是翻代码，而是看监控，局部热点的典型特征是单机指标异常、集群整体平稳，比如同一套负载均衡后面的十台机器，九台CPU使用率在20%以下，唯独一台跑到90%，这基本可以锁定热点机器。
用Top命令快速锁定进程和线程
登录异常机器后,先执行top -c，按CPU占用排序，找到占用最高的进程PID，这一步能快速区分是业务进程（Java、Node、PHP等）还是系统进程（如kswapd内存回收、mysqld备份进程）在抢CPU，如果是业务进程，继续用top -Hp 进程PID查看线程级别占用，把最高线程的PID记下来，转成十六进制（printf "%xn" 线程PID），然后用jstack 进程PID | grep -A 30 "十六进制线程号"抓取线程堆栈，基本能定位到具体的代码行。
区分计算密集型和锁竞争
业内专家指出,相当一部分CPU热点不是算力不够，而是线程在“空转”，堆栈里如果大量出现java.util.concurrent.locks相关的帧，说明是锁竞争导致的上下文切换开销；如果堆栈里是序列化、加解密、正则匹配这类纯计算逻辑，才是真的计算密集型热点，这两种情况的处理思路完全不同前者要优化锁粒度，后者要加缓存或拆分任务。
连接池和线程池参数检查清单
局部热点还有一种隐蔽成因：连接池配置不合理，比如某个服务的数据库连接池maxActive设成50，但同一台机器上部署了四个实例，每个实例都初始化50个连接，热点出现时连接数直接打满，请求全部阻塞在获取连接阶段，CPU没高多少，但接口RT（响应时间）飙到秒级，排查时重点看三个值：活跃连接数是否接近上限、等待获取连接的线程数、连接空闲回收是否正常。
单台服务器负载过高怎么处理：临时止血和长效方案分开做
定位到热点后,先做临时处理保住可用性，再考虑根治，临时方案的目的不是解决热点，而是把热点请求从单台机器上分流出去。
四层和七层负载均衡的调优顺序
如果热点机器前面挂了Nginx或LVS,优先调整负载均衡策略。一致性哈希模式下，某个用户或某个IP的请求会固定打到同一台机器，热点账号出现时这台机器必然遭殃，临时办法是把策略改为least_conn（最少连接数），让新请求尽量分发到空闲机器；如果业务允许，直接停掉热点机器在LB上的权重，等流量自然散去再恢复。
应用层限流熔断三板斧
- 接口级别限流：对热点接口配置
Guava RateLimiter或Sentinel，阈值设为正常峰值的1.5倍，超出直接返回兜底数据或错误码 - 线程池隔离：把热点接口单独放到一个线程池，核心线程数设小，队列长度设短，避免热点拖垮整个Tomcat
- 熔断降级：下游依赖（如商品详情、库存服务）连续错误率超过阈值时直接熔断，返回本地缓存的旧数据
读写分离的临时切换
热点通常是读多写少,如果热点接口的数据库压力大，先把从库的读流量比例调大，比如从默认的3:7调整到7:3（主：从），观察主库的慢查询和锁等待是否下降，这招不能根治热点，但能争取半小时到一小时的排查时间。
热点数据缓存架构对比：本地缓存、分布式缓存和分层缓存的取舍
热点处理的长期方案,核心是让同一份热点数据不要每次都穿透到数据库，这里有个常见误区：以为加了Redis就万事大吉，实际上单机Redis在热点key上的QPS上限也就10万左右，热点key一旦超过这个量级，Redis本身也会成为新的热点。
| 缓存方案 | 适合场景 | 主要风险 | 热点应对能力 |
|---|---|---|---|
| 本地缓存（Caffeine/Guava） | 单机内部重复读 | 数据一致性差 | 每台机器分摊流量，无网络开销 |
| 分布式缓存（Redis Cluster） | 全局共享数据 | 热点key打满单分片 | 需要额外做key打散 |
| 多级缓存（本地+Redis） | 读多写少的高并发场景 | 缓存一致性维护复杂 | 抗热点能力最强 |
多级缓存的思路是：先查本地缓存，命不中再查Redis，Redis也没有才回源数据库，本地缓存命中率能做到50%以上，意味着热点流量在每台机器内部就被消化了一半，需要注意的是，本地缓存要有过期时间和最大容量限制，否则机器内存会被撑爆。
热点key的主动发现与打散
行业共识认为,被动等热点打挂机器再去处理，成本远高于主动发现，建议在业务代码里埋点统计key的访问频率，每秒访问超过1000次的key自动上报到监控系统，然后做两件事：
- key后缀打散：把
hot_product_202601拆成hot_product_202601_01到hot_product_202601_10十个key，分散到Redis的不同分片 - 本地缓存预热：热点key识别出来后，主动推送到各台机器的本地缓存，并设置较短的过期时间（如30秒），过期后重新拉取
热点账号和突发流量场景的完整复盘
用一个电商大促的典型场景串一遍整个流程：某头部主播开播后，一款秒杀商品的详情页流量在30秒内涨了50倍，监控显示其中两台应用服务器的CPU使用率冲到95%，接口RT从50ms涨到3秒。
第一步：定位。 通过top找到CPU占用最高的Java进程，jstack抓出线程堆栈，发现大量线程阻塞在商品详情的数据库查询上，同时Redis监控显示product_detail_9527这个key的QPS达到每秒8万，接近单分片极限。
第二步：临时止血。 在Nginx层把这两台机器的权重降为0，让新请求全部打到其他机器；同时在Sentinel控制台给详情接口配置限流阈值，超出部分直接返回“活动太火爆”的兜底文案。
第三步：缓存改造。 对这个秒杀商品做本地缓存+Redis双写，本地缓存过期时间设为10秒，Redis key拆成10个分片key，改造后单机QPS从原来的5000提升到2万，热点机器CPU使用率降到40%以下。
第四步：长效预防。 在监控系统里配置热点key自动发现规则，访问频率超过阈值自动告警并执行打散逻辑，后续再遇到类似场景，系统能在1分钟内自动完成识别和分流，不需要人工介入。
服务器局部热点常见问题解答
Q：热点key和普通key怎么区分？有没有判断标准？
判断标准不是看key的绝对值，而是看单key的访问量占整个Redis实例总QPS的比例，当单个key的QPS超过实例总QPS的10%，或者单key QPS超过1万，就需要考虑打散处理，不同业务规模阈值不同，核心观察指标是key所在分片的CPU和带宽是否出现明显倾斜。
Q：本地缓存和Redis缓存的数据一致性怎么保证？
一致性方案按业务容忍度分三档：强一致场景不用本地缓存，直接走Redis；秒级延迟容忍场景，本地缓存设置短过期时间（5-30秒），过期后强制刷新；最终一致场景，用消息队列异步更新本地缓存，热点数据大部分属于第二档，用短过期时间换吞吐量是业界最通用的做法。
Q：热点请求已经打到数据库了，除了加缓存还能做什么？
数据库层面先做SQL限流和慢查询治理，把热点SQL的并发数限制在连接池能承受的范围，如果热点集中在某张表，可以考虑读写分离把读流量分散到多个从库，或者按业务维度分表，让热点数据单独落在一张表中，最极端的情况下，用限流器直接拒绝一部分非核心请求，保护数据库不被击穿，据工信部相关技术白皮书的数据，多数互联网企业的热点治理方案都包含数据库限流这一层，这是最后一道防线。