AB页跳转流量分层：核心定义与概念边界
先把这个场景摆出来：跳转系统那一秒里塞满了各种请求——搜索爬虫在抓、真实用户在点、监控探针在探、还有一堆特征异常的流量混进来。资源就那么多，你总得决定先伺候谁、谁往后排、谁干脆先晾着。AB页跳转流量分层干的就是这件事。它按请求的来源特征、业务价值、时效敏感度打上不同层级标签，每层配一套独立的处理队列和资源额度，最后调度器看着层级顺序和额度余量来定谁先执行。
这里面有两个东西是绑死的，拆不开。优先级队列管的是顺序——同时来了一堆请求，谁排前面。带宽配额动态分配管的是容量——每个层级单位时间里能用多少计算资源、多少连接数、多少出口带宽。缺一个都不行。你要只讲优先级不讲配额，高优先级的流量能把资源全吃干净，底下几层直接饿死。反过来只配额不优先级，分配就僵住了，突发情况来了关键请求也拿不到额外的资源。
有个事得说清楚，这套东西跟普通的请求限流不是一码事。限流盯的是总量，超了就拒或者排队等着。流量分层盯的是结构，总量不变的情况下，通过层级划分和配额调整来改变资源往哪流。还有个容易搞混的是负载均衡——那是解决请求分到哪个节点的问题，流量分层解决的是请求到了节点内部之后按什么顺序处理、资源怎么分，两个东西不在一个抽象层面上。
优先级队列的构建逻辑与层级划分
层级怎么划？一般看两类信号。一类是请求自己带的信息，User-Agent类型、来源IP段、请求频率、Cookie和会话状态、Referer来源，这些都算。另一类是业务侧配的东西，比如当前投放计划里哪些页面版本在灰度验证、哪些地域的转化目标正在冲刺、哪些渠道的流量成本已经超标了。这两类信号合在一起，决定一个请求落到哪个优先级层级。
典型的层级结构大概三到五层。最高那层放的是时效敏感、业务价值又明确的请求，像正在参与灰度实验的特定用户群、转化概率高的回访会话。中间层是常规真实用户流量，量大，个体之间价值差异不明显，但整体是业务的基本盘。再往下是低频爬虫和监控探针，这些对延迟不敏感，排队等等没关系。最底层留给特征异常的请求——不一定马上拒掉，但也不该占着高优先级的资源。
队列调度算法选择
调度算法怎么选，得看跳转系统的延迟预算。严格优先级调度适合层级之间延迟要求差得特别远的情况，高优先级队列只要非空就永远先处理，实现简单，但低层级可能被饿死。加权公平队列给每层分一个权重，调度器按权重比例轮流从各队列取请求，既保住了高优先级的优势，又给低层级留了最低处理速率。赤字轮询在加权公平的基础上加了信用累积，空闲层级的配额可以临时转给繁忙层级，流量模式变化频繁的投放场景用这个比较合适。
实际部署里，多数AB页跳转系统用的是加权公平队列加严格优先级的混合模式：最高层级走严格优先级，保证决策延迟；其余层级走加权公平队列，维持资源分配的均衡。权重值不是写死的，会根据实时流量结构和业务目标动态调，调整频率通常跟配额分配周期对齐。
带宽配额动态分配的运行机制
配额的度量维度与初始分配
带宽配额这个词，在跳转系统的语境里其实涵盖三个维度。一个是连接数配额，每层能同时持有的活跃连接数上限。一个是计算资源配额，每层能占用的CPU时间片或者规则引擎调用次数。还有一个才是出口带宽配额，每层每秒能消耗的出口流量上限。这三个维度对应跳转决策链路里不同的瓶颈点，得独立配，但又互相约束着。
初始配额怎么给？通常基于历史流量画像和业务优先级权重来算。历史流量画像提供各层级请求量的基线比例，业务优先级权重由运营侧根据当前投放策略来定。两个数乘一下得到初始配额值，再做最小配额保底和最大配额封顶，第一版配额表就出来了。
配额之所以要动态调，是因为流量结构在分钟级别就可能大变。触发调整的信号有这么几个：某层级队列积压深度超过阈值了、某层级请求的决策延迟分位数突破基线了、上游投放平台出现预算消耗速率突变、特定地域或渠道的流量占比短时间内偏移超过设定比例。 调整幅度走渐进原则，单次调整通常不超过当前配额值的20%，调整间隔不低于30秒。这么做的目的是防止配额在相邻周期之间来回震荡，调度器行为变得不可预测。检测到持续性流量结构偏移的时候，系统会在多个调整周期内逐步把配额推向新的平衡点，不会一次性跳过去。
配额借用与归还机制
动态分配有个关键补充，就是配额借用。某层级当前周期没用完配额，系统整体资源又没饱和，空闲配额可以临时借给配额紧张的高优先级层级。借用关系记在配额账本里，后面周期逐步归还。归还的优先级高于新的借用请求，防止借用关系无限累积把账本搞失真。 借用得有上限，通常不超过借出层级基础配额的50%。过了这条线，哪怕借出层级还有空闲资源，也不让新的借用了，这样借出层级在流量反弹时能迅速把资源收回来。
适用条件与边界：什么时候该用，什么时候不该用
流量分层加配额动态分配，适合几个条件同时成立的场景。跳转系统承载的流量类型性质差异明显；系统资源在峰值时段确实存在竞争；业务侧对不同类型请求的时效要求不一样；团队有能力实时监控各层级队列状态和配额使用率。如果流量类型很单一、资源始终充裕、或者业务对所有请求的时效要求都一致，那引入分层机制的复杂度可能比它带来的收益还大。
边界这块，流量分层解决不了规则引擎本身的准确性问题。规则配错了，大量真实用户被划进低优先级层级，分层机制只会让这个错误的影响来得更快。配额动态分配也替代不了容量规划——它是在给定容量下优化资源流向，总容量撑不住基础流量的时候，什么配额策略都挡不住服务退化。
说个实际案例。某工具类产品的投放团队，日均点击量一千二三的量级，服务器双核四线程。他们一开始把所有非爬虫流量放在同一个优先级，结果下午投放高峰时段，灰度实验组的跳转决策延迟从平均80毫秒涨到接近400毫秒，实验数据直接失真了。调整分两步走：先把灰度实验组和常规用户拆进两个优先级层级，保住实验组的最低处理速率；然后引入带宽配额动态分配，检测到实验组队列积压就自动从常规用户层级借连接数配额。最后实验组延迟在高峰时段稳定在120毫秒以内，常规用户的延迟上升控制在15%以内。这个案例的边界在哪？借用机制只在实验组流量占比低于总流量20%时有效，超过这个比例，配额账本频繁触发借用上限，调整效果就明显衰减了。
相邻概念对比：分层调度与相关机制的区别
与速率限制的区别
速率限制是给某类请求在单位时间内的处理数量设一个硬上限，超出的直接拒掉或者延迟处理。流量分层不设硬上限，它靠配额比例来引导资源流向。速率限制的粒度通常只针对单一维度，比如单IP每秒请求数；流量分层的粒度是多维度组合——来源特征、业务价值、时效敏感度都得看。两者可以叠加用，速率限制负责过滤明显异常的请求，流量分层负责在正常请求之间分资源。
服务质量等级在网络领域一般指给特定流量打个优先级标签，底层网络设备按标签来调度。AB页跳转流量分层的层级划分发生在应用层，依据的是业务侧可配置的规则；服务质量等级的标记通常由网络层完成。而且流量分层的调整频率远高于服务质量等级配置，前者秒级到分钟级就能完成配额重分配，后者的策略变更通常要分钟级到小时级才能全网生效。
简单轮询对所有请求一视同仁，按到达顺序依次处理。流量分层调度承认请求之间有价值和时效的差异，并且把这个差异显式地写进调度逻辑里。选哪种方式，取决于业务是不是需要对不同请求做差异化处理。所有请求确实同等重要、资源又充裕的时候，简单轮询的确定性和低开销就是优势；资源竞争出现了、请求时效要求分层了，流量分层的调控能力就变得必要。
配置与观测的核心参数
优先级队列和配额动态分配的可观测性，依赖三类参数。队列状态参数：各层级当前排队深度、入队速率、出队速率、平均等待时间。配额使用参数：各层级当前配额值、实际使用量、使用率、借用与归还的累计次数。决策效果参数：各层级请求的端到端决策延迟分位数、层级间延迟差异比值、配额调整后的延迟收敛时间。
观测的重点不是单点数值，而是层级之间的关系稳不稳定。高优先级层级的延迟分位数持续上升，说明配额可能覆盖不住它的流量增长了。低优先级层级的等待时间出现数量级跳变，说明配额借用可能太激进，低层级资源被挤压过头了。这两类信号，是触发配额分配策略复审的主要依据。
