Linux系统高峰期不稳定源于容量瓶颈与限流机制协同失效，需分四步解决：一、定位真实瓶颈（CPU队列、内存Swap、IO等待、连接耗尽）；二、按基线水位、弹性缓冲、熔断触发点分层设阈值；三、内核级（Netfilter）、系统级（conntrack）、进程级（cgroups）、应用层（Sentinel）协同限流；四、用压测、日志、抓包验证策略有效性。
Linux系统在高峰期出现不稳定，往往不是单一原因导致，而是容量瓶颈与限流机制协同失效的结果。关键不在于“扛不扛得住”，而在于“是否清楚资源在哪卡住、限流是否真正生效、策略是否匹配业务节奏”。
一、先定位：哪些资源真正在拖垮系统？
高峰期的“不稳定”常表现为响应变慢、请求超时、服务重启甚至节点失联。但背后资源瓶颈可能各不相同：
- CPU饱和：非一定是满载100%，而是可运行队列（run queue）持续大于CPU核心数，说明任务排队严重，top中看load average值显著高于CPU逻辑核数；
- 内存+Swap抖动：free -h显示可用内存极低，同时si/so（swap in/out）持续有值，表明内核频繁换页，进程反复被换入换出；
- 磁盘I/O等待高：iostat -x 1中%util接近100%且await远高于svctm，说明IO队列积压，常见于日志刷盘、数据库同步或临时文件暴增；
- 连接类瓶颈：ss -s 显示total connected / time-wait / orphaned异常偏高；netstat -s 查看“packet receive errors”或“TCP: time wait bucket table overflow”提示连接跟踪耗尽。
二、容量水位怎么设才合理？别只看50%或80%
静态阈值（如“CPU>70%就告警”）在动态业务下容易误报或漏报。应结合业务特征分层设定：
- 基线水位：用sar -u / sar -r 持续采集7天以上，取P95值作为日常安全水位（例如CPU P95=45%，那60%就该介入）；
- 弹性缓冲区：为突发流量预留15~25%余量，但需配套验证——用stress-ng模拟对应负载，观察服务P99延迟是否突破SLA；
- 熔断触发点：不是等资源打满，而是当平均响应时间突增200%+错误率>1%时，即视为容量临界，此时限流应已启动。
三、限流不能只靠应用层：内核级与中间件协同控制
单靠Spring Cloud Gateway或Nginx限流，无法拦截内核态资源争抢（如大量短连接冲击conntrack表）。必须分层布防：
- 连接准入层（Netfilter）：用iptables + hashlimit限制单IP新建连接速率，例如每秒不超过30个SYN，防扫描和突发连接冲击；
- 系统级连接控制：调整net.ipv4.ip_conntrack_max、net.netfilter.nf_conntrack_tcp_be_liberal，并配合nf_conntrack_timeout_*缩短空闲连接存活时间；
- 进程资源约束：用systemd的MemoryMax/CPUQuota或cgroups v2对关键服务做硬限制，避免一个Java服务OOM拖垮整机；
- 应用层兜底：基于QPS/并发数/线程池活跃度做动态降级，推荐集成Sentinel或Resilience4j，规则应支持运行时热更新。
四、验证策略是否真实有效：别信配置，要测行为
写完限流规则、调完sysctl参数，必须用真实流量模式验证效果：
