迪士尼的FastPass是否有效和/或有用的排队论

在迪士尼世界，他们使用称为Fastpass的系统为热门游乐设施创建第二条较短的路线。这个想法是，您可以在标准行中等待，通常需要等待一个小时以上，或者您可以获取FastPass，它允许您在指定的时间段（通常是几个小时后）返回，仅等待10分钟以内。使用FastPass一次只能“等待”一次乘车。

我一直在试图弄清这个概念背后的排队理论，但是我发现的唯一解释是，它旨在使人们脱颖而出并做一些可以带来额外收入（购物，饮食等）的事情。

这是为什么要实施FastPass，还是要解决一个真正的访客效率问题？是否有应用了类似逻辑的软件应用程序？是否有应采用类似逻辑的软件应用程序？

我看到在软件中实现类似功能的部分问题是它基于用户选择队列。为了使软件中的等待周期更快，我认为，如果要很好地应用此理论，就需要应用程序足够聪明，才能根据需要将人们放置在哪些队列中，而无需最终用户选择。

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

就像我说的那样，您不会为上述乘车创建更多的总吞吐量，但是在其他地方可能未充分利用乘车。如果您现在能够骑行这些游乐设施以及必须等待的游乐设施，则可以提高公园的整体效率。我的意思是最大程度地减少在载客量以下行驶的乘车量。

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

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

快速通过之所以起作用，是因为它使队列中的各个项目在“消费”某些物品时效率更高。它不是排队等待指令执行的处理器，而是排队等待食物的人。

对于迪士尼乐园的人们来说，这使他们能够最大程度地享受乐趣。

考虑一个处理器接受指令。每个指令都在等待在队列中执行，以执行其任务。现在改变它-想象每一个指令排队等候不执行一条指令，但要得到从处理器中某些东西-每次击中处理器时，它都会获得金星奖，其工作就是积累许多尽可能。

Fastpass就像允许指令转到其他处理器，以在那里获得金星，然后返回主处理器以从中获取金星。

对于迪斯尼乐园的用户来说，他们有兴趣玩得开心-积累了乘车体验。快速通行证允许用户以较短的路线找到其他乘车路线，从而实现最大化，从而使他们可以在更短的时间内积累更多的东西。

我尝试过FastPass，这是我的看法：

假设您的骑车等待时间为1小时，如果您使用FastPass，则会获得一个指定的时间段，可以保证立即进入。通常是在超过1小时之后。

我们为热门游乐设施提供了FastPasses，在此期间，我们排成10-15m的队列，使我们可以在FastPass虚拟队列中排队并进入3个游乐设施。他们还为一些非常不受欢迎的游乐设施提供了额外的不可计数的FastPass，如果我们使用这些通行证，我们将减轻一些较受欢迎的游乐设施的负担，并填补非常不受欢迎的游乐设施。

这是一个图表，比较了我们花费的时间与非快速通过选项：

在我看来，这是一种有效的排队论，它允许执行等待时间较短的资源，而延迟的等待时间更长。

FastPass基本上实现了具有某种优先级队列的非阻塞访问者。他们不阻塞，不睡觉，花钱。之所以有效，是因为John在11:00 AM使用了它，joe在11:15 AM（或11:01 am）使用了它。现在，如果每个人都通过了快速通行证，那么常规线路会更快，而大多数游客在食品和礼物上花费的钱更多。对于迪士尼来说，这在某种程度上是理想的效果。

通行证有一些假设，也有一些限制。它假定快速通行证持有人是少数..如果这种情况发生了变化，他们将不得不使通行证适用于多次乘车，否则快速通行证持有人会花钱，而在常规路线上看到很少的人会适得其反。由于仅支持一次乘车，因此没有两个快速通行证持有人会立即要求同一次乘车。

现在，考虑到Joe可能在转弯之前就离开了公园，您将不得不提出某种访客“ futex”以使系统高效。如果乔走了，而约翰早到了，约翰就可以骑了。而且，约翰想知道为什么他的快速通行证没有通知他他可以提前nn分钟骑行。那真的是很有趣的地方，如果乔离开只是为了从汽车上取些防晒霜然后返回，该怎么办？毕竟，他的转弯距离只有两个小时，除非他挡车（获得防晒霜）时有200多人离开公园，否则这个任务是无法中断的。因此，在那种情况下，我们将Joe置于某种磁盘睡眠状态，即无法中断或杀死的睡眠状态。他没有信号，他没有在轮询任何东西，他不在公园里。

这是驱动实际无锁编程的理论。它与餐饮哲学家问题一样有趣，实际上更多。

就迪士尼而言，这不是一个错误，而是它的一个功能，人们较少倾向于离开公园，而更倾向于花钱。

在普通的队列中，您无法真正估算出乘坐的速度。您很紧张，有时会考虑放弃这个想法。

使用FastPass，您“知道”乘车将在精确定义的时间段内发生。您可以“确定”何时发生这种情况，并考虑减少退出的频率。您去购物和吃饭，需要时返回。您可能已经返回，因为您已经提前申请了乘车服务并感到了承诺。乔尔·斯波斯基（ Joel Spolsky）描述了星巴克排队使用的类似承诺理念。

因此，FastPass为公园和游客提供了一种便利。参观者更加高兴，公园可以在等待时出售更多。

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

我认为您可以将其与异步编程模型进行比较。

您要求系统执行操作，稍后再返回结果。

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

对我来说，这似乎是一个优先队列。

初次使用SpeedPass时，会获得更高的优先级。然后突然离开时general line queue的SpeedPass在队列更优先。

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

从调度维基文章修改：

在迪斯尼乐园调度主要关注的是：

• 乘车利用率-使乘车尽可能繁忙。
  
• 吞吐量-每个时间单位完成乘车的人数。
  
• 周转时间-执行特定行程的时间。
  
• 等待时间-一个人在就绪队列中等待的时间。
  
• 响应时间-从排队排队到产生第一个响应所花费的时间。
  
• 公平-每个人的乘车时间均等。
  

对于我来说，FastPass的想法看起来像是一种系统的解决方案，该系统需要执行任务1到N，并基于我对自己的一些了解（在迪斯尼，我可能知道我的孩子在等待测试轨道时会非常高兴。快速的到达FastPass时间片）我可以安排自己进入任务N的“ FastPass”队列，也可以进入任务M的标准队列。这在任务顺序不一定很重要以及队列时间很长的地方就可以使用是已知的，我可以估计完成任务M或N所需的时间。虽然不确定我是否有一个好的实际编程示例-我们的大部分思维本质上都是线性的，所以我们的工作流程往往是这样。

FastPass允许您同时在多行中等待。它使您可以避免等待，但是会增加平均等待时间，因为有效地延长了行数。

但是大多数人并没有花费全部时间去骑车。某些活动（例如游行）并没有真正的等待时间。通过使用快速通行证，您可以参加更多的无线或短线赛事，而无需牺牲许多长线游乐设施。

在我看来，有两个地方在软件开发中具有相似的行为。但是，两者都不是精确的类比，因为它们都需要

首先是异步编程。正如前面提到的，有异步模型和快速通过模型之间的一些差异，你如何等方面。但是，其他一些编程模型（例如消息传递接口）为您提供了其他一些选择，这些选择可能与FastPass模型更加接近。

特别是，我在考虑MPI中的MPI_Gather方法-它们使用的模型可能更接近一点。每个函数都在群集中传递，然后您可以从根调用收集，以获取当前处理的数据。目标是相同的（让每个人等待的时间更少（不会阻塞用户）并四处走动，花费（或处理数据））。

我可以看到的另一个地方是高级线程编程模型，例如TPL中的新调度程序。C＃4中提供的TPL的主要优点之一是，调度程序将允许窃取工作，在我看来，这似乎是一种软件的清晰实现，它试图动态地在线路之间移动-这与FastPass息息相关。fastpass的优点之一是，您坐得更少，骑得更多，走动更多。使用TPL，（希望）减少了阻塞和等待，因为完成队列的线程可以从其他队列中窃取任务。

FastPass的一个有趣方面是它引入了迪士尼的反馈渠道。拥有一条几乎总是等待吸引游客的单条线路，您除了可以以某种方式测量一天中固定时间间隔的线路长度外，您无能为力。迪士尼使用FastPass实时收集每个景点的需求和交通数据，并且已经将其数字化-它应该立即进入其数据仓库进行挖掘。

我倾向于同意那些将FastPass视为资源分配系统而不是资源排队系统的人。另一个比喻是将每位迪士尼客户视为OS进程，该进程是单线程的，直到客户选择FastPass。这使客户成为一个2线程进程，该进程像以前一样一直在整个公园中循环，并正在运行另一个线程，该线程等待轮换指定资源（FastPass吸引力）。允许对用户（进程）进行多次快速通过将使此类进程更加多线程。当客户最终获得FastPass吸引力时，就会进行线程同步。

我能看到的唯一软件类比是，这种方法避免了队列缓冲区溢出-如果许多客户端都在几乎同时尝试添加到队列中，则它可能会迅速填充该队列。如果要求客户端等待给定的时间长度，则必须在添加到队列之前在本地缓冲（相对）较少的项。

但是，在大多数其他情况下，这会导致吞吐量降低，因为如果选择的等待时间不佳，则可能导致队列饿死。

尝试编写一个测试应用程序，该应用程序在各种指标下使用带有“ FastPass”和不带有“ FastPass”的队列，并比较结果-如果您发现任何有趣的事情，请告诉我们！:)

不知道如何将其应用在软件中。但是该系统肯定对游客具有优势：您可以拥有一次乘车的快速通行证，同时前往排队时间不长的另一次乘车（或者，如您所说的去购物，吃饭等）。当我和我的家人在那里时，这真是救命稻草（尽管可以承认，那是淡季）。

鉴于已被利用，您必须信任队列用户;-)

在我的供应链课程中，立即出现的排队问题是减少了您的等待时间，因此人们根本不介意等待。我不认为这会缩短主线，但确实可以缓解某些人在常规路线上等待的忧虑，因为他们知道，一旦下车，他们就可以第二次回来（如果他们的快速通行证时间到了，无论如何）。

我知道，我可以通过快速通行证骑乘更多的车，尽管我不知道这是否是实际情况，还是只是巧妙地重新设定了我的等待时间。

我发现的唯一解释是，它旨在使人们脱颖而出，并做一些可以带来额外收入（购物，饮食等）的事情。

我认为您已经达到了要点，但听起来却使公司听起来比应有的邪恶。我当然宁愿购物和吃饭时“虚拟排队”，也不愿排队。

从理论上讲，FastPass可以在自然需求较低时尝试安排更多的人员。这就是您要从真正的预定队列中获得更多吞吐量的方法。但实际上，我怀疑这些游乐设施在一天中的大部分时间里都处于满负荷运转状态，因此从中获得的生产力很小。

它涉及用于热门游乐设施的资源调度，以及通过出售商品产生额外收入的方式。如果您在排队等候，则意味着您没有机会花更多的钱。

满足客户的要求符合迪士尼的最大利益。销售固然是一笔可观的收入，但获得回头客的价值却要高很多倍。

如果我花150美元买了1天的公园漏斗票，但由于排队时间太长，只能坐10趟车，我会质疑这些游乐设施是否真的值每张15美元。但是，如果我可以骑30次车，那么我会有更好的体验，不太可能质疑这种体验的价值，而更有可能返回并给迪士尼乐园另外150美元+食物+商品。

在使用FastPass之前，我的10骑和30骑之间的唯一区别是公园有多拥挤。这是其他期望的吸引力试图以其他方式解决的普遍问题。例如，塔霍（Tahoe）的Northstar滑雪胜地将限制他们在特定日期（或至少以前）出售的缆车票的数量。这也解决了该问题，但以某种方式对收入产生了负面影响。

在软件中，类似的范例将是加载网页。在古代，此过程是单线程的：获取所有内容，呈现所有内容并显示页面。随着流量和数据的增加（特别是图像的合并），该模型面临与迪士尼乐园相同的问题。如果页面上有很多图像并且加载时间很长，那么我就不会等待内容，也不会再来该网站了。

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

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

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

他们保证他们将在一定时间内获得资源。他们不会插队，但可以推进！当他们不使用游乐设施时，其他非实时访客也可以使用它。

-亚历克斯

这是很棒的东西。迪士尼实际上是制作两个队列，根据FASTpass分发的数量，其服务率呈线性降低。

短的FASTpass队列可以建模为在短暂的等待中始终处于平衡状态的队列。保持较短的队列可以最大程度地减少两个队列之间的反馈-这对于随机建模非常有用。另一个队列是典型队列，服务速率较低。

当然，如果FASTpass配额过大，则会在两个队列之间产生费用返还，使系统混乱，并使排队模型描述结果的影响最小化。

另一个策略是最大程度地减少用户等待时间，严格按照预约安排行程，在这种情况下，这是一个纯批处理队列，并且易于优化。我认为这在美国不行。:-)

您不会坐更多的车。现在，不受欢迎的台词的台词更长了，因为越来越多的人在等待流行的通行证成熟时正在浪费时间。容量就是容量。

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