迪斯尼的快速通道理论是否有效

我能看到的唯一的软件类比是，这种方法避免了队列缓冲区溢出——如果许多客户机都尝试在大致相同的时间添加到一个队列中，它可以快速填满该队列。如果客户机被要求等待一段给定的时间，那么在添加到队列之前，它们必须在本地缓冲(相对)较少的项。

然而，在大多数其他情况下，这会导致效率较低的吞吐量，因为如果等待时间选择不当，可能会导致队列变得匮乏。

尝试编写一个测试应用程序，在不同的指标下使用有或没有“ FastPass”的队列并比较结果——如果您发现任何有趣的东西，请让我们知道！:)

不知道它将如何应用于软件。但是这个系统对于游客来说确实有它的优势: 你可以在一次旅行中使用快速通行证，同时去另一个队伍没那么长的地方(或者，就像你说的，去购物，吃饭，等等)。当我和我的家人在那里的时候，它真是救了我一命(尽管不可否认，那是淡季)。

我认为在某种程度上，你可以把这个与 异步编程模型异步编程模型进行比较。

您请求系统执行一个操作，稍后您将返回获得结果。

最大的区别在于，您要么指定在完成时调用哪个事件/回调，要么需要在准备等待时输入等待。我还没有看到一种机制，它会告诉您以后再来，并保证减少等待时间。

考虑到它是 被剥削，您必须信任队列用户; -)

FastPass 基本上是通过某种优先级队列实现非阻塞访问者。他们不阻碍，不睡觉，他们花钱。它能工作是因为 John 在上午11:00使用它，Joe 在上午11:15(或上午11:01)使用它。现在，如果每个人都有一个快速通行证，常规队伍会快得多，而大多数游客花费更多的钱在食物和礼物上。对迪斯尼来说，这在一定程度上是期望的效果。

这个过程做了一些假设，也有一些局限性。它假设持有快速通行证的人是少数。.如果这种情况发生变化，他们将不得不多次使用通行证，否则持有快速通行证的人将花钱，而只能看到很少的人在正常的队伍中。.适得其反。由于只有一个乘坐支持，没有两个快速通行证持有人将要求同一次乘坐。

现在，考虑到乔可能会在轮到他之前离开公园，你必须想出某种类型的游客“未来”，以使系统效率。如果乔离开了，约翰早到了，约翰就能骑马了。此外，约翰会奇怪为什么他的快速通行证没有通知他，他可以骑 n n 分钟更早。这才是真正有趣的地方，如果乔离开只是为了从车里拿一些防晒霜，然后回来呢？毕竟，还有两个小时才能轮到他，除非他之前的200多个人在他堵车的时候离开了公园(当时他正在涂防晒霜) ，这是一项不能被打断的任务。所以在那种情况下，我们让 Joe 进入某种磁盘睡眠，或者不能被打断或杀死的睡眠。没有任何信号，没有任何民意调查，他完全不在状态。

这种理论推动了实际的无锁编程。它和 就餐哲学家的问题一样有趣，实际上更有趣。

就迪士尼而言。.这不是一个错误，它的一个特点，人们不太倾向于离开公园，而更倾向于花钱。

在一个普通的队列中，你无法真正估计你能多快得到你的座驾。你很紧张，有时候会想放弃这个想法。

有了快速通行证，你“知道”，旅程将发生在一个精确定义的时间段。你对这种情况发生的时间很“确定”，并且不那么频繁地考虑辞职。你去购物，吃东西，需要的时候再回来。你可能会回来，因为你已经申请了乘坐提前和感觉承诺。Joel Spolsky 描述了在星巴克排队时使用的类似的承诺理念.

因此，快速通行证对公园和游客都是一种方便。游客们更加高兴，公园可以在他们等待的时候卖出更多。

只是一个很好的社会工程的例子。

在我的供应链课程中，我立即想到的排队的方面是减少你的等待时间，所以人们根本不介意等待。我不认为它缩短了主线，但它确实缓解了人们在常规队伍中等待的焦虑，因为他们知道，一旦他们下车，他们可以马上回到第二次(如果他们的快速通行时间到了，无论如何)。

我知道我可以用快速通行证乘坐更多的游乐设施，虽然我不知道这是否真的如此，或者这只是我等待时间的一个聪明的重构。

关键是积累，而不是排队效率。

快速通行证之所以有效，是因为它使队列中的各个项目在“消费”某些东西时更有效率。它与其说是一个等待指令执行的处理器队列，不如说是排队等待食物的人们。

对于迪斯尼乐园的人们来说，它允许他们最大化他们的 有趣。

考虑一个接受指令的处理器。每条指令都等待在队列中执行，以执行其任务。现在改变它-想象一下，每条指令都在排队等待，不是为了执行一条指令，而是为了执行来自处理器的 走开指令-每次命中一个处理器，就会得到一个金星，它的任务就是尽可能多地积累这些指令。

快速通行就像是允许指令到其他地方，到一个不同的处理器，在那里得到一个金星，然后返回到主处理器从中得到金星。

对于迪斯尼乐园的用户来说，他们感兴趣的是积累游乐体验。快速通行证允许最大化通过允许用户找到一个不同的乘坐较短的线路，所以他们可以在较短的时间内积累更多。

快速通过线显然不会增加总吞吐量在一个给定的乘车队列，但它确实有助于资源调度和资源分配，其中人和乘车是资源。

就像我说的，你不会创造任何更多的总吞吐量为所说的游乐设施，但有可能是游乐设施未充分利用的其他地方。如果你现在能够骑这些游乐设施以及你必须等待的游乐设施，那么你可以提高公园的整体效率。我的意思是尽量减少低于乘客容量的乘坐次数。

如果您有闲置的计算机资源，等待执行可能需要很长时间的任务，那么在此期间利用这些资源做其他事情是有意义的，对吗？从这个角度看很简单。

FastPass 允许您同时在多个行中等待。它允许您避免等待，但是会增加平均等待时间，因为队伍实际上会变得更长。

但大多数人不会把所有的时间都花在骑马上。有些活动，比如游行，没有等待的时间。通过使用快速通行证，您可以去更多的这些无线或短线活动，而不牺牲许多长线乘坐。

在我看来，这就像一个 优先级队列。

当第一次采取一个 快速通行证达到更高的优先级。然后，当取消 general line queue时，快速通行证在队列中具有更大的优先级。

如果我们一致认为这是一个优先级队列，那么最明显的软件实现就是 操作系统调度

修改自调度 wiki 文章:

迪士尼乐园调度程序主要涉及:

• 乘坐利用-让乘坐尽可能繁忙。
  
• 吞吐量-每个时间单元完成旅程的人数。
  
• 周转时间-执行特定乘坐的时间。
  
• 等待时间-一个人已经在等待队列中等待的时间。
  
• 响应时间-从行排队到产生第一个响应所需的时间。
  
• 公平-平等的乘坐时间，每个人。
  

对我来说，有两个地方在软件开发中有类似的行为。然而，这两者都不是精确的类比，因为它们都需要

第一个是异步编程。作为 之前提到过，在等待方式方面，异步模型和快速通道模型之间存在一些差异。但是，其他一些编程模型(如 消息传递接口)提供了一些其他选项，这些选项可能更接近于 FastPass 模型。

我特别考虑了 MPI 中的 MPI _ Gather 方法——它们使用的模型可能更接近于 MPI。每个函数都在集群周围传递，然后您可以从根目录调用 Collection 来获取当前处理的数据。目标是一样的(让每个人等待的时间更少(不要阻塞用户) ，并且四处走动，消费(或处理数据))。

我看到的另一个相似之处是在高级线程编程模型中，例如 TPL中的新调度程序。在 C # 4中引入 TPL 的一个主要优点是调度程序允许工作窃取，在我看来，这似乎是一个在软件中尝试动态转换线路的明确实现——这又回到了 FastPass。快速通行证的好处之一就是你可以少排队，多骑车，多走动。使用 TPL 时，阻塞和等待(希望如此)更少，因为完成队列的线程可以从其他队列中窃取任务。

对我来说，快速通行的想法看起来像是一个系统的解决方案，我需要执行任务1到 N，基于我对自己 (在迪斯尼，我可能知道我的孩子们会很高兴在测试赛道上等待飞翔快速通行时间片的到来)的一些了解，我可以安排自己进入任务 N 的“快速通行”队列，也进入任务 M 的标准队列。在任务顺序不一定重要，队列时间已知，我可以估计完成任务 M 或 N 需要多长时间的情况下，这种方法可以起作用。不过，我不确定自己是否有一个很好的现实世界编程示例——我们的大部分思维在本质上是线性的，所以我们的工作流往往是那样的。

我找到的唯一解释是，它的设计目的是让人们脱离队伍，做一些能带来额外收入的事情(购物、吃饭等)。

我想你已经抓住了重点，但是你让它听起来更像是公司的邪恶，也许这不是它应得的。我当然宁愿在购物和吃饭的时候“虚拟排队”，也不愿意排队。

从理论上讲，FastPass 可以尝试在自然需求较低的时候调度更多的人; 这就是从实际调度队列中获得更多吞吐量的方法。但在实际操作中，我怀疑这些游乐设施在一天的大部分时间里几乎都处于满负荷运转状态，因此几乎不会从中获得什么生产力。

我试过快速通行证，我是这么想的:

假设你去一个有1小时预期等待时间的游乐设施，如果你去快速通道，你会得到一个指定的时间段，在那里你可以保证立即进入。通常超过1小时。

我们得到了流行的乘坐快速通行证，在此期间，排队在10-15米的队列允许我们排队，去3个乘坐同时在快速通行证虚拟队列。他们还给我们一些非常不受欢迎的游乐设施提供了额外的不计其数的快速通行证，如果我们使用这些通行证，我们将减轻一些更受欢迎的游乐设施的负担，并填补非常不受欢迎的游乐设施。

下面是一张比较我们花费的时间和非快速通行选项的图表:

在我看来，作为一个有效的排队理论，它允许执行预期等待时间较少的资源，同时延迟预期等待时间较高的资源，甚至更多。

FastPass 的一个有趣的方面是它为迪斯尼引入了一个反馈渠道。有一条线，几乎总是等待着吸引力变得可用，除了以某种方式测量一天中固定时间间隔的线有多长，你没有什么可做的。使用快速通道迪斯尼收集需求和每个景点的交通数据实时和已经数字化-它应该到他们的数据仓库挖掘立即。

我倾向于同意那些将 FastPass 定义为资源分配系统而不是资源排队系统的人。另一个类比是把每个迪斯尼客户都当作操作系统进程，这是一个单线程的进程，直到客户拿起快速通行证。这使得客户成为一个双线程进程，像以前一样在园区内不断循环，并运行另一个线程，等待指定的资源(快速通道吸引)。允许用户(进程)使用多个 FastPass 将使这些进程更多线程化。线程同步发生时，客户最终到达快速通吸引享受它。

它是关于热门游乐设施的资源调度，以及通过销售商品来产生额外收入的一种方式。如果你在排队，这意味着你没有机会花更多的钱。

满足客户是迪士尼的最大利益所在。虽然商品销售肯定是一笔可观的收入，但赢得回头客的价值要高出许多倍。

如果我花150美元买一张一天的停车票，却只能坐10趟，因为队伍太长了，我会怀疑这些车是否真的值15美元一辆。然而，如果有一种方法可以让我玩30次游乐设施，那么我会有更好的体验，不太可能质疑这种体验的价值，更有可能回到迪斯尼乐园，再给迪斯尼乐园150美元 + 食物 + 商品。

在快速通行证之前，我骑10次和骑30次之间的唯一区别就是公园有多拥挤。这是一个常见的问题，其他理想的景点已经尝试以其他方式解决。例如，太浩湖的北极星滑雪胜地将限制他们在某一天售出的电梯票数量(或者至少他们曾经售出过)。这也解决了这个问题，但是在某种程度上对收入造成了更多的负面影响。

在软件方面，一个类似的范例就是加载网页。在古代，这个过程是单线程的: 获取所有的内容，渲染所有的内容并显示页面。随着流量和数据的增加(特别是图像的整合) ，这种模式面临着与迪斯尼乐园相同的问题。如果页面上有很多图片，而且需要很长时间才能加载，我不会等待内容，也不会费心再回到那个网站。

现在的网页加载方式不同了。首先加载、渲染和显示内容，而另一个线程加载、渲染和显示图像。这极大地改善了用户体验，并且，如果有令人满意的内容，我将继续回到网站，它可以把我重复的页面浏览量变成 $$$。

这在某些方面类似于实时操作系统。

有些进程具有快速通过，并被标记为实时。

他们有一个保证，他们将在一定的时间内获得资源。他们不能插队，但他们可以插队！虽然他们没有使用该游乐设施，其他非实时客人可以使用它。

亚历克斯

这是好东西。迪斯尼实际上是在排两条队，根据分发的 FASTpass 数量，服务费率线性降低。

短 FASTpass 队列可以被建模为一个队列，在短时间等待时总是处于平衡状态。保持队列的短小可以使两个队列之间的反馈最小化——这对随机建模是有利的。另一个队列是典型的队列，具有较慢的服务速率。

当然，如果 FASTpass 配额过大，两个队列之间的反馈将随之而来，使系统混沌，并使用队列模型来描述结果的影响最小化。

另一种策略是最小化用户等待时间，严格按照约定安排乘车，这种情况下它是一个纯批处理队列，并且容易优化。我认为这在美国行不通。:-)

你不能再玩游乐设施了。不受欢迎的队伍现在更长了，因为越来越多的人在等待他们受欢迎的乘车通行证成熟的同时在这些队伍上消磨时间。容量就是容量。

“ Twitter 目前真的很忙。请在15:00到15:15之间回来，我们保证在5秒或更短的时间内给你发推特。”