为什么只看CPU使用率会误判扩容时机
页面跳转是本文的核心主题。前阵子有个做家居流量站的客户跑来找我，说他们大促当天跳转集群差点翻车。我问他扩容怎么决策的，他说盯CPU，超过百分之七十就加机器。可那天CPU一直稳在百分之六十出头，运维看了一圈觉得没毛病，结果晚上八点流量峰值一压上来，跳转平均耗时从四十毫秒一路爬到三百多毫秒，有部分请求直接超时了，落地页打开率掉了将近两成。
这种事儿我见过不止一次。跳转集群跟普通业务集群有个根本差别：单请求计算量很小、依赖的外部资源多、对延迟又极度敏感。CPU使用率反映的只是计算资源消耗，可跳转链路的瓶颈往往卡在连接池、DNS解析、规则匹配、下游落地页响应这些地方。CPU没满，不意味着集群还有余量。
所以扩容触发条件不能是单一指标，得是一组有先后顺序、能互相校验的信号。下面我把实际工作中用到的五个触发条件拆开讲，每个条件说清楚观测口径、阈值怎么定、以及怎么验证这个信号是不是真的在提示扩容。
五个扩容触发条件：口径、阈值与验证方式
条件一：连接池饱和度持续走高
跳转服务要跟下游落地页、规则库、缓存层建立大量连接。连接池饱和度指的是当前活跃连接数占最大连接数的比例。这个指标比CPU更早发出信号，因为连接建立本身有开销，池子满了之后请求会排队等连接。
观测口径：按实例维度采集活跃连接数与最大连接数的比值，取五分钟滑动窗口的P95值。
阈值设定依据：一般把百分之七十作为预警线，百分之八十五作为扩容线。但这个阈值跟连接复用率有关，如果下游响应快、连接复用充分，可以适当放宽到百分之九十；如果下游是外部落地页、响应时间波动大，建议压到百分之七十五就触发。 验证方式：看连接等待时间。如果活跃连接数上去了但连接等待时间没涨，说明池子设计还有余量，不一定要扩容；如果等待时间同步爬升，那是真饱和了。这个验证能避免被单一比值误导。
条件二：决策耗时P99突破延迟预算
跳转集群的核心工作是做决策——判断这个请求该走哪个落地页、带哪些参数、走不走缓存。决策耗时是跳转链路自己产生的延迟，不包含下游落地页的加载时间。这个指标要单独拆出来看，不能混在端到端耗时里。
观测口径：从请求进入跳转服务到决策完成、准备发起重定向的时间，按P50、P95、P99三个分位数分别采集。
阈值设定依据：先定延迟预算。假设你承诺跳转环节不超过五十毫秒，那P99就不能突破五十毫秒。实际配置里，我一般把P99的扩容线定在延迟预算的百分之八十，也就是四十毫秒，留出缓冲。P50突破预算的百分之五十就要警觉，因为P50涨说明整体水位在抬升，不是个别慢请求。
验证方式：把决策耗时按规则复杂度分层看。如果耗时上涨集中在复杂规则命中的请求上，可能是规则引擎需要优化而不是加机器；如果各层都在涨，那就是资源不够。这个区分直接决定你是扩容还是改配置。
跳转集群的错误率平时应该接近零，偶尔有几个超时是正常的背景噪声。扩容触发要看的是错误率是否脱离了背景水平并且持续。 观测口径：按五分钟窗口统计错误请求数占比，错误类型要分开——连接超时、决策超时、下游不可达、参数异常要分别计数。
阈值设定依据：先测出正常时段的背景错误率，比如百分之零点零几。扩容线定在背景值的五到十倍，并且要求连续两个窗口都超标。单窗口超标可能是抖动，连续超标才是趋势。 验证方式：看错误类型的分布。如果连接超时占比高，指向连接池或网络；如果决策超时占比高，指向计算资源；如果下游不可达占比高，那问题不在跳转集群，扩容也没用。这个验证能防止错误地给跳转集群加机器。
条件四：请求队列积压深度持续为正
大部分跳转服务会用队列来削峰。正常状态下队列应该是空的或者偶尔有个位数积压。队列积压深度持续为正，说明请求到达速度已经超过处理速度。 观测口径：采集队列长度的瞬时值和一分钟内的平均值。
阈值设定依据：这个阈值跟队列容量设计有关。如果队列容量是一千，积压深度超过容量的百分之二十并且持续一分钟以上，就该触发扩容。如果队列容量很小，比如只有一百，那积压超过二十就要动。
验证方式：看积压的消退速度。流量峰值过去后，队列如果能在三十秒内清空，说明处理能力只是暂时不够；如果消退很慢，说明处理能力缺口是结构性的，扩容之外还要看是不是有慢请求把worker占住了。
条件五：资源水位与请求量的比值异常
这个条件是把资源消耗和请求量放在一起看。正常情况下，每处理一万次跳转请求消耗的资源量应该是稳定的。如果这个比值突然变大，说明单位请求的成本上升了，可能是规则变复杂了、缓存命中率掉了、或者下游变慢了。 观测口径：用CPU时间、内存分配量、网络IO分别除以请求数，得到单位请求资源消耗。
阈值设定依据：跟历史基线比，比值上涨超过百分之三十并且持续，就要查原因。这个条件不直接触发扩容，而是触发排查——先搞清楚为什么单位成本涨了，再决定是扩容还是修配置。 验证方式：把比值按请求类型拆分。如果只有某类规则命中的请求成本上升，那是规则问题；如果所有请求成本都上升，那可能是缓存层出了问题或者机器本身有状况。
压测指标该盯哪几项，以及指标之间怎么互相校验
触发条件解决的是什么时候扩容，压测指标解决的是扩多少、扩完能不能扛住。压测不是把流量打满看崩不崩，而是要测出几个关键指标之间的对应关系。
核心压测指标
吞吐量：每秒完成的跳转决策数。这个指标要跟并发数一起看，找到吞吐量不再随并发上升的拐点。；决策耗时分布：P50、P95、P99、P999。重点看P99和P999，大促场景下尾部延迟比平均延迟重要得多。；错误率随并发的变化曲线：从零错误到错误率抬头之间的并发区间，就是安全余量。；资源消耗曲线：CPU、内存、连接数随并发上升的斜率。斜率突变点往往就是瓶颈所在。；缓存命中率：跳转决策如果依赖缓存，命中率在高压下会不会掉，掉了之后耗时涨多少。。
指标之间的校验关系
单看一个指标容易误判，几个指标放一起看才能定位问题。这里说三组常用的校验。
第一组：吞吐量和决策耗时。如果并发上去了吞吐量不涨但耗时涨了，说明系统已经饱和，加并发没用，要加机器。如果吞吐量和耗时同步涨，说明还在线性区间，有余量。
第二组：错误率和连接池饱和度。错误率抬头的同时连接池饱和度也到顶，那扩容能解决。错误率抬头但连接池没满，要查是不是下游或者规则引擎的问题。 第三组：缓存命中率和决策耗时。压测中如果缓存命中率掉了，决策耗时必然涨，这时候要看是缓存容量不够还是缓存key设计有问题。直接扩容可能只是掩盖了缓存设计缺陷。
压测场景怎么设计才接近大促
大促流量跟日常流量有两个区别：一是请求分布更集中，二是请求类型更偏向核心路径。压测场景要覆盖这两点。 建议按三个场景分别压：
- 稳态压测：模拟日常流量的分布，测出基线指标。
- 峰值压测： 把并发拉到预估峰值的百分之一百二十，持续十分钟以上，观察指标是否稳定。
- 突增压测： 在三十秒内把并发从基线拉到峰值，看队列积压和恢复速度。大促开场那一下往往就是突增。
每个场景压完，把五个触发条件的指标都拉出来对一遍，看哪些条件先触发。这样你就能知道大促时该优先盯哪个信号。
一个家居流量站的扩容复盘
回到开头那个客户。他们的业务是做家居品类的内容聚合，大促期间日均跳转请求在八百万次左右，峰值集中在晚上八点到十点。服务器规格是八台四核八G的实例，跑跳转服务和规则引擎，前面挂了一层缓存。
踩的坑有三个。第一个就是前面说的只看CPU，CPU没到线就不扩容。第二个是压测只压了稳态，没压突增，结果大促开场那一下队列积压直接冲到容量的六成，花了将近两分钟才消化完。第三个是缓存key设计有问题，大促期间大量长尾请求打穿了缓存，命中率从平时的百分之九十多掉到百分之七十出头，决策耗时跟着涨。
调整过程分三步。第一步，把扩容触发条件从单一CPU改成前面说的五个条件组合，其中连接池饱和度和决策耗时P99设为一类信号，直接触发扩容；错误率和队列积压设为二类信号，触发告警加人工确认；资源比值设为排查信号。第二步，重新设计压测场景，补了突增压测，并根据压测结果把实例数从八台扩到十四台，同时调大了连接池和队列容量。第三步，修缓存key，把长尾请求的缓存粒度调粗，命中率在压测中回到百分之八十八左右。
调整后的大促表现：峰值期间决策耗时P99稳定在三十五毫秒以内，连接池饱和度最高到百分之七十八，队列积压峰值没超过容量的百分之十五，错误率全程在背景水平。没有出现跳转超时导致的落地页打开失败。
这个案例里最值得说的不是扩容本身，而是触发条件的组合方式。如果只扩容不修缓存，机器加了但单位请求成本还是高，下次大促还得加更多机器。触发条件的作用不只是告诉你什么时候加机器，也告诉你什么时候该停下来查别的地方。
扩容决策的边界与收束检查项
最后说几个边界条件，这些是实际做决策时容易忽略的。
- 扩容有延迟。从触发扩容到新实例接流量，中间有启动、注册、预热的时间。大促场景下这个延迟可能有好几分钟，所以触发阈值要留出这个时间窗口的余量，不能等指标到顶了才动。
- 扩容不是无限的。跳转集群的下游——规则库、缓存、落地页服务——也有容量上限。跳转集群扩了但下游没扩，瓶颈只是转移了位置。
- 压测指标要定期复测。规则在变、流量结构在变、下游在变，上个月压出来的基线这个月可能就不准了。大促前至少复测一次。
- 触发条件要能自动执行，也要能人工覆盖。自动扩容快但可能误判，人工确认慢但能避免无效扩容。建议一类信号自动执行，二类信号人工确认，同时保留人工强制扩容的入口。
收束成一份检查项，大促前对着过一遍：
- 五个触发条件的采集是否都配了，阈值是否按当前流量结构校准过。
- 压测是否覆盖了稳态、峰值、突增三个场景，指标是否都落在安全区间。
- 扩容后的实例预热流程是否验证过，从触发到接流量需要多久是否清楚。
- 下游服务的容量是否同步评估过，瓶颈会不会转移。
- 缓存命中率在高压下的表现是否测过，掉了之后有没有预案。
扩容这件事，难的不是加机器，是判断什么时候加、加多少、加完之后瓶颈会不会换个地方出现。把触发条件和压测指标配成一组互相校验的信号，比盯着任何一个单一数字都靠谱。
总结：本文详细介绍了页面跳转的相关内容，包括页面跳转的原理、配置方法和优化技巧，包括页面跳转的原理、配置方法和优化技巧，包括页面跳转的原理、配置方法和优化技巧，包括页面跳转的原理、配置方法和优化技巧，包括页面跳转的原理、配置方法和优化技巧，包括页面跳转的原理、配置方法和优化技巧。希望这些页面跳转内容对您有帮助。
