复盘618与双十一：香港服务器如何根据峰值请求量预留容量？

618、双十一的容量复盘，不能只看“大促当天用了多少CPU”。真正决定香港服务器需要预留多少容量的，是下一次活动的峰值请求量、请求类型变化、数据规模增长，以及扩容完成前可能继续增加的负载。同样是每秒数千次请求，浏览商品和提交订单消耗的资源不同；同样的访问人数，缓存命中率下降或接口变慢，也会让服务器承受更高压力。

合理的预留方法，是把历史峰值修正为下一次活动的设计负载，再按照CPU、内存、带宽、数据库和存储分别计算需求，以最先触及业务性能边界的资源确定容量。香港服务器还需要单独核对目标地区的访问线路、可用带宽和交付周期：增加计算节点不能自动解决出口拥塞，活动开始后再申请资源，也未必来得及承接短时峰值。

一、从大促复盘中还原负载画像

峰值请求量不能用全天平均值替代

一天的总请求数适合核算流量费用，却不适合直接决定峰值容量。活动入口开放、优惠券发放、秒杀开始和支付回调，都可能形成持续时间不同的高峰。

复盘时，至少保留三个时间尺度：秒级或数秒级的突发峰值、分钟级的持续高峰，以及活动主要时段的负载曲线。具体采样间隔取决于监控系统，但不能只留下小时平均值，否则短时拥塞容易被平滑掉。

还要明确请求在哪一层统计。CDN边缘请求、香港源站请求、网关请求和应用接口调用量，并不是同一个口径。一笔订单可能触发库存、优惠、支付等多个内部调用，不能把入口QPS直接当成数据库QPS。

容量规划中的峰值请求量，应当指明统计入口、采样窗口和请求范围，并同时保留持续时间。脱离这些条件的“峰值QPS”，无法直接用于服务器选型。

618与双十一也不能只比较访问量。两次活动的商品数量、优惠规则、直播入口、投放节奏和用户地区分布发生变化时，请求结构可能已经改变。上一次首页浏览占多数，下一次订单和优惠计算占比提高，即使总QPS相同，计算与数据库压力也可能更大。

将请求拆成可计算的业务类型

可先按业务路径建立下面的负载画像，再使用各类请求的比例计算资源需求。

请求占比最好对应峰值窗口，而不是全天平均比例。大促开场的下单占比，可能明显不同于活动前的浏览阶段。

还需要区分业务增长和重试放大。可使用以下关系：

设计请求量 = 历史峰值请求量 × 业务增长系数 × 请求放大系数

例如，历史峰值为6000次/秒，下一次活动预计增长30%，额外重试和重复调用按5%估算，则设计请求量为：

6000 × 1.30 × 1.05 = 8190次/秒。

这里的30%与5%是演算条件，不是固定推荐比例。业务增长应来自投放计划、用户规模和活动入口变化；请求放大则应根据重试策略、历史超时和重复提交情况确定。若历史峰值已经包含异常重试，需要先识别其中的放大量，避免重复计算。

并发数量必须结合请求耗时

同时在线人数不等于同时处理的请求数。在系统相对稳定、统计口径一致时：

平均在途请求数 ≈ 每秒到达请求数 × 平均响应时间，响应时间以秒计。

设计请求量为8190次/秒，平均响应时间为0.15秒，对应约1229个在途请求。如果平均响应时间升到0.6秒，在途请求就会增加到约4914个。

这解释了为什么请求量没有继续上涨，连接池和工作线程仍可能被耗尽。容量复盘不能只记录QPS，还应记录平均耗时、P95或P99延迟、错误率和排队长度。上述公式使用的是平均值，不能直接把P95代入并声称得到准确并发量；长尾延迟应另外用于检查超时与排队风险。

二、把业务负载转换为资源变量

CPU看执行消耗，内存看常驻与在途占用

CPU容量应尽量根据请求实际消耗的CPU时间估算，而不是根据接口总耗时判断。接口等待数据库100毫秒，不代表应用CPU执行了100毫秒。

延续8190次/秒的示例，给出一组用于计算的请求结构：

加权CPU时间为：

70% × 2 + 20% × 5 + 10% × 12 = 3.6毫秒/请求。

总计算需求约为8190 × 0.0036 = 29.484 CPU核秒/秒。它可理解为约29.5个核心持续满负荷执行的计算量，但尚未计入系统开销、后台任务和资源争用。

若每个应用节点有8个可用核心，计划将CPU利用率控制在60%以内，则仅按CPU得到的理论节点吞吐约为：

8 × 60% ÷ 0.0036 ≈ 1333次/秒。

这只是推演上限，不是某款服务器的承载保证。处理器性能、共享资源争用、程序运行方式和请求分布都可能使结果变化，最终还需通过目标环境压测确认。

内存则要拆成运行时常驻、业务缓存、在途请求、连接与系统预留几部分。若每个在途请求平均额外占用256KB，1229个请求约占315MB；延迟升高到4914个在途请求时，相关占用约为1.26GB。这里按十进制单位计算，实际占用还取决于对象分配、缓冲和回收机制。

因此，内存不能只按“每秒请求量”线性配置。商品数据、缓存键数量和连接池扩大，都可能在QPS变化不大时推高内存需求。

带宽要按回源响应大小计算

香港源站承载的流量，应扣除真正由CDN直接交付的内容，但仍需包含动态接口、缓存未命中和实际回源的数据。

继续采用上述请求占比，若浏览、查询、交易类响应分别为20KB、8KB、4KB，则平均响应大小为：

70% × 20 + 20% × 8 + 10% × 4 = 16KB/请求。

按十进制口径，1KB为1000字节，1Mbps为每秒100万比特。源站响应带宽约为：

8190 × 16 × 1000 × 8 ÷ 1000000 = 1048.32Mbps。

若希望该部分业务流量不超过可用出口带宽的70%，所需带宽约为：

1048.32 ÷ 70% = 1497.6Mbps。

也就是说，仅这组动态响应就需要约1.5Gbps的带宽容量，还未计入协议开销、重传、上传请求及其他业务流量。部署在香港并不会改变这笔计算；线路质量则会影响目标地区的有效吞吐、丢包与响应时间。

数据库和磁盘要独立核算

数据库负载取决于每类请求执行多少次查询、写入和事务。若浏览类平均产生0.2次数据库操作、查询类产生2次、交易类产生5次，则平均每个入口请求对应：

70% × 0.2 + 20% × 2 + 10% × 5 = 1.04次数据库操作。

8190次/秒的入口负载，对应约8518次/秒的数据库操作。这不是数据库承载能力结论，因为一次主键查询与一次复杂统计的成本不同；提交事务数、锁等待和日志写入还要单独观察。

数据规模也应纳入下一次活动的容量模型。同样的SQL，在索引变大、缓存容纳不下热点数据后，可能需要更多磁盘读取。

日志空间尤其容易被遗漏。若每个请求平均写入1KB日志，8190次/秒持续两小时，日志量为：

8190 × 1000 × 7200 ÷ 1000000000 = 58.968GB。

这是未压缩、未采样的估算量，对应平均写入约8.19MB/秒。集中日志系统可以减少本地长期占用，但发送缓冲和故障积压仍需要磁盘空间。

三、用业务性能边界判断谁先成为瓶颈

单看CPU是否达到100%，通常太晚。容量边界应定义为：在指定请求结构和数据规模下，延迟、错误率及队列积压仍满足业务要求的最大可持续负载。

压测需要逐级增加负载，并同时观察资源与业务结果。若吞吐增加时P95延迟基本稳定，说明仍有空间；若吞吐增长有限、延迟却明显上升，通常已经接近排队拐点。

这些现象用于定位方向，不能替代进一步验证。例如增加应用节点可能放大数据库连接数量，使数据库更早拥塞；增加缓存内存也不能解决所有请求都修改同一库存记录的问题。

香港服务器还应把“计算能力”和“目标地区访问能力”分开验收。机房内压测适合验证应用吞吐；从主要用户地区访问，才有助于检查线路、延迟和实际传输表现。验收时应记录源站处理时间与完整请求时间，避免把网络慢全部归因于服务器配置。

四、预留容量要覆盖波动、故障和交付时间

先确定单节点安全吞吐

单节点安全吞吐，应是在目标请求配比、目标数据规模和业务性能要求下确认的运行能力，而非压测中短暂出现的最高QPS。

前面的8核节点按CPU推演约为1333次/秒。若后续压测确认，在1100次/秒以内，延迟、错误率、内存和数据库等待均符合要求，可将1100次/秒作为该场景的安全吞吐。它已经包含性能边界约束，不应再把理论值1333次/秒当作可调度容量。

有了这一口径，才能计算节点数量。

应用节点数 = 向上取整（设计请求量 ÷ 单节点安全吞吐）+ 故障预留节点数。

设计请求量8190次/秒、单节点安全吞吐1100次/秒，如果要求任意一个节点退出后仍能承接活动负载，则需要：

向上取整（8190 ÷ 1100）+ 1 = 9个节点。

9个节点均匀承载时，每个约910次/秒；退出一个节点后，其余8个平均约1024次/秒。该结果仍以负载均衡有效、共享数据库和带宽足够为前提。

容量余量不是统一加一个百分比

性能余量、业务预测误差、节点故障预留和扩容等待期负载增长，解决的是不同问题。将它们全部合并为“多留30%”，容易遗漏风险，也可能重复预留。

例如，1100次/秒的安全吞吐已经低于理论CPU容量；如果这个值还包含了明确的性能余量，就不必再机械叠加同一性质的余量。相反，单节点故障后的剩余容量仍必须单独验证。

对于短时秒杀，扩容启动可能慢于流量到达，资源需要提前上线；对于持续数小时的活动，可以在基础容量之外设置可扩容空间。不能假设所有香港服务器都有相同交付速度，独立服务器上架、云实例启动、带宽调整和数据库扩容，应分别确认时间。

存储余量要留给增长与维护

存储容量至少应包含现有数据、规划周期内增长、活动临时数据，以及索引构建、日志轮转等维护所需空间。

例如，当前数据为200GB，未来30天净增长按每天8GB估算，再计入约59GB活动临时日志，合计约499GB。若计划将正常占用控制在磁盘容量的70%以内，则容量需求约为：

499 ÷ 70% ≈ 713GB。

这只是空间需求，不能说明磁盘IOPS或写入延迟合格。数据库副本需分别核算容量，备份也应有独立预算和恢复方案，不能把同一块磁盘上的备份文件视为有效的故障隔离。

五、将容量结果对应到香港服务器产品条件

容量推演的结果不应只是一张CPU与内存配置单。它应能对应到实际采购、交付和扩容条件。

选型时还要检查架构是否支持横向扩容。会话依赖单机内存、任务固定在某个节点，或者所有交易竞争同一把锁时，增加节点不一定增加有效吞吐。

成本也应分开核算。计算节点按资源和使用时间估算；带宽可能按固定速率、流量或峰值计费，具体以合同口径为准；备份、快照、日志存储和数据库副本则有各自的增长变量。用于售前沟通的容量表，最好同时注明“活动期间最低需求”“需提前预留的资源”和“可在高峰后释放的资源”。

交付验收不宜只检查机器能否启动。至少应确认目标负载下的持续表现、单节点退出后的承载情况、目标地区访问效果，以及扩容申请到服务可用的实际流程。对于分钟级突发业务，若交付时间长于峰值形成时间，就不适合依赖临时采购兜底。

围绕618与双十一的容量预留，A5数据提供香港Xeon Gold及AMD EPYC等物理服务器产品，以不同档位的计算资源、内存和SSD或NVMe存储，为电商接口、业务后台及数据库提供部署基础。香港产品还提供CN2与国际带宽方案，衔接不同访问人群的网络需求；另有大容量存储系列承载活动日志、文件与归档数据，让计算、网络和数据留存需求都有对应的资源供给。

六、依据安全容量和扩容提前量设置触发点

从扩容完成时间反推触发阈值

扩容阈值不能简单规定为“CPU到80%再加机器”。应先确定从触发告警到新增容量真正可用，需要多长时间，再计算这段时间内可能增加多少请求。

可用以下关系确定请求量触发点：

扩容触发请求量 ≤ 故障条件下可用安全容量 − 扩容等待期预计增量 − 未覆盖的短时波动量。

以上述9节点集群为例，预留一个节点故障后，可用安全容量为8 × 1100 = 8800次/秒。若新增容量需要15分钟就绪，期间请求量预计每分钟增加60次/秒，且还需覆盖300次/秒的额外短时波动，则触发点不应高于：

8800 − 15 × 60 − 300 = 7600次/秒。

这也说明，9个节点虽然满足8190次/秒的静态设计负载，却未必足以覆盖扩容等待期继续增长的场景。若8190次/秒尚未包含上述900次/秒增长和300次/秒波动，需准备：

向上取整［（8190 + 900 + 300）÷ 1100］+ 1 = 10个节点。

如果这些增长已经计入8190次/秒的预测，就不能重复叠加。活动入口瞬间跳升的负载，也不应套用平缓增长速度，而应直接提前准备对应容量。

为不同资源设置不同告警

请求量适合触发应用扩容，但数据库、带宽和磁盘必须使用自己的指标。监控至少需要覆盖以下对应关系：

• 应用节点：每节点QPS、CPU、内存、平均及尾部延迟、错误率，检查负载是否均衡。
• 数据库：查询与事务速率、连接等待、锁等待、磁盘延迟、复制延迟，判断应用扩容是否会放大后端压力。
• 缓存：命中率、淘汰量、热点键、连接数，识别缓存失效后的回源放大。
• 网络出口：吞吐、丢包、重传和目标地区请求时间，避免只看端口标称速率。
• 消息队列：积压量、最老消息等待时间、生产与消费速率，确保削峰没有转化为不可接受的业务延迟。
• 存储：剩余空间、增长速度、IOPS与吞吐、读写延迟，预测耗尽时间而非等待空间不足。

阈值应从压测曲线确定：找到延迟开始明显恶化的负载点，将运行上限设在其下方，再结合扩容提前量设置更早的触发点。监控持续窗口要能过滤偶发噪声，但秒杀入口的队列和错误率不能等待过长时间才告警。

每次618或双十一结束后，应更新峰值请求结构、单节点安全吞吐、数据库操作放大系数、实际带宽消耗和扩容耗时。下一次活动的预留容量，便可以用这组更新后的变量重新计算，而不是沿用上一年的机器数量。对香港服务器而言，可执行的容量规划最终应落在三项结果上：目标负载下有多少安全容量，失去一个资源单元后还能承接多少，以及在剩余容量耗尽前能否完成扩容。