上个月有个客户来找我，说把分流系统的采样率调低之后，日志里判定时延反而涨了。这事儿听着挺反直觉的对吧？我跟他排查了半天，最后发现根子出在请求合并队列的批次窗口上。分流系统的判定时效与吞吐能力，很大程度上取决于请求合并队列的批次窗口怎么定。 窗口设小了，判定是快，但后端压力扛不住；窗口设大了，吞吐量是好看了，可访客那边等不及。这篇文章就围绕这个取舍来聊，我打算先讲怎么判断问题出在哪，再对比几种方案各自适合什么条件，最后把选择边界划一划。
判断标准：先分清"等窗口"和"等资源"
调批次窗口这事儿，我的习惯是别上来就动参数。你得先搞清楚，当前这个瓶颈到底卡在哪个环节。
怎么看呢？翻日志。如果大量请求的等待时间都集中在窗口快要闭合的那一瞬间，那问题基本就在窗口本身——请求早就到了，但非得等窗口满或者超时才被处理。这种时候你把窗口调小一点，或者改成"满N条就触发"，一般就能缓解。
另一种情况，等待时间的分布比较均匀，而且后端处理耗时明显拉长了。这就不是窗口的问题了，瓶颈在下游资源——可能是PHP-FPM进程池打满了，也可能是指纹库查询在排队，或者是Cookie池那边读写锁竞争。这时候你调窗口大小没用的，得先去解决资源的问题。
判断方法其实很简单：在分流判定入口和出口各打一个时间戳，看差值分布。差值集中在窗口时长的某个比例上，那就是窗口问题；差值呈长尾分布，而且跟后端负载正相关，那就是资源问题。这里容易搞混，别看到时延涨了就条件反射去调窗口。
方案条件：三种批次窗口策略的适用场景
固定窗口：实现简单，适合流量平稳期
固定窗口说白了就是每隔固定毫秒数把队列里的请求打包处理一次，比如20ms、50ms这样。实现起来最简单，Nginx配合Lua或者PHP常驻进程都能做。
适用条件嘛：请求量波动不大、对判定时延要求不苛刻，比如允许50ms以内的额外延迟。缺点也很明显——流量低谷期窗口空转，高峰期窗口内请求数暴涨，处理时间不稳定。
满N触发：吞吐优先，适合高并发场景
队列攒够N条请求立即触发处理，同时设一个最大等待时间兜底。这个策略在请求密集的时候几乎不产生额外等待，吞吐效率最高。适用条件：请求量持续较高、后端处理能力充足、能接受低流量时单条请求等满超时。典型配置是N=50~200，超时兜底10~30ms。
思路是监控队列深度和最近几批的处理耗时，动态缩放窗口大小。队列积压了就缩小窗口加快消费，队列空闲了就放大窗口减少触发次数。
适用条件：流量波动剧烈，比如分时投放的账户；另外团队得有精力维护监控和调参逻辑。实现复杂度最高，但边界适应性更好。
选择边界：什么情况下不该用请求合并
请求合并队列并非万能。以下几种情况，合并带来的收益可能抵不过复杂度成本：
- 单请求判定耗时已经很低（低于5ms） ：合并省下的那点后端调用次数，换来的是每个请求多等一个窗口。算下来不划算。
- 请求量本身很低（日均几千次） ：队列大部分时间空转，窗口逻辑纯粹是负担。直接同步处理更干净。
- 判定链路中有强顺序依赖：比如后一个请求的判定需要前一个请求写入的Cookie状态。合并处理会打乱顺序，引入竞态。
- 对首字节时间有硬要求：某些落地页场景下，访客感知的加载速度直接关联跳出率。额外几十毫秒的窗口等待可能吃掉转化。
一个实用的边界参考：当日均请求量低于5万次、单次判定后端耗时低于10ms时，优先考虑不做请求合并；当日均请求量超过20万次、后端单次判定耗时超过20ms时，合并队列的收益开始明显。中间地带需要根据实际压测来定。
调参实操：从保守值开始逐步逼近
如果确定要用请求合并队列，建议按以下顺序调参：
- 先设一个保守的固定窗口：比如30ms，观察一周的判定时延分布和后端负载。这个阶段的目标是建立基线，不是追求最优。
- 看窗口内平均请求数：如果大部分窗口只攒到个位数请求，说明窗口偏大或流量偏低，可以调小窗口或切换到满N触发。如果窗口经常爆满且处理排队，说明窗口偏小或后端需要扩容。
- 引入满N触发+超时兜底：把窗口从"时间驱动"改成"数量驱动+时间兜底"。N的初始值可以设为后端单批处理能力的70%左右，留出余量。
- 观察P95和P99时延：平均值好看不代表体验好。P99时延如果远超窗口时长，说明存在排队积压，需要缩小窗口或增加处理并发。
- 按投放时段设不同参数：分时投放的账户，高峰时段用满N触发抢吞吐，低谷时段切回固定小窗口保时延。这个切换可以通过配置文件热加载实现，参考动态分流规则库版本管理里的热更新思路。
之前有个团队做金融行业投放，日均请求量在三十万左右，后端单次判定涉及指纹比对和Cookie池查询，耗时大概15~25ms。最初用固定50ms窗口，P99时延到了120ms，访客侧偶尔反馈页面"卡一下"。后来改成满80条触发、超时兜底15ms，P99降到45ms左右，后端CPU峰值反而降了一成多。顺带说一句，他们后来把这个逻辑和分流特征提取时机的异步采样做了配合——合并队列只处理需要同步判定的请求，异步特征走另一条通道，互不阻塞。
小结
请求合并队列的批次窗口，本质是在"每个请求等多久"和"后端每批处理多少"之间找平衡点。判断标准是先分清瓶颈在窗口还是在资源；方案条件上，固定窗口适合平稳流量、满N触发适合高并发、自适应窗口适合波动场景；选择边界则提醒我们，低请求量、强顺序依赖、低时延要求的场景下，不做合并可能是更理性的选择。调参没有万能值，从保守基线出发、盯住P95和P99、按时段分策略，是相对稳妥的路径。
常见问题
请求合并队列会影响落地页加载速度吗
要看窗口设多大。如果窗口在20ms以内，访客基本感知不到；超过50ms且后端处理再叠加，首字节时间会明显变长。建议把窗口时长控制在后端单次判定耗时的三分之一以内，这样合并带来的额外等待不会成为主要瓶颈。
批次窗口调小之后后端压力反而更大了，怎么回事
这个要看情况。窗口调小意味着单位时间内触发次数变多，如果后端每次处理的固定开销（比如建立连接、加载规则）占比较高，触发越频繁总开销越大。说白了，省下的等待时间变成了更多的重复劳动。这种情况应该优先合并后端调用的固定开销，而不是继续缩窗口。
满N触发里的N值有没有推荐范围
没有通用值，但可以从后端单批处理能力的70%起步试。N太小等于没合并，N太大则低流量时全靠超时兜底、失去意义。观察指标是窗口内有请求等待超时的比例，超过两成就说明N偏大了。
自适应窗口是不是一定要上
不一定。自适应窗口的维护成本不低，需要监控队列深度、维护伸缩逻辑、处理参数抖动。如果流量曲线比较规律、固定窗口或满N触发已经够用，没必要为了"自适应"三个字增加系统复杂度。
延伸阅读
请求合并队列解决的是判定链路的吞吐与时延平衡问题，而整个分流系统的技术选型和架构设计还有更多需要权衡的地方。下面这篇从整体视角梳理了斗篷技术的系统构成与风险认知，可以作为本文的上层参考。
