半小时后，主从数据库的延迟从几十秒级回落到不到一秒，关键接口恢复稳定，用户侧的错误率明显下降。流量一被管住，丢包和重传就少了，关键服务又慢慢爬回正常范围，用户那头的报错也明显少了。

那天下午的告警先从应用层冒出来：页面慢、请求超时多，客服电话一下子响个不停。运维小李一看监控图，立马觉得不对劲——整机的网口利用率快顶满了，TCP重传和连接重置一下子飙起来。DB张姐盯着复制延迟看，发现binlog的传输卡在网络上，slave端的延迟一路往上窜，队列越堆越长。大家赶紧临时召了个应急会，先把事儿压住再去找根源。

先把问题压住的办法挺直接：在边缘路由和几台关键应用机上先做了流量控制。用iptables给非核心的流量打标记，然后在网卡上用tc做HTB分流，把数据库复制和核心请求往前排。具体就是把3306端口的流量放到优先级高的class里，把备份、爬虫、第三方同步这些吃带宽的设成低优先级，给它们定rate和ceil，防止瞬间把链路吃满。改完后，用iperf和压测脚本模拟突发流量，确认replication lag不再爆表，才逐步放松其他限制。

回头看出事的起点，是个定时批量作业在白天被误触发。本来那个任务安排在凌晨做历史数据同步到分析集群，但上周有人改了调度器配置，这回跑到业务高峰期去触发。与此同时，几家外部合作方也在同一时间段大批量拉取数据。多股高峰叠加，出口带宽瞬间超阈值。平时看带宽够用，但没按流量类型分层管理，大家平常就是“谁先抢到谁用”，结果把对丢包敏感的replication流挤掉了。

排查花了段时间。先从监控抓数据：netstat/ss能看到大量半开或被reset的连接，sar和ifstat上网卡收包速率飙高，ethtool提示queue drops上升。抓包用tcpdump一看，都是重传、延迟ACK，slave端连接不停重试。应用日志里绝大多数超时并不是业务慢，而是TCP层丢包重建连接导致。DB端的复制线程卡在某个文件偏移处不停拉取也验证了这一点。

技术动作分段来做。边缘路由先做Ingress policing，把突发流量限制在可控范围；应用层把非关键服务临时屏蔽或暂停，把批处理job挪走，影响小的同步任务延后。各应用服务器上用tc按来源IP或端口做精细限速：用iptables mangle打标，再在qdisc里把filter映射到对应class。给DB复制和HTTP/HTTPS设置高优先级和较大保证带宽，爬虫、分析这些设低保证但留峰值空间。现场也定了几个参数：edge口的ingress policing设400Mbps的峰值；内部到数据库的egress class设保证带宽1Gbps；低优先级定rate 100Mbps、ceil 300Mbps。还把conntrack的超时调短，避免大量已关闭的连接占资源。所有改动先在测试环境跑iperf3并抓包验证，再在一台低峰的机器试跑稳定才推广。

沟通上也很紧凑。DBA要求先保障binlog通道，产品临时屏蔽了几条非必要接口，开发把调度器恢复到原定时间窗。运维用Ansible把tc规则批量下发到几十台机器，避免漏掉节点。每次推送都有回滚脚本，万一哪步出问题能立刻撤回。整个堵点的大动作花了大约一个小时，之后又用了半小时观察，延迟明显收敛，用户投诉数量也大幅下降。

调查里还发现架构上的老问题：长期没把网络流量管理做成常态。大家平时更盯应用性能和DB调优，网络策略多是默认配置，一旦链路拥塞，状态同步类的流量最先吃亏，因为对丢包和时延很敏感。DB张姐在事后把关键表的binlog切分得更频繁，降低单次传输的数据量，这样复制恢复起来更稳。监控报警也从单纯带宽告警，扩展到了TCP重传率、应用错误率和复制延迟的组合告警，减少单一指标失灵带来的盲点。

在流控生效后的第28分钟，slave的IO线程把落后的binlog文件拉完，SQL线程开始回放积压的事务，延迟从几十秒回落到个位数，接着稳定在不到1秒。值班群里有人半开玩笑地说，这次我们是被自己的分析任务“拿下”了，也有人叮嘱以后改调度器得三思。整个过程没有什么惊天动地的英雄救美，更多是按着指标一步步查、分级限流、验证再推广。