摘要

  • 针对同一合格缓存对象的并发请求可以共享一次源站获取，减少重复工作；等待列表也是这个机制的一部分。
  • 若获取结果既不能服务等待者，又不能建立hit-for-pass直通标记，后续请求可能反复排队，从并发变成连续处理。
  • 源站请求更少，不足以证明整体省钱或服务更好。需要同时看完成交付、等待边界与响应能否合法共享。

源站安静了，用户未必已经拿到结果

一个热门对象在边缘缓存中过期，用户同时请求它。源站没有为每位用户各做一次获取，而是只收到较少请求。这个结果可能是真实改进：重复工作被合并了。但它没有单独回答，用户是否已经拿到可用响应，是否等待过久，或是否有人收到了不应共享的信息。

Fastly把该机制称为请求合并，即把同一对象的并发请求合成一次源站请求，再视结果是否适用，服务挂在等待列表上的用户。“是否适用”不是在加入队列时已经确定的事实。

因此，对采购者而言，源站减负是验收输入，不是完整验收。它可以保护昂贵或有限的源站资源，却不能独自证明交付完成、等待合理、复用安全或总体账单下降。本文没有测量任何客户的这些结果，只依据供应商公开机制解释为什么它们不能互相替代。

等待不是异常附属物，而是合并的条件

没有请求合并时，热门对象突然失去缓存覆盖，可能引发接近同时到达源站的请求洪峰。Fastly的等待列表允许后来的合格请求挂到已经进行的获取上，而不是立刻再发起一份重复工作。

若响应适合等待者，公共工作就能够服务多位用户。机制上的收益明确：源站少做重复操作，负载也可能更加平滑。但这些用户随后依赖同一次获取的进展，结果能否使用与何时可用，都变得重要。

不能把这个描述扩大成整个CDN对相同可见网址只有一个全球队列。适用单位是相关交付路径中的缓存对象及其变体。Fastly明确说明，hit-for-pass标记遵守Vary，同一个缓存地址下的不同变体可以具有不同处理状态。

所以，同一个网址不是跨用户共享响应的充分证据。公共资源与个人响应即使呈现类似需求，也有不同复用边界。减少源站操作的目标，不能把这个区别抹去。

一个无用结果，可能让队列重新开始

Fastly说明了一条困难分支：请求已经合并，但源站返回的响应不能用于等待请求，而且无法创建hit-for-pass标记。下一位等待者会发起新的源站请求，其余请求可能在它后面组成另一个等待队列。

如果相同条件反复出现，源站获取就可能连续进行，而不是并发处理。官方指南警告，某些情况下等待可达到数分钟。这是文档列出的可能性，不是本文观察到的事件、客户账户预测，也不是每个私有响应的必然结局。

VCL参考文档对一个条件说得更明确。beresp.cacheable为false时，不保存响应对象，也不创建hit-for-pass对象，即使响应处理以deliver结束。被释放的后续请求因此可能马上加入新的队列。

这里，低源站请求量可能有两种不同解释。一种是一次工作有效完成了多位用户的任务；另一种是未完成请求积在队列里。只看聚合请求数，很难区分真正减负与交付瓶颈。

但不能据此提出“让所有响应可缓存”的解决办法。相同参考说明，把缓存资格标志设为true可能导致原本不可缓存的内容被保存。把个人或保密响应变成共享内容，不是改善等待指标的合格代价。

标记“不合并”，不等于缓存私有正文

hit-for-pass提供另一种控制。缓存里可以保存一个标记，告诉相关资源或变体的请求不要合并，而应分别获取源站结果。缓存条目在这里记录的，是保持工作分离的处理决定，不是供其他用户阅读的私有正文。

在官方描述的CDN VCL响应阶段直通路径中，满足相应处理条件时，可以建立该标记，而不把响应内容用于服务等待列表上的其他用户。判断标记和判断响应正文，必须分开。

Fastly还区分请求阶段直通：在源站获取之前，已确定不应复用的工作，可以不进入请求合并。能否提前识别这类内容，影响等待列表是否形成。

这些控制仍有接口与条件限制。VCL特定处理不能冒充所有Compute缓存接口的统一行为。分开获取也不会消除需求：原先等待的工作可能转为并发抵达源站，但源站不会因为换了队列分支就自动多出处理能力。

暂时复用与长期保存，是不同状态

请求合并指南还描述，未标为私有的响应，即使带有max-age=0或no-cache，也可能服务已经等待的用户，而下一次请求仍会缓存未命中。这个等待列表案例区分了获取期间复用，与给未来请求留下仍然新鲜的缓存对象。

它不能推广成HTTP指令的普遍等价，也不能说明个人响应因新鲜期为零就有权跨用户共享。更不能把它和beresp.cacheable为false的条件混成同一个状态。

Fastly的解释博客又以“可缓存且剩余生命周期为正”定义可用对象指标。这个指标的计数条件，不能不加说明地套在其他指南描述的每一种等待列表交付上。指标名称可读，不代表计数边界已经一致。

流式未命中还有时间维度。启用时，源站响应头到达后，可用数据就可能开始进入缓存，缩短新请求与初始获取重叠的窗口。因此，更少的请求合并也可能伴随更快、更有效率的源站响应。发生频率本身，不是成功或失败的裁判。

关闭合并，可能同时放弃旧内容选项

CDN VCL的req.hash_ignore_busy控制也不只是队列开关。Fastly说明，启用后请求不再有合并资格，但仍可能由新鲜缓存命中服务；与此同时，旧对象变得不可用，stale-while-revalidate和stale-if-error效果被禁用。

因此，这种控制与请求阶段直通不同，还可能改变源站并发和异常期间的交付选项。把它描述成没有其他后果的消除等待办法，会漏掉控制面的重要一部分。

旧内容也有自己的正当边界。Fastly的旧内容教程讨论允许窗口和条件，包括源站发生问题时的情形。它没有保证每一种错误都会自动回退到旧响应，更不能证明旧权限、库存或价格总是适合继续交付。

应用需要回答什么年龄、什么内容仍然有效。更快并不自动意味着更正确，保留可用性选项也不能凌驾于用户所需的准确性。

验收应回到有用交付

一份简短决定记录可以明确内容类别、真实缓存身份与变体、授权复用范围、适用服务接口、失败分支，以及可接受等待和新鲜程度。这个做法是编辑分析的建议，不是Fastly强制功能，也不是对任何客户配置的审计。

这样，采购与运维才能提出具体问题：源站获取变少的同时，是否有更多请求完成了有用交付，等待是否仍在可接受边界？不能复用的工作是否保持分离，还是仅把不可持续的洪峰从队列转移回源站？

本文没有操作或测试Fastly客户账户、服务、缓存、VCL或任何实际配置。商业结论也因此保持边界：请求合并在共享工作完成合法交付时具有价值，而不是在某张源站请求图更安静时就已经被证明成功。

来源