我们实际上找不到一出一进的任何优点。 简而言之，这种方法的问题是，当用户是电子商务网站的访问者时，网络服务器不知道它在任何时刻有多少个并发用户。 这是一个展示性的问题。 原因就在这里。
在这篇文章的后面，我们还告诉你如何使用基于价格的虚拟房间来保护你的网站。
A rate-based Virtual Waiting Room does more than just hold visitors; it controls exactly how many people are allowed through over time. A simple queue may preserve order, but won't deliver stable load when there is abandonment, or people going away from the queue and coming back after their turn has been called. A rate-based queue focused on delivering the exact right number of people to the site every minute is much better at preserving stability.
For enterprise organisations, that distinction is critical. During a launch, onsale, or major public event, you do not just need fairness; you need controlled throughput. If too many users are released in one burst, the site can still slow down or fail. Auto-scaling helps with gradual traffic increases, but sudden surges happen faster than scaling can react, so you need a mechanism that actively meters demand in real time.
Queue-Fair is built around that principle. It gives enterprise-level organisations accurate, rate-based control, first-come, first-served fairness, and a much better chance of keeping the site stable during extreme demand. It can usually be deployed in about five minutes with a single line of code, and Free Queue lets teams get started for free.
A rate-based approach helps prevent crashes by smoothing the arrival of visitors into a stable flow. Instead of opening the gate too widely and hoping the site copes, it meters access at a pace the origin can actually handle. That keeps pressure on critical services under control and reduces the chance of a sudden concurrency shock taking down the platform.
This is more effective than relying on infrastructure alone because infrastructure is often reactive. If a traffic spike lands within seconds, for example from ticket onsales or timed product launches, extra instances and capacity may not come online quickly enough to stop the first wave from overwhelming the bottleneck. A rate-based Virtual Waiting Room deals with the traffic pattern itself, which is often the true cause of the incident.
Queue-Fair gives organisations that protection in a form that is both powerful and easy to deploy. With one line of code, around five minutes to go live, and a Free Queue option at no cost, enterprise teams can quickly add a highly practical defence against crashes, overload errors, and unstable customer journeys.
It is most useful when demand is intense, sudden, and commercially important. That includes ticket on-sales, product drops, flash sales, presales, public deadlines, campaign launches, and any event where many people are likely to arrive together. In these situations, the challenge is not merely the number of visitors but the concentration of arrivals in a short time window.
A rate-based approach is especially valuable for enterprise organisations because it supports operational control. Teams can protect the site, maintain fairness, and tune throughput to match real-world conditions instead of guessing. That means fewer crashes, fewer emergency interventions, and a better customer experience during the moments that matter most.
Queue-Fair is designed exactly for those high-pressure scenarios. It combines rate-based accuracy, fairness, rapid deployment with a single line of code, and a Free Queue option for free. That makes it one of the fastest and most effective ways to prepare a website for sudden demand without waiting for a major replatforming or infrastructure project.
传统上，电子商务服务器的配置是为了支持最大的并发用户数，负载通常是这样定义的。 使用这种方法来运行网站的队列有一个问题--我们用速率来解决这个问题。
问题的出现是因为访问者只是在他们的浏览器加载每个网页时才真正使用网络服务器。
例如，我们假设一个电子商务网站正在销售门票。 从访客旅程的开始到访客旅程的结束（用户会话），有六个页面，因为访客
整个交易过程平均需要5分钟。
再比如说，每分钟有100个游客来买票，完成这一过程的平均时间是5分钟。 在任何给定的时间点，有500人同时在交易过程中，服务器必须被配置为支持500个并发用户。
人们可能会认为，可以创建一个并发用户计数器，每次有新的访问者到达主页时都会递增，每次有访问者完成交易时都会递减，这样就可以告诉你一个服务器在任何时候处理多少个用户，但这是行不通的。
它不会起作用，因为不是每个访问者都能完成交易。人们会改变主意，或分心，或离开后再回来。 因为网络服务器只在访客的浏览器加载页面时与他们互动，网络服务器没有办法知道这种情况何时发生，或对谁发生。
相反，为了确定一个访问者不再是交易过程的一部分，单一服务器必须等待，看是否有更多的页面请求从该访问者那里到达，然后超时该访问者的会话。 超时必须总是设置为比平均交易时间长得多（比如在这个例子中是20分钟），因为有些访客完成交易的时间比其他访客长得多。
我们可以增加设施，在每次访客会话超时时递减自己的名义并发用户计数器，但这样做的结果很差。
如果每分钟到达的100个访客中有10%没有继续完成他们的交易，那么完成交易的访客将平均活跃5分钟，没有完成交易的访客将被认为至少总是活跃20分钟（实际上在考虑多个会话时，会话超时加上平均会话时间的可能性更大）。
这就是90 * 5 + 10 * 20 = 650，服务器将报告650个并发用户，尽管它实际上并不那么繁忙！这就是所谓的 "不忙"。
此外，在这些并发用户中，有多达10*20=200人没有真正使用该网站，而是在超时过程中，这占报告的并发用户的30%以上，尽管只有10%的访问者未能完成交易。
现在我们假设有人希望在这个网站上添加一个队列，由我们的并发用户计数器控制。 一旦该网站达到容量，那么排在队列前面的人只有在计数器递减时才会被传递到该网站。 这被称为一出一进的队列。 将会发生的情况是，30%的时间里，排在队列前面的人将会等待一个不打算完成交易的人完成不完成他们的交易。
还有额外的技术整合工作和网站上创建和运行计数器的负荷，以及与队列系统共享该信息。 如果共享或计数机制出现故障或中断，队列就会被卡住。 更糟糕的是，如果单个服务器变得如此繁忙，它不能更新队列服务器以告诉队列服务器让下一个人进来，队列也会被卡住。
所有这些问题都很容易和简单地得到解决，而是以一个恒定的、固定的速率从队列的前面发送访问者--在这种情况下，每分钟100个访问者。
这样就不需要测量实际的并发用户数，也不需要与售票网站进行复杂的整合，更没有排队卡住的风险。
这就是为什么我们在 2004 年为繁忙的网站发明了基于费率的虚拟候机室并申请了专利。
如果你知道一个网络服务器处理多少个并发用户，以及从交易流程中的第一个页面到订单确认页面的平均交易时间或访问时间，你就可以用利特尔定律将其转换成排队率，即用用户数除以时间长度，像这样。
排队率 = 并发用户/交易时间
Queue-Fair将以您指定的速度向您的网站输送访客--我们拥有迄今为止最精确的队列人工智能，以确保您每分钟想要的访客数量就是您每分钟得到的访客数量，自动计算出轮到他们时不在场的人，以及晚回来的人。
这如何转化为并发用户的数量？ 当然，不是每个到达你的网站的访问者都会用准确的平均交易时间来完成他们的交易，但由于大数法则，你会通过Queue-Fair获得非常稳定的并发用户数。
例如，假设你的排队率是每分钟100个访客。 我们会在每分钟向您的网站源源不断地发送100名访客--这就是我们的工作，而且我们在这方面的能力令人惊叹。 我们还假设，人们使用你的网站的平均时间为5分钟，其中70%的人从排队通过到提出最后一个页面请求（无论他们是否完成交易）的时间在4到6分钟之间。 这是一个标准偏差，即平均数的两边各1分钟。 从统计学上讲，这意味着每一个需要5.5分钟的访问者，都会有另一个需要4.5分钟的访问者，因此，当你以任何方式计算大量的访问者时，这些跨越多个会话的个人访问时间的变化往往会相互抵消。 大数法则说，涉及的人数越多，这种抵消就越精确。
到底有多准确？ 我们可以用一点统计学的方法来解决这个问题。 有一个5*100=500的样本量，这就是这里涉及的大数。 这就是你要计算的人数。 这意味着交易时间的平均值的标准误差是1（标准差，1分钟）除以样本量的平方根（所以是500的平方根），根据平均值的标准误差的统计公式，交易时间的平均值的标准误差是0.044分钟，或只是2.7秒，这还不到百分之一。
这意味着，如果队列速率为100，每个访问者的交易时间为5分钟，或多或少，你应该期望你的网站在70%左右的时间里有495到505个并发用户，所以计算表明，使用基于速率的队列将为你的网络服务器提供非常稳定的负载。
但是，这种计算方法准确吗？ 这里有一些微妙之处--例如，每次计算并发用户时（即在任何给定的时间内），我们快乐的平方根的样本量并不总是正好是500，而且正态（高斯）分布可以给出负的交易时间，这在现实生活中并没有发生。 因此，我们使用一个逐个访问者、逐秒的模拟器来进行测量，以检查这些类型的计算，这告诉我们，根据上述数字，你应该在70%的时间内期待493到507个访问者，所以数学上非常好地保持了这一点。 测量数据还告诉我们，你的网站至少有95%的时间会有500±15个并发用户。
这可能比你的网络服务器能够测量使用你的网站的人数的准确性更稳定！这是很重要的。 更妙的是，这里真正巧妙的是，即使你不知道你的访问者的平均交易时间或标准偏差是多少，这些数学量存在，无论你是否知道它们，你都会得到一个稳定的负载。
其结果是，Queue-Fair将提供你想要的每分钟访问量，而且几乎完美无缺，从而使你的网站上有非常稳定的并发用户数，以及你可以完全控制的稳定的网络服务器负载。
万岁!
现在是一个警告。 值得注意的是，您网站上的并发用户数量的稳定性--因此您的服务器负载的稳定性--确实关键取决于您的虚拟候机室供应商每分钟向您发送您想要的访客数量的准确性，因此这是您选择虚拟候机室平台时的一个关键因素。因为我们提供世界上最准确的虚拟候机室，没有人比Queue-Fair更能阻止您的服务器被淹没。
如果你不知道一台服务器可以处理多少个并发用户，或者交易时间，怎么办？你可以看看可能成为你瓶颈的页面--通常是点击 "立即购买 "按钮的页面。 使用谷歌分析，找到该页面的每月独立访客，或计算你的每月订单。 将此除以30 * 24 * 60 = 43,200，这是一个月的分钟数（大约）。 这是你整个月每分钟的平均访客数。 将其乘以3。 这是你在工作时间内每分钟的平均访客数（大约）。 将其翻倍。 这可能是一个用于排队率的安全数字。
例如，假设你每月处理100,000个订单--也就是100,000次点击 "立即购买 "按钮。 这就是100,000/43,200=每分钟2.31个订单。 你会期望这些订单大部分是在白天，而你的服务器在晚上会比较安静，所以用这个数字乘以3，就是每分钟7个订单，作为对你的服务器在营业时间内繁忙程度的粗略估计。 如果得出的数字小于50：需求会有高峰和低谷，所以如果你的服务器在高峰时段没有明显的缓慢，就用这个数字乘以2，得到每分钟14个活跃用户。 如果这个数字超过50：每分钟的高峰和低谷相比之下会更小，把这个数字加倍并不安全。 你最终得到的数字可能是一个安全的排队率开始的数字，相当于你可以安全地管理每秒多少个请求；如果你发现你的系统在这个速度下仍然对最终用户的性能有反应，你可以随时增加它。
如果你的订单有时间戳，你也可以看看上个月你在一分钟内的最大订单量--但要谨慎使用，因为你不知道在这一分钟内你可能因为服务器变慢而放弃了多少订单，所以要减少20%。
本文的其余部分讨论了其他一些计算队列速率的方法。
值得指出的是，在通常情况下，"并发用户 "至少有两种定义。
我们使用的定义是："在任何时候参与交易流的人数"。 这是你需要知道的设置排队率的关键数字。 这就是现在有多少用户正在浏览你的网站。并发会话的数量通常比并发连接或并发用户的数量大一些，因为有些会话正在超时过程中，增加了平均会话时间。
与此相对应的是多少个并发请求，也就是你的网络服务器在任何时候正在处理的HTTP请求的数量。 非常令人困惑的是，很多技术人员在说有多少个并发用户时，会指多少个并发请求。
然后是并发连接（或并发TCP连接到你的网络接口卡上的同一个服务器端口），这是任何时候在你的服务器端口或后端服务上打开的TCP/IP套接字的数量。 在进行页面请求时，浏览器默认会保留连接，以备页面提出任何进一步的请求，或用户转到不同的页面。 这就减少了每秒钟打开新的TCP/IP连接的请求数，使服务器进程更加有效。 这些并发连接的超时因浏览器而异，从60秒到永不关闭。 你的服务器也可以在一段时间没有活动后自动关闭连接。在Linux网络服务器上，你可以用这个命令获得同一服务器端口的并发连接数。 netstat -aenp | grep ":80\|:443" | wc -l
如果你感到好奇，可以试试。同样，有些人也把这称为 "并发用户"，其实它指的是并发连接。
事实上，如果你要求你的主机提供商告诉你你的网络服务器处理的最大并发用户数（多少峰值流量），他们实际上可能会给你一个并发会话、并发请求或并发连接的数字，原因很简单，他们不知道你的平均交易时间、交易流程中的页面数量，或任何其他信息，使他们能够告诉你你的网络服务器处理多少个并发用户。 所有这些数字都有不同的值。
如果你向你的主机供应商或技术团队询问有关最大流量水平的信息，你必须澄清他们指的是并发用户、并发会话、并发请求还是并发连接，这一点超级重要。
原因就在这里。 每个页面都是一个单一的HTTP请求，但所有的图像、脚本和其他来自你的Web应用程序的文件，浏览器用来显示页面也是HTTP请求。
让我们想象一下，你的技术团队告诉你，服务器支持500个并发用户，但他们实际上是指500个并发请求。 用你的5分钟交易时间，你使用上述公式，假设你的网站可以支持每分钟100个访问者。
可以吗？不能。
当人们通过交易流程时，他们实际上只是在每个页面加载时从你的服务器发出请求。 这影响到你的服务器每秒能处理多少流量或活跃用户。 在5分钟的交易时间中，对于一个普通用户来说，这只是几秒钟的时间。 因此，你可能认为500个并发请求意味着你可以处理更多的并发用户，但你很可能是错的。你现在能明白，以多少流量或活跃用户总数来理解你的网站容量是多么复杂的一件事吗？
为了从最大的并发请求总数中计算出你的最大并发用户，你还需要知道
你可能已经知道1）和2）--在我们的例子中是6页和5分钟。 你可以很容易地计算你在进行交易时看到的页面。如果你不知道平均交易时间，谷歌分析可能会告诉你，或者你可以检查你的网络服务器日志。
对于3）和4），火狐浏览器可以提供帮助。 在你的网站上的一个页面上点击右键，选择检查元素和网络标签。 然后点击CTRL-SHIFT-R来完全刷新页面。 你会看到列表中页面的每个元素的网络加载时间。 你要确保你能在 "已传输 "一栏中看到传输大小，否则文件可能是从缓存中提供的，这可能会扰乱你的计算。 你可能会看到一些脚本和其他资源来自你网站以外的服务器，所以你可以在左边的过滤框中输入你网站的域名。 要看持续时间栏，右击任何一栏的标题，在弹出的菜单中选择时间->持续时间。 你的屏幕应该看起来像这样。
此页面的火狐网络标签，显示来自queue-fair.com的持续时间和请求数量。
用于显示你的网页的文件可能来自许多不同的网站，所以你也要使用左上角的过滤器，只显示来自你的网站的文件--但前提是你确定 这些来自其他网站的文件不是导致页面加载缓慢的原因，或者是你的瓶颈的一部分。
火狐在显示屏的左下方为你计算请求数，仅这一个页面就显示了36个HTTP请求。
你需要对交易流程中的每一个页面都这样做--计算总数，然后除以页面数，就可以找到每一个页面的平均HTTP请求数，也就是我们列表中的第3项）。 现在你可以看到为什么每个HTML页面的子请求数是你的网络服务器能处理多少流量的一个关键因素。
对于数字4)，你需要看一下持续时间一栏，找出所有页面的HTTP请求的平均数。 如果你不确定，可以假设半秒--反正这里面有很多不确定性（见下文）。
让我们举一些例子数字。 我们已经说过，在这个例子的服务器流程中有六个动态页面，这就是1)，平均交易时间是5分钟，这就是2)。 让我们假设每个页面有36个HTTP请求，这就是3)，每个HTTP请求的服务器处理时间为半秒，这就是4)。
有了这些数字，一个可以处理500个并发请求的服务器可以每秒处理500/（0.5秒）=1000个HTTP请求，也就是每分钟60,000个HTTP请求，当它完全达到极限时。
在5分钟的交易时间内，它可以处理5 * 60,000 = 300,000个HTTP请求。 似乎很多，对吗？
但是，对于每个访问者来说，有六个页面，每个页面平均有36个HTTP请求，因此，这就是6*36=216个请求。
因此，300,000个HTTP请求的容量在理论上可以处理300,000 / 216 = 1,389个并发用户
嘿，那真是太好了!我们以为我们的排队率只能是100，但1389/5分钟=每分钟278个访客，所以我们可以有更高的排队率！"。
嗯，可能不是。 首先，你的访问者不会像上述计算假设的那样，整齐地以半秒的间隔发送请求。 更重要的是，你会在网站不忙的时候测量你的输入数据。 垃圾进，垃圾出。
当网站繁忙时，服务器需要更长的时间来处理请求--你会在其他网站上注意到这一点，当事情繁忙时，你等待页面的时间更长。 这增加了你的服务器处理一个HTTP请求的平均时间（4），从而降低了最大吞吐量。 因此，把每分钟278个访问者的数据减半。 然后再减半。你可能现实地看到，在最大负荷下，每分钟大约有70个新访客。
其他干扰因素包括缓存，这意味着你的访问者的浏览器可能不需要对每一个页面进行每一次请求--这往往意味着服务器需要更少的资源，可以增加你的服务器每分钟可以处理的新访问者数量。 负载平衡器将负载分布在几个服务器上，并提供静态内容而不是动态页面，也可以加快你的服务器进程，因为每个服务器需要的资源更少。
你还会发现，并不是所有的页面都需要同样的时间来完成，因为有些页面需要的资源比其他页面少，以制作和服务。 数据库搜索、搜索查询和更新需要的时间最长，所以你会在流程中的某个地方出现瓶颈，人们在那里堆积，等待处理信用卡细节和存储订单，或者等待检查可用性。 每一个交易流程都有一个最慢的步骤，所以总有一个瓶颈的地方，对于一个网络服务器可以处理多少个并发用户的问题，总有一个最大值的答案--而且可能涉及几个限制。 在这种情况下，你要把你的队列速率设置得足够低，以确保你的服务器有cpu时间能力来处理足够多的人并发你的流程中最慢的步骤，这样人们就不会堆积在那里。 否则，你的网络服务器可能真的会陷入停滞状态。
我们的经验是，在进行第一次销售时，每个人都高估了他们的服务器应对大流量的能力。
每个人都是如此。
准确地确定平均会话时间和终端用户在缓慢或高峰流量期间的性能，并不适合胆小的人。 最好的办法是进行适当的负载测试，让 "假 "客户在进行负载测试时，完全按照他们在现实生活中的情况进行订购，以相同的顺序提出相同的HTTP请求，在进行负载测试时，页面之间的等待时间与你在现实生活中看到的相同，并在你增加虚拟访问者的数量时，密切关注你的处理器负载、IO吞吐量和响应时间。 你可以使用Apache JMeter（我们也喜欢K6，用于较轻的负载或较慢的机器），但无论你使用什么工具，以完全正确的方式模仿每个用户的行为是很耗时和棘手的（特别是在缓存的复杂性方面）。 即使如此，也要把你的最大数字减半。
在没有这种情况下，要谨慎行事。
您可以随时使用 Queue-Fair 门户轻松更改任何 Queue-Fair 队列的队列速率。 从每分钟 10 位访客开始，或从正常情况下的交易率开始，在门票发售后观察一段时间，如果一切正常，处理器负载较低，SQL 数据库正常，（最重要的是）按下 CTRL-SHIFT-R 键时页面反应灵敏，则将队列率提高不超过 20%，稍等片刻，然后重复。 在这种 "负载平衡 "过程中，您很快就会找到您需要的实际速率（看到我们做了什么吗？），记住，从客户体验的角度来看，提高队列速率是没有问题的，因为这会导致队列中客户看到的预计等待时间缩短，每个人都很高兴看到响应时间提供了更短的预计等待时间。
你要避免的是把队列速率设置得太高，然后不得不降低它，因为这a）意味着使用该网站的人经历缓慢的页面加载，和b）导致估计的等待时间增加。 所有在你的队列中的人都会叹气的
记住，你会在你的订单流程的某个地方有一个瓶颈--每个交易都有一个最慢的步骤--你会得到多个会话堆积在那里。 你不想做的是，在你的票务销售中得到一分钟，看到你的服务器处理器负载远低于其最大数量，并提高速率。 你的访客可能还没有走到 "现在购买 "按钮。 你要等到你的sql数据库报告的新订单的速度与你的队列速度相同或相似时，再进行测量和响应性测试。 请记住，每次你提高速率时，额外的访问者需要相同的时间才能到达你的瓶颈，所以你将无法准确地评估你的服务器在新的速率下的表现，直到时间过去之后。
我们已经讨论过，一旦你的队列打开，最好逐渐增加队列速率。 你可能知道你的服务器确实有一个限制，不能超过这个限制，否则系统就会崩溃，甚至可能知道这个限制是什么 - 但你可能不知道的是，当负载接近这个限制时，通常没有什么迹象 - 通常只有一些错误或警告，或处理器负载超过80%。
当网络服务出现故障时，它们往往会很快 "断裂 "或瘫痪。 这通常是因为一旦你的系统不能再像它们进来时那样快速地处理请求，内部处理队列就会建立起来。然后，你的系统不得不做处理、管理和存储其内部队列以及请求的工作，这就是服务器崩溃的原因。 非常快。 一旦发生这种情况，你的服务器可能会在一段时间内用一个错误页面来回应，但这对你没有帮助，因为看到它的访问者会立即点击刷新，使负载更加复杂。
即使在此之前，如果访问者看到你的网页的时间超过一秒钟，他们就会点击刷新。 当访问者点击刷新时，网络服务器并不知道访问者已不再等待原始请求的响应。 如果同时收到原始请求和刷新请求，网络服务器将同时处理这两个请求。 这意味着网络服务器的工作量会更大，所有访问者的响应速度会更慢，点击刷新的人也会更多，从而形成恶性循环，使网络服务器在开始发送错误响应之前就已经崩溃。
因此，不要把你的服务器推得比你需要的更难。追求最后20%的cpu时间容量，通常不值得冒险。 如果Queue-Fair门户中显示的队列规模（图表中的黄色等待数字和线条）正在逐分钟减少，甚至只是缓慢增加，而且显示的等待时间是50分钟或更短，那么你处理订单的速度足够快，队列最终会自动清空并停止显示队列页面，而不需要你做任何事情，也不需要你告诉老板，你把它推得太猛，破坏了它。只要队列前面的速度高于每分钟的加入人数（两者都显示在Queue-Fair门户中），你最终会达到目的--转折点通常是在每个事件的至少几分钟后。 如果你销售的是数量有限的产品，你很可能在达到转折点之前就卖完了。
好消息是，如果你不小心把队列速率设置得太高，你的服务器就会崩溃，Queue-Fair可以帮助你迅速恢复运行--只要把队列放在 "保持 "状态，直到你的服务器准备好再次处理访客。 在 "保持 "模式下，排队者会看到一个特殊的 "保持 "页面，你可以在在线活动前设计这个页面。 当队列处于 "保持 "状态时，没有人会从队列前面通过，但新的互联网访问者仍然可以在后面加入队列，一旦堵塞被清除，就会公平地排队，这将很快发生，因为Queue-Fair正在保护您的网站免受需求影响。 保持页面是比将排队率设置得很低更优越的用户体验，特别是如果你更新它，告诉访问者你期望排队重新开放的时间，用门户页面编辑器很容易做到这一点，即使数十万人已经在排队中 - 在保持模式下，如果你需要，你甚至可以用Queue-Fair独特的接纳一个按钮让他们一次通过，同时你的系统从快照中恢复。
因此，如果你发现你的服务器在你的活动期间需要休息，"保持 "页面正是你所需要的，并将帮助你的服务器更快恢复。
在这篇文章中，我们已经解释了为什么基于速率的队列总是前进的方向，并给出了两种方法来计算你所需要的速率，但除非你已经对你的整个交易流做了全面和准确的虚拟访客负载测试，并且真的超级超级确定，否则我们的建议总是相同的。
如果你销售的是数量有限的产品，你也不需要注意步骤7。
这是对你的第一个队列而言，当时你不知道你的系统能支持的实际最大队列速率。 对于以后的队列，一旦你测量了你的系统实际能处理的队列速率，你也许可以再次使用相同的数字-- 但前提是你的系统没有任何变化。 在实践中，你的系统可能在不断开发和修改，你可能不知道最近的变化对你的最大队列速率有什么影响--所以为什么不从以前测量的数字的一半开始，重复上述过程？
因此，这就是如何使用 Queue-Fair 让您的销售变得安全可靠，请记住，安全总比遗憾好。
01.02.2021
虚拟候机室究竟是如何工作的？
排队等候的心理学（如果你是英国人，则排队）。
技术指南
如何选择一个虚拟候机室
为什么准确性对虚拟候机室很重要
虚拟候机室的在线排队系统的类型
购票网站的虚拟等候室和在线排队
