当您的流量接近可能导致应用程序崩溃的预定义阈值时，Waiting Room 会对访客进行排队。
一旦您为特定的应用程序页面创建并激活了候诊室：
-
如果页面没有遇到大流量，访客将直接访问该页面。
-
如果页面流量接近用户定义的阈值，访客将进入虚拟候诊室，直到轮到他们访问页面：
- 每个用户都会收到一个 cookie，以先进先出 (FIFO) 的顺序管理从候诊室到源网站请求的动态流出。
- 在候诊室中，用户的浏览器会自动每 20 秒刷新一次，以为他们提供有关其预计等待时间的更新信息。
- 当用户退出候诊室并到达您的应用程序时，他们可以离开并重新进入，而无需等待会话持续时间指定的时长。
- 因为候诊室支持动态流入和流出，新名额会更快出现，并且估计的等待时间更短、更准确。
Waiting Room 构建在 Workers 上，该服务在 Cloudflare 数据中心的全球网络中运行。
当请求到达由 Waiting Room 覆盖的主机或路径时，该请求会转到地理上最接近的数据中心的 Waiting Room Worker。然后 Worker 需要做出决定：是将用户发送到队列还是网站。
该决定本身取决于两个因素：管理员定义的阈值和 Waiting Room 状态。
对于管理员定义的阈值，两个重要的衡量指标是 total active users（总活跃用户数）和 new users per minute（每分钟新用户数）：
-
total active users是针对候诊室覆盖的页面上您希望允许同时存在多少用户而设定的目标阈值。 -
new users per minute定义了网站每分钟用户流入量最大速率的目标阈值。
这两个值中的任何一个急剧激增都可能导致排队。另一个影响我们计算 total active users 的配置是 session duration（会话持续时间）。自从向由候诊室覆盖的任何页面发出请求以来，用户在 session duration 分钟内被认为是活跃的。
另一个因素是 Waiting Room 状态，该状态在本地数据中心级别维护，但也会根据全球各地的流量不断变化。每个数据中心都使用自己的 Waiting Room 状态。这种状态是该时间点全球该网站可用流量模式的快照。使用这种方法的优点（在 Worker 级别做出决定）是我们可以在不给请求增加任何显著延迟的情况下做出决定。Waiting Room 算法根据 Waiting Room 状态动态分配每个 Worker 可用的特定数量的插槽。当 Worker 内插槽耗尽时，排队就开始了。由于没有增加额外延迟，客户可以随时开启候诊室，而不必担心给其用户带来额外延迟。
Waiting Room 状态每隔几秒钟就会利用全球信息进行更新。我们在 Cloudflare Durable Objects 中设置了一个管道，可确保流量变化传播到全球各地。这种架构确保我们不会引入额外的延迟，并且我们以尽可能接近实时准确性来做决定。
有关架构及我们为何做出这些决定的更多详细信息，请参阅我们的技术博客深入探讨 ↗。