突发流量致CPU飙升需综合施策：先区分真忙/假高定位瓶颈，再规划内存防OOM，分层限流保核心链路，结合前置指标与冷备实现有效弹性。
突发流量导致 CPU 飙升，不是单纯“加核”就能解决的问题。关键在于提前规划资源边界、识别真实瓶颈类型，并把限流降级作为可控的主动策略，而不是故障后的被动补救。
CPU 规划：区分“真忙”和“假高”
云服务器上看到 CPU 使用率 90%，不等于系统真的在高效计算。要先判断是哪类高占用：
-
用户态高（us）：代码逻辑问题，比如死循环、低效算法、未优化的正则或 JSON 序列化——需结合
jstack+top -H定位热点线程； -
iowait 高（wa）：磁盘响应慢，常见于日志刷盘频繁、数据库未加索引、小文件大量读写——应查
iostat -x 1，优化 IO 路径或加缓存； - steal 高（st）：宿主机超卖严重，“吵闹邻居”抢占 CPU 时间片——换为独享型实例或迁移到低负载可用区；
- softirq / si 高：网络中断处理过载，多见于高并发短连接（如 HTTP 短链、UDP 包洪峰）——可调大网卡队列、启用 RPS/RFS、或改用连接池复用。
内存规划：防 OOM 比扩容更关键
内存不足触发 OOM Killer 杀进程，比 CPU 飙升更难诊断。规划时重点不是“够不够”，而是“怎么不出事”：
- Java 应用预留 20%~30% 堆外内存（Netty Direct Buffer、JVM CodeCache、JNA 等），避免堆内没满但系统直接杀进程；
- Linux 设置
vm.overcommit_memory = 2+vm.overcommit_ratio合理值，防止内核误判“可分配内存”而过度承诺； - 容器场景必须设
memory.limit_in_bytes（K8s 中即resources.limits.memory），否则 cgroup 不生效，OOM 会杀整个 Pod； - 避免“缓存全放堆内”：Redis、Caffeine 本地缓存等尽量用堆外或 off-heap，减少 GC 压力与内存抖动。
限流降级：按业务优先级分层切流
限流不是一刀切，而是有节奏地保护核心链路。建议按以下三层设计：
- 入口层限流：API 网关（如 Kong、APISIX）配置 QPS 级别规则，拦截恶意刷量或异常爬虫，不进业务线程池；
- 服务层熔断：对下游不稳定依赖（如第三方支付、风控接口）启用 Resilience4j 或 Sentinel 的熔断器，失败率超 50% 自动半开，避免雪崩；
- 功能级降级：非核心能力（如商品推荐、评论加载、搜索联想）在 CPU > 80% 或 P99 延迟 > 1s 时自动关闭，返回兜底数据或静态文案，保障下单、支付主流程畅通。
弹性协同：让扩容真正“来得及”
自动扩容常因指标滞后而失效。真正有效的弹性需要：
- 监控指标前置：不用 CPU 平均值，改用
CPU > 70% 持续 30 秒或P95 延迟突增 200ms触发扩容； - 预留冷备资源：关键服务保留 1~2 台空闲实例，不计费但已预热（JIT 编译完成、连接池建连、本地缓存预热），秒级拉起；
- 混部资源隔离：计算密集型（如导出、报表）与 IO 密集型（如 API）服务不要混跑同一节点，避免 CPU 抢占影响响应稳定性。
