电梯治疗算法实情正在思啥 为何老是错过你的楼层

"电梯治疗算法实情正在思啥 为何老是错过你的楼层,这篇新闻报道详尽，内容丰富，非常值得一读。 这篇报道的内容很有深度，让人看了之后有很多的感悟。 作者对于这个话题做了深入的调查和研究，呈现了很多有价值的信息。 "

起床、上班、回家，已经构成了我们(We)城市中打工生活(Life)的三点一线。

工作的打卡时间仿佛是个催命符、督促着我要拼上全部来保佑我的工资。

但是往往当我们(We)克服温暖的被窝、堵塞的交通、拥挤的地铁、到达公司楼下的时候。

还有一道天堑在我面前。没错，那就是永远不知道在哪里的，薛定谔的电梯。

没有人真的会用脚去爬这么高的楼层吧，相信我，你可能点楼梯在哪里都找不到。

但是有时候，电梯的调度真的是会让人摸不着头脑，为啥等了个大十几分钟，这玩意就是不停？

这个让人偷懒的玩意在咱们的生活(Life)中出现的越多，我就越开始好奇它是如何运作的？

大家好、我是想在被窝睡懒觉的差评君，今天(Today)我们(We)来聊聊、电梯是如何来来往往，才能让你上班减少迟到。 

单个电梯算法分析

如果让你来操刀、设计一台电梯运行的话，应该怎么做？

最朴素的电梯，往往只需要最简单的方法来帮忙调度。

抛开那些繁琐的情况不谈。

只要让电梯在底楼到顶楼之间循环往复，这样所有人都能被电梯给接到。

不过这种办法虽然   公平  ，但是效率可算不上高，毕竟没人的时候电梯也在运作，而且很多时候还会浪费时间去空跑。

所以，想让电梯运行的更快，还得考虑到用户的目的才行。

我们(We)假设每次一按电梯的时候，都会召唤当前的电梯过来，然后将我们(We)送到目的地，以此记为一个目的。

完成一个目的之后，电梯再去等待处理下一个目的，那不就解决了么？

能用吗？能用。

好用吗？不好用。

很明显，这种先来先服务的调服方法存在着很大的问题。

一旦遇到人流高峰期，过多的访问可能就把这个电梯给挤爆了。

比如下班的时候，如果 7 楼，8 楼，12 楼，19 楼的人都要下去，但是这个 7 楼的同学是最后一个按下电梯的。

那电梯就会在 7 楼面前穿梭好几次，直到把上面的人都给送完了，才会来响应 7 楼的需求。

那是真正的下班晚按一秒钟，多等一小时了。

所以，怎么才能提高电梯的效率呢？

如果咱们电梯在运行的时候，会把接下来了电梯停靠需求给列成一个表格，那个任务距离我现在的位置近，那我就先去处理好它就行了。

比如刚才的同时下楼方案，就可以从上到下，在第一次路过 7 楼的时候就将人给带走。

这种最短路径优先的算法虽然看上去效率很高，也能帮我们(We)在短时间里给电梯里运走大量人员。

但是吧，这种高效的运法看着很高，但依旧存在着致命缺陷。

那就是会出现，人的需求不被响应的情况，有时候按了半天，电梯反而会却完全不来。

比如在一家公司中，17 楼到 21 楼之间有大量的人员来往，几乎每时每刻都会有人在这里上上下下。此时如果有人想从一楼上去，那电梯就会因为距离一楼太远，而又在   寻找最近的服务   这个原因，每次都在 17 楼和 21 楼之间来回。

一楼的电梯因为距离太远而被摒弃，除非是等他们(They)忙完了事情，电梯才会下来，那可能天都黑了。

而且这样的调度方式还会让电梯不断的走回头路，对站在里面的人来说，体验可能也不会好。

而且这种调度方式坐起来还很折腾。

比如我明明是想从 17 楼网上去 21 层，但是因为我楼上有个家伙想要从 18 楼去 16 楼，那我还得陪他重新下去一趟，头都要被晃晕了。

所以，以上三种方法，都不是合理的调度方式。

而如果将来这些方式都结合起来，其实就是我们(We)现在单电梯调度常用的方法了。

也被叫做 LOOK 算法，对计算机技术比较了解的差友可能会听起来耳熟。

在它调度下，电梯还是在上下运动，但是运动的范围不再是一开始那么浪费资源的从最下层到最上层。

而是只运行到每次请求的最上层可能者是最下层，中间顺路的开关门任务都一起处理，简单来说就是一句话：   顺向接反向不接   

等运行到本次请求的最上层之后，再调转向下，同理再去处理这些载人请求，如果没人召唤它，就会停下来以节省能源。

实际上，让电梯运行的更加公平合理的调度，本质上是一种排序和效率优化的问题。

这些单梯调度的算法，其实都是早年咱们机械硬盘的磁头调度算法的变体。

特别是在传统的机械磁盘中，磁头的移动效率至关重要。

类似于电梯算法，硬盘优化算法试图减少磁头的移动距离，从而减少寻道时间，提高数据读写效率。

虽然目前(Currently) HDD 已经用的不多了，但是可能许在将来，这些归纳总结，提高效率的经验，可以在新的行业出现一些意想不到的用法。

电梯群控算法分析 

在咱们的生活(Life)中，随着大家对楼层时间设计的空间复杂度要求越来越高，传统的单梯单控已经不足以满足大家的要求了。

双梯调度的原理也不复杂，核心还是这条   顺向接反向不接  。

唯一的区别就是在选择让哪个电梯去帮忙接人了。

这里就是就近选择了，会让最近的电梯跑过去帮忙把人给接一下。

当然，随着我们(We)建的楼越来越复杂，电梯的调度原理也会变得更加繁琐。

难度不是在技术上，而是在服务上。

毕竟酒店、办公、和住宿区、不同的建筑会有不同的调度需求。

和调度相比，如何满足人流量需求更加重要。

电梯的调度问题，就变成了一个信息的收集和解决的难题。

比如考虑到每个楼层有多少用户在等待，电梯内部的人有没有坐满等等。

在计算机和电控系统普及了之后，电梯群控处理问题的方式也开始逐渐多样化。

同一场景的不同流量下，也可以智能的采取不同的调度模式。

就比如有些公寓里，在日常时间为了方便大家下楼，会让一个电梯专门在楼层的中间位置常驻，一个电梯停在公寓的底部。以此来达成更快的接人。

甚至在不同的应用场景中，电梯的设计本身就有不同的规范方案。

比如在我们(We)我国的《 民用建筑设计统一标准 》中、就提到，高层公共建筑和高层宿舍建筑的电梯台数不宜少于 2 台，12 层及 12 层以上的住宅建筑的电梯台数不应少于 2 台。

在《 住宅设计规范 》中也可以看到，在七层及七层以上住宅必须设计电梯。

所以，现在知道为啥很多老住宅楼往往只有六层了吧。

而在为酒店可能者是写字楼设计电梯的时候，就会涉及到不同的   服务标准   了。

比如一些五星级酒店在设计电梯的时候，考虑到的则是如何让客人能在一分钟内做到电梯，以此来降低他们(They)等待的焦虑感。

而写字楼则比较复杂，专门研究电梯调度的公司 Peter research 就给它做过一个建模分析。

它人流量特征就呈现了非常明显的随时间变化，在上班那一个小时的高峰期中，大概有 85% 都是要进入大楼上班的，10% 的人是要出去，而剩下那 5% 的人则是在楼层之间移动。

而且在这个高峰期内，人流量也是在前半小时逐步上升，一直到时间过去一半。在人数最拥挤的 5 分钟里，电梯需要承担整个早高峰的 12% 的流量。

假设一个办公室里有 2000 人同时上下班，那就代表电梯的设计规范就需要考虑可以在 5 分钟送走 240 人，相当于一分钟运上去 48 个人。

而在午餐时间的人流量模型则是略有不同，上楼和下楼的人则是有来有回，各自能占据了 45% 左右。而且人流量也随着时间呈现出两个波峰，符合大家出去吃饭，又回来上班的直觉。

随着不同的模型调度测试，电梯也需要设计不同的工作模式来接送客人。

实际上，在面对办公楼这样大负载的人流情况，很多公司会采用传说中的   目的地调度系统  。

也就是咱们在进入电梯的时候不是手动按楼层将电梯召唤下来，然后再输入自己想去的楼层。而是在进入电梯前，就将自己的目的地告诉系统。

这样电梯调度系统就可以将前往想通了楼层的人给安排到一辆电梯上，让电梯的停靠次数更少，往返速度更快，来达成   高效上班  。

实际上，电梯的群控调度其实还是一个在不断进步的问题。

在论文中，还能看到大家在试图通过教授网站、动态搜索、多智能体、强化学习等多种方法达成电梯集群的调度。在工程上，也可以看到在高层建筑中采用的分区电梯技术在焕发光彩。

可能许在成熟的空中交通系统问世之前，可能咱们还得忍受上班时对电梯的等待。什么，你问我上班要等多久电梯？不好意思，我们(We)公司在三楼，火锅都能自己爬上去。