真正有效的削峰限流是提前分层设防、动静结合：先识别CPU排队、Swap抖动、IO积压、conntrack耗尽等真实瓶颈；再通过客户端随机退避、服务端分批下发、高频操作间隔兜底实现源头削峰；最后在网络层、系统层、进程层三层限流，并基于P95基线、弹性缓冲和体验指标动态水位管控。
高峰期性能下降，核心不是“扛不住”，而是“没管住”。真正有效的削峰限流，不是等系统快挂了才动手，而是提前识别压力来源、分层设防、动静结合——既压住瞬时洪峰，也稳住资源水位。
先看清楚：哪类资源在告急？
别只盯着CPU百分比。实际瓶颈常藏在更底层：
- CPU排队比占用更危险：top里load average持续高于逻辑核数（比如8核机器load长期＞10），说明任务在队列里等执行，此时%idle可能还有10%，但响应已明显变慢；
- 内存不缺，Swap在狂抖：free -h显示可用内存尚可，但iostat里si/so值持续跳动，说明进程被反复换入换出，延迟毛刺频发；
- 磁盘%util没满，await却翻倍：iostat -x 1中%util才70%，但await达50ms以上（远超svctm），说明IO请求积压，常见于日志同步或小文件密集写；
- 连接数没爆，conntrack先耗尽：ss -s显示time-wait连接多，但netstat -s里出现“TCP: time wait bucket table overflow”，本质是连接跟踪表满，新SYN直接丢弃。
削峰要从源头错开，不止靠后端扛
把峰值打散，比硬抗更省力。关键在客户端和服务端协同：
- 服务端可控下发时，主动分批：比如消息推送、定时任务触发，不要同一毫秒全推，按用户ID哈希或随机偏移1–5秒再下发；
- 客户端请求加随机退避：前端JS或App SDK统一接入，收到指令后不是立刻发，而是生成[0, 2000]ms内随机延迟再调用，实测可将尖峰QPS压至原1/3以下；
- 高频操作加最小间隔兜底：如红包雨、点赞按钮，强制两次请求间隔≥800ms，前端拦截无效请求，服务端再校验时间戳，双保险防刷。
限流必须分层落地，单点防护会失效
只在应用网关（如Nginx、Spring Cloud Gateway）做限流，挡不住内核态冲击。需三层布防：
- 网络入口层（Netfilter）：用iptables限制单IP新建连接速率，例如每秒不超过25个SYN，防扫描和突发连接打穿conntrack；
- 系统连接层（内核参数）：调大net.ipv4.ip_conntrack_max，缩短nf_conntrack_timeout_established（如从432000调至300），加速空闲连接释放；
- 进程资源层（cgroups v2）：对Java服务设MemoryMax=4G、CPUQuota=300%，避免一个服务OOM拖垮整机，systemd或Kubernetes均可配置。
水位设定不能拍脑袋，得看业务真实基线
“CPU＞70%就告警”在动态业务中基本等于误报。应基于数据定策略：
- 取P95当日常安全线：用sar -u连续采样7天，CPU使用率P95是48%，那55%就该人工巡检，60%启动预案；
- 弹性缓冲留15%～20%：但必须验证——用stress-ng模拟对应负载，确认P99延迟仍在SLA内（如＜1.2s）；
- 熔断不看资源，看体验：平均响应时间突增180% + 错误率＞0.8%，即视为容量临界，此时限流策略必须已生效，而非等待告警后手动开启。
