618与双十一峰值流量复盘，如何定位香港服务器带宽与应用瓶颈？

零点后的大促监控屏上，页面响应时间突然拉长，香港服务器的CPU却只用了三成。值班人员看到出口流量接近套餐带宽，准备申请扩容；另一组人员发现应用连接池排队，又建议增加实例。618与双十一复盘时，这两种判断都可能只说对了一部分：定位瓶颈不能只看某个资源是否接近满载，而要确认请求在哪一段等待、哪些指标同步恶化，以及改变一个条件后性能是否恢复。

对于香港服务器，判断顺序应覆盖用户到机房的网络路径、服务器出口、CPU、内存、磁盘、应用与数据库。带宽不足通常表现为出口平台化、发送等待增长；应用或数据库瓶颈则更常表现为内部处理时间、连接池排队或查询等待增长。下面用一个技术上合理的模拟现场还原判断过程，时间线、监控数值与日志均为示例，不对应具体客户或真实事故。

模拟现场：同一次大促，先后出现了两类瓶颈

现场采用一组便于讨论的配置：香港应用服务器为16 vCPU、32 GiB内存，出口带宽上限为200 Mbps，运行Nginx与应用服务；数据库部署在独立节点。商品图片与活动页部分静态资源仍由源站发送，动态请求包括库存查询、优惠计算与订单提交。

活动前，首页访问正常，数据库没有明显慢查询。活动开始后，运维人员记录了三段现象：

这里的入口尝试请求包含尚未完成或最终失败的请求，不能直接当作成功吞吐量。出口速率也不能与某一时刻的请求数机械相乘：响应大小不同、请求尚未完成、TCP重传和统计窗口差异都会影响结果。

第一段异常更像出口带宽不足；第二段异常发生时，带宽已经有余量，问题转向应用与数据库。一个瓶颈被解除后，原本被它压住的下一个瓶颈可能才会暴露。因此，大促复盘不能用“扩带宽后好了一会儿”证明整次故障都由带宽引起，也不能因后来出现数据库等待，就否定前面存在网络容量问题。

关键线索：把监控拼成同一条请求链

现场首先需要统一时间。入口日志、主机监控、应用追踪与数据库记录如果相差几十秒，就容易把流量上涨后的结果误认成原因。

较实用的做法是保留5—10秒粒度的资源指标，并用统一的一分钟窗口统计吞吐、错误率和延迟分位数。除了全站P95，还要分别观察首页、库存、下单等关键接口，避免大量快速静态请求掩盖少量缓慢交易请求。

带宽曲线必须同时关联响应大小与完成量

带宽消耗取决于传输字节，不只取决于QPS。同样是每秒300个请求，返回2 KB的接口与返回200 KB的页面，对出口的压力相差很大。

按十进制口径计算，1 KB为1000字节、1 Mbps为每秒100万比特。若平均每个响应发送80 KB，请求需求为360次/秒：

• 每秒响应数据量：360 × 80 KB = 28.8 MB/s。
• 对应数据速率：28.8 × 8 = 230.4 Mbps。
• 在200 Mbps出口下，理论上仅这部分响应数据就已超出容量，尚未计入协议开销、其他业务流量与重传。

反过来，200 Mbps相当于25 MB/s。以每次80 KB计算，理想上限约为312.5次/秒，但这不是可承诺的业务吞吐，更不代表能维持目标P95。

如果源站出口长期贴近上限、成功完成量不再增长、发送等待和用户延迟持续增加，而应用处理时间基本稳定，就形成了较完整的带宽瓶颈证据。只有“流量看起来很高”，还不足以下结论。

总耗时与上游耗时分开看

Nginx日志可以保留请求总耗时、上游响应耗时、发送字节数、状态码和请求标识。模拟日志如下：

{
  "time": "00:01:20",
  "request_id": "demo-618-001",
  "uri": "/activity",
  "status": 200,
  "request_time": 2.640,
  "upstream_response_time": "0.084",
  "body_bytes_sent": 82000
}

该日志表明，总耗时明显大于获取上游响应所需的时间。结合出口接近上限，它支持“耗时主要增加在客户端侧接收、响应发送等环节”的判断，但单条日志不能证明带宽不足。

request_time包含读取客户端请求、与上游交互及向客户端发送响应等过程；upstream_response_time也不是纯粹的应用CPU执行时间。响应缓冲、请求体上传、流式输出和客户端速度都会影响二者关系，不能把两项相减后直接命名为“网络耗时”。

当异常转向动态接口时，日志可能表现为总耗时与上游耗时一起增长。此时需要继续用应用追踪拆出连接池等待、数据库执行、缓存访问与外部服务调用时间。

香港线路问题与服务器出口问题分开看

香港服务器面向不同地区、不同运营商的访问者，网络路径可能不同。复盘应按访问地区与运营商分组，而不是只看全站平均值。

如果只有某一类访问路径变慢，源站出口没有接近上限，应用内部延迟也稳定，应优先检查路径时延、丢包、连接建立时间与重传，而不是直接升级服务器带宽。

如果多个地区同时变慢，出口达到上限，服务器侧发送等待同步增加，才更符合源站出口拥塞。即使确认路径问题，也应通过多个探测点、持续样本和业务连接表现交叉验证；中间节点不响应探测或限制探测报文，不等于业务链路一定丢包。

面向大促期间的网络与应用资源需求，A5数据提供香港物理服务器租用，涵盖CN2与国际带宽方案，以及Xeon Gold、AMD EPYC等计算平台。不同配置搭配大容量内存、SSD或NVMe存储，可为活动页面、库存接口、订单服务及数据库节点提供部署基础，支持应用与数据库分层承载，为访问线路、出口带宽和内部计算存储提供多维度的资源选择。

判断过程：逐层排除CPU、内存、磁盘与内部等待

现场没有采用“哪个数字高就处理哪个”的方法，而是逐层检查资源饱和度、等待时间与吞吐变化。

第一层：网络是真正的限制，还是症状？

网络检查需要回答三个问题：流量是否达到实际生效的限制，数据是否在发送端排队，异常是否覆盖多个访问路径。

套餐带宽、网卡链路速率和实际出口能力不是同一个概念。服务器显示网卡为1 Gbps，并不意味着可以持续使用1 Gbps公网出口。独享或共享、固定上限或可突发、入站与出站是否分别限制，都应按实际服务条件核对。

Linux环境可用以下只读命令辅助观察；sar来自sysstat，需要系统已安装，网卡名称应按实际输出确认：

ip -s link
sar -n DEV,TCP,ETCP 1 10
ss -s

网卡统计可帮助发现丢弃和错误，sar可观察接口速率与TCP重传变化，ss可查看连接状态概况，但它们都不能单独证明公网线路拥塞。

在模拟现场中，出口连续多个采样周期贴近200 Mbps，业务完成量平台化，而上游处理时间没有同步增长。因此，运维人员将“出口容量不足”列为第一阶段的主因，而不是因CPU不高就认定服务器没有瓶颈。

第二层：CPU平均不高，是否仍有计算瓶颈？

16 vCPU服务器的平均CPU占用为30%，不能排除单线程或少数线程满载。如果一个关键执行线程持续占满单核，整机平均值仍可能不高。

应同时检查每核利用率、运行队列、进程与线程占用，以及虚拟化环境中的CPU等待情况。应用有容器CPU配额时，还要检查是否发生限流：宿主机有空闲资源，并不意味着容器能够使用。

mpstat -P ALL 1 10
vmstat 1 10

上述命令分别用于观察每核利用率及运行队列、内存和调度相关情况，mpstat同样依赖sysstat。

CPU瓶颈通常需要“可用执行能力接近耗尽、任务排队、处理延迟上升、吞吐增长停滞”等证据互相印证。如果请求追踪显示大部分时间在等待数据库锁，即使应用CPU还有空闲，也不能靠增加CPU解决。

第三层：内存占用高，是否形成真实压力？

Linux使用空闲内存作为缓存是正常现象，不能把“内存用了90%”直接等同于内存不足。

真正需要关注的是可用内存趋势、换页活动、内存回收压力、OOM记录，以及应用运行时的垃圾回收暂停。应用堆内存稳定，也不代表进程总内存稳定；连接缓冲、线程栈和本地内存都可能增长。

free -h
vmstat 1 10

若高峰时可用内存持续下降、换入换出明显增加，并且延迟与其同步恶化，内存压力才更可信。vmstat第一行通常反映自启动以来的平均情况，后续采样更适合观察现场变化。

本例中，应用节点仍有可用内存，没有持续换页，垃圾回收暂停也未明显增加，因此内存不是当前主因。这不意味着下一次流量增长时仍可忽略它。

第四层：磁盘是否拖慢应用或数据库？

磁盘问题要分别看应用节点与数据库节点。

应用节点可能因访问日志、临时文件或上传文件产生写入压力；数据库节点则需要关联数据读取、事务日志写入、刷盘与检查点。不能拿应用服务器磁盘空闲，去证明独立数据库节点的存储没有问题。

iostat -xz 1 10

判断应结合设备延迟、队列、吞吐及业务等待。对于并行能力较强的SSD或虚拟块设备，%util接近100%不一定代表性能完全耗尽；反过来，利用率不高也不能排除云盘限额、突发额度耗尽或少量同步写入延迟。

本例中，数据库存储延迟没有明显恶化，等待主要集中在同一库存记录的锁竞争，因此不宜把数据库变慢归因于磁盘。

第五层：应用与数据库到底谁在排队？

静态资源分流后，源站出口明显下降，更多动态请求进入应用。监控显示，数据库连接池80个连接长期全部占用，获取连接的等待时间增长。

“连接池满”只是现象，至少可能对应三种原因：

• 数据库执行变慢，连接被占用得更久。
• 应用在事务中执行其他耗时操作，迟迟不归还连接。
• 连接池确实偏小，而数据库还有处理余量。

三者对应的处置完全不同。盲目扩大连接池，可能把应用侧队列转移到数据库，增加并发查询和锁竞争。

追踪进一步显示，库存扣减围绕少数热门商品集中发生，数据库CPU和磁盘并未饱和，但锁等待增长。此时的瓶颈不是“数据库规格不够”这个笼统结论，而是热点事务串行化限制了处理能力。

各层P95也不能直接相加得出整条请求的P95，因为这些分位数不一定来自同一批请求。定位关键请求，应沿同一个请求标识查看实际耗时分布。

可用于复盘的瓶颈对照表

处置步骤：每次只验证一个主要假设

大促现场的处置目标不是立刻消除所有告警，而是恢复关键交易并形成可验证的因果链。

1. 保存现场，先保护核心链路

运维人员应先记录异常起点、流量结构、错误率、资源指标和近期变更，保留关键日志与追踪样本。直接重启可能暂时释放资源，也可能清掉诊断线索并形成冷缓存冲击。

业务保护可优先针对非核心请求采取限流、缓存或降级，让库存确认和订单提交获得必要资源。需要限制的是明确的入口或功能，而不是无差别地让所有用户等待。

2. 第一阶段减少源站传输，验证带宽判断

本例将适合缓存的图片和版本化静态资源交由CDN分发，并检查命中率和回源量。登录态、购物车、订单等动态内容不能为降低带宽而盲目缓存。

另一个估算可以帮助判断改动方向：若调整后源站平均响应降至18 KB，在420次/秒的请求需求下，响应数据速率约为：

420 × 18 KB = 7.56 MB/s；7.56 × 8 = 60.48 Mbps。

该值只是按平均响应大小计算的业务数据量，不含其他出口流量与协议开销。它说明减少每次请求的源站字节量，可以显著改变带宽需求，但具体效果仍需监控验证。

这一轮只观察出口、完成量、错误率与端到端延迟。若出口离开上限后延迟下降，而应用处理时间基本不变，就进一步支持第一阶段的判断。

带宽扩容同样可能有效，但只适用于实际出口上限构成约束的情况。若问题在特定网络路径或数据库等待，扩容不能替代对应处理。

3. 第二阶段处理内部排队，不盲目加连接

确认热点锁竞争后，短期可限制热点接口的并发，对重复请求做合并或去重，并避免无界重试。限流与重试必须配合清晰的超时、退避和幂等设计，防止少量超时演变为请求放大。

长期应检查事务是否过长、是否在持锁期间调用外部服务、查询索引是否合适，以及库存更新方式是否能减少冲突。引入排队或异步处理时，还需要明确订单状态、失败补偿和库存一致性边界，不能仅以接口返回更快作为成功标准。

增加应用实例前，应确认数据库承受得住新增并发；增加数据库连接前，应确认等待并非由热点锁或慢事务造成。

4. 用相同业务模型复测，设置回滚门槛

带宽调整、缓存规则和应用并发参数都应保留原值，明确影响范围与回滚触发条件。数据库索引或事务逻辑变更则应先在测试环境验证，评估锁表、存储空间和一致性风险，并准备符合业务恢复要求的备份与回退方案。

复测不能只刷一个健康检查接口，应包含静态资源、商品浏览、库存查询、优惠计算与下单，并模拟冷缓存、热门商品集中访问和正常用户停顿。

验收至少要同时满足：目标吞吐达到要求、关键接口P95与P99可接受、错误率没有转移到其他环节、内部队列能够在峰值结束后回落。恢复速度同样重要，峰值过去后仍持续积压，说明系统没有真正恢复。

复盘边界：不要把一次恢复写成容量保证

模拟现场中，第一阶段的主要限制是香港服务器出口，第二阶段则是热点事务与连接占用。两次现象发生在同一次大促，但不能合并成一句“服务器性能不足”。

容量结论应带上条件：访问地区与运营商分布、请求结构、平均响应字节数、缓存命中率、数据库数据规模及关键事务并发。618与双十一即使总访问量接近，也可能因促销玩法、热门商品集中度、客户端重试策略不同，出现不同瓶颈。

复盘容易遗漏的检查项，往往决定下一次活动是否重演：

• 统计口径是否一致。 尝试请求、成功请求、订单量与并发连接数不能互相替代；Mbps、MB/s及GiB内存也不能混用。
• 是否看到了短时峰值。 五分钟平均流量可能掩盖数秒级突发，平均延迟也可能掩盖P99和超时。
• 缓存是否真的减少了回源。 命中率应按资源类型核对，还要检查过期集中、冷缓存和失效风暴。
• 重试是否放大了负载。 用户点击重试、客户端自动重试和服务内部重试可能叠加，非幂等交易尤其需要审查。
• 后台任务是否撞上促销窗口。 备份、报表、日志归档和数据库维护应分别核查所在节点与资源竞争。
• 是否只验证了单节点。 应用负载不均、某台连接池异常、某个数据库节点延迟，都可能被集群平均值隐藏。
• 香港出口与访问路径是否分别记录。 机房带宽、共享条件和用户侧路径属于不同约束，不能用一项改善替代另一项验证。
• 业务结果是否正确。 页面恢复、HTTP返回200并不代表库存与订单一致，还要核对超卖、重复提交、支付回调和补偿积压。

最终留下的复盘记录，应能回答：异常从什么时候开始，请求在哪里等待，哪些证据支持主因，改动后哪些指标随之改善，以及下一次活动前还需验证什么。只有这些问题逐项闭合，带宽、服务器规格和应用优化才不会变成凭感觉追加资源。