想象一下，如果在某个星期一早上，你去给你的高街商店开锁时，有人把你所有的锁都粘在一起，你会面临怎样的恐怖。如果你没有像往常一样敞开大门迎接你的顾客，而且招牌被翻成了"开放"，那么他们都会漫步而过，理所当然地感到不满，前往其他地方消费。
这几乎是过去几个月内发生在不止一个而是两个主要CDN运营商身上的事情。即使你以前从未听说过CDN运营商，他们的故障也会导致你拥有的一些最大的互联网网站瘫痪。
大型基础设施固然有用，但并不能完全解决高需求流量问题。增加更多服务器、更多云资源或更大的托管范围固然可以提高容量，但并不能自动解决需求突然到来时的核心问题。在许多情况下，问题不在于基础设施的总量，而在于流量击中关键瓶颈的速度和集中度。
这就是为什么越大并不一定越好。企业系统仍然依赖账户服务、数据库、库存逻辑、应用程序接口和支付步骤等关键路径，即使在大型架构中，这些路径也可能变得不稳定。自动扩展很有价值，但其本质上是被动的，突然的浪涌往往比额外容量的充分发挥更快。
Queue-Fair 从另一个角度解决了这个问题，它通过控制到达率而不是简单地寄希望于更大的基础设施来吸收一切。它只需一行代码即可部署，通常在五分钟左右即可上线，甚至还提供免费队列。对于企业组织来说，这往往比为了以防万一而试图扩展堆栈的每个部分更安全、更具成本效益。
大型平台仍有可能崩溃，因为峰值对系统造成的压力并不均匀。流量事件可能会将压力集中在旅程的某个狭窄部分，如登录、产品详情、座位选择、库存预订或支付协调。一旦这个瓶颈出现问题，平台的其他部分也会随之崩溃，无论整体基础设施的占用空间看起来有多大。
这也是 "只管做大 "会产生误导的原因之一。容量升级有帮助，但不能消除架构限制、第三方依赖或并发冲击。当激增突然到来时，被动扩展可能无法快速保护最脆弱的组件。这就是为什么即使是大型和复杂的企业网站，在发生重大事件时仍然会出现速度变慢、503 和完全中断的情况。
Queue-Fair 可在到达瓶颈之前平滑到达曲线，从而保护这些平台。Queue-Fair 不允许破坏性的突发撞击原点，而是以公平、先到先得的方式分配访问。由于只需一行代码就能在 5 分钟内完成添加，并可通过免费队列免费启动，因此这是一种增加弹性而无需无休止地追求更大基础设施的实用方法。
更好的解决方案通常是将合理的容量规划与积极的流量管理相结合。容量规划很重要，但最好与能够控制到达时间和流量的虚拟候机室相结合。这样，网站就能看到稳定和可预测的负载，而不是不受控制的冲击。
这种方法对于面临发布、销售、截止日期或公告等极端高峰的企业组织尤为有效。他们可以通过队列来保护网站，更有效地利用基础设施，并保持高质量的客户体验，而不是为最罕见的时刻过度建设系统的每个部分。通常情况下，这样做既省钱又安全，而不是单靠更大的主机来强行应对每一次浪涌。
Queue-Fair 正是为这一策略而设计的。它提供高度精确的流量控制、先到先得的公平性、只需一行代码就能在五分钟内快速部署，还提供免费的免费队列选项。这使它成为一种极具吸引力的替代方案，而不是昂贵且往往不完整的简单放大逻辑。
内容交付网络 是基于云的软件。 这是一种通往我们都认为理所当然的巨型网站的捷径。我们生活在这样一个社会中，客户对立即访问一切的体验是相当期待的，24/7，全速和高效，如果它消失了，那么，就会有各种各样的地狱付出。
CDN运营商为许多商业上最大的网站运营商提供服务器和本地文件托管，通过在全球各种其他地方提供更快、更有效的本地连接来支持他们的主要网站和服务器。
例如，你住在伦敦，但你喜欢跟上美国的最新新闻。 纽约时报.与其连接到他们在美国的服务器，那里已经在管理大量的美国人寻求最新的新闻和八卦，不如连接到另一个离家很近的服务器，将重要的信息缓存到本地的数据中心。这确保了《纽约时报》的访问者获得最有效和最愉快的体验，特别是在速度至关重要的地方--例如，流媒体视频文章和采访。这改善了客户的体验，当它发挥作用时。
到目前为止，这一切听起来都很理想。超级快速的连接和访问由捎带的"内容总部 "提供。但问题是这样的。因为有一小撮主要的CDN处理几乎所有最大的供应商，当他们倒下时，其他人也会这样。
这就是最近发生在一家主要CDN运营商身上的事情，与之相伴的还有亚马逊、eBay、StackOverflow、Reddit、PayPal、Shopify、Github、Twitch、 HMRC，以及你能想到的几乎所有新闻机构。
现在，他们不会永远停工；大多数为这些大企业工作的工程师会以最快的速度扭转问题，但对于相关的零售商来说，永远都不够快。
从你的网站下线的那一刻起，你就失去了客户流的收入。
卫报》 报道了由SEO机构Reboot提供的一些数据，估计亚马逊在最近一次CDN供应商中断期间可能损失了大约3200万美元的销售额。他们的研究表明，该零售巨头每秒钟的销售额远远超过6千美元，而离线近一个小时很快就会造成巨大损失。
这可是3200万美元啊!
在另一家 一个月后也发生故障的CDN 供应商，他们在博客上写道："在使用这项服务的大约500名客户中，有许多人被自动改道，在几分钟内就恢复了运营......其余大部分客户在不久后手动改道。"
然而，大银行的服务需要30分钟到几个小时才能完全恢复到正常的客户流量。
于是，CDN供应商瘫痪了，每个人的虚拟门锁都被粘在一起。这条信息 '错误503服务不可用' 闪现在数以百万计的用户眼前，让他们感到困惑和迷失方向。在不断地按下刷新按钮，直到他们的拇指上的皮肤或手机屏幕上的玻璃被磨破之后，他们很可能放弃了，去别的地方冒险。 这一点通过我们的队列管理系统得到了解决，我们监测与队列有关的数据以及你的网站有多繁忙。 这些实时指标、历史数据和服务报告也为你的商业情报获得了洞察力。
想象一下，如果你能告诉你的客户，一些恶作剧者把你所有的门锁粘在一起，而不是看着它们漂移过去（或者关于CDN运营商控制你的服务器交付的代码中的那个错误），并且一切都会在一小时内回到正轨？
甚至更好的是，你会为他们保留排队的位置；你认为有多少人还会去别的地方购物？
这就是 Queue-Fair虚拟候车室的作用。
这样的中断不应该发生--甚至相关的CDN运营商也表示，他们对这个错误没有早点被发现感到失望和惊讶，这样的错误可以从他们的网中溜走，而且它 给他们的客户带来了如此多的问题.他们发表了适当的道歉声明，并恢复了正常的业务。
可悲的是，这样的错误会时常 发生，而下一次的影响可能比最近的CDN事件要严重得多。
这不是我们任何一个做生意的人想听到的。我们想要保护。
当涉及到选择最好的赌注选项时，我们都在其中，特别是如果那是价值所在，然而有时走向最大的企业并不总是要走的路。
根据我们的经验，我们发现，正是那些规模较小的企业能够提供最个性化和最有效的服务。他们的员工了解你的业务、你的系统，所以在进行升级、管理新想法和处理你的员工时，往往更有效率。
我们没有雇用数百名员工，也不需要。像我们这样的企业，我们很想知道他们整天都在做什么，我们也会担心顾客花了钱得到了什么。所有这些额外的工资最终都会 提高在线排队SaaS 产品的价格。
我们的框架和任何人的框架一样强大。我们不使用最近发生故障的主要供应商提供的CDN，我们使用谷歌的CDN，即使谷歌的服务器遭遇这样的故障，我们也有独特的优势，可以将我们的域名重定向并排向我们的核心服务器，远离他们。 这就是如何用一个强大的队列管理系统巧妙地管理客户队列，以解决你的业务挑战和提高客户满意度。
此外，中断后对你的服务器最大的压力之一是他们重新初始化的时候--你可能没有太多的商业情报，所以要注意。他们不仅要管理重新启动系统所涉及的所有数字计算，而且还要承受巨大的额外负载，管理你的客户的备份请求。在故障发生后，有比正常情况下更多的人在等待，他们都渴望访问你的服务，而你的服务器已经承受了重新连接你的数据库和填充缓存的压力。
有了Queue-Fair等待室，所有这些压力都被消除了，您的客户在我们的虚拟等待室中安全地等待，直到他们以设计好的速度反馈到您的页面上。 我们不只是显示平均等待时间--我们显示每个特定访客的等待时间，让客户在整个客户旅程中保持知情，并提高客户满意度。
此外，我们的虚拟候机室是业内最准确的，每分钟向你的网站提供准确的人数。 因为它是如此精确，你的服务器负载更加稳定，你可以处理比其他供应商更高的流出量。 访客流量运营效率的提高意味着你减少了客户排队的等待时间，同时确保在线公平。 当每个访客的等待时间更短时，就会有更多的销售。
正是通过专业化的操作，使我们能够通过我们的队列管理系统，随时保持你的服务策略。
我们的最后一点是，那些看起来更大的企业中，有多少只是因为它们的融资方式而变得更大。
许多SaaS（软件即服务）初创公司需要注入资金来启动和运行。风险资本家带着他们的巨额资金进入。有了一大笔风险投资，这些新企业可以建立庞大的专家团队，并将他们安置在最令人印象深刻的办公场所--所有这些都是在他们赚取一分钱之前。毕竟，他们需要看起来像一个大企业，以吸引其他大企业；这就是系统的运作方式，所以这就是钱的来源。
风险投资公司投资越多，他们的回报就越好，而SaaS初创公司花的钱越多，产品就必须越贵，才能支付其偿还的费用。
有时，更大只是更大，而不是更好。
Queue-Fair仍在其原始发明人的领导下运作。100%.没有投资者，没有不必要的额外员工，也没有废话--当我们收集客户反馈时，我们一直被评为G2上最好的。我们是一个规模合理、相互支持的团队，了解客户，并随时准备提供帮助--我们通过一流的队列管理系统巧妙地处理客户队列，你也可以这样做。
20.07.2021
虚拟候机室究竟是如何工作的？
网站流量过大的风险和机遇
技术指南
如何选择一个虚拟候机室
电子商务的虚拟候机室
虚拟候机室的在线排队系统的类型
