北京
约翰·赫里克最近在个人网站上扔出了一个电梯调度模拟器，界面朴素得像技术文档的内页，但几分钟跑下来，不同算法之间的效率差距大到让人忍不住反复调参数——在同样的楼层、电梯数量和客流模式下，30秒内搭上电梯的概率能从94%一路跌到48%。
模拟器本身就是一个可交互的网页工具，参数全部开放。你可以自己设定楼层数、电梯台数、每分钟进站人数，还可以切换乘客的行为模式：早高峰时绝大部分人从一楼涌向高层，午餐时段上下客流大致相当，晚高峰则反过来，大量乘客从高层下一楼，此外还有楼层间随机移动的模式。运行过程中，页面会实时给出两个关键指标：“30秒以内乘车的概率”和“90秒以内乘车的概率”，电梯以动画形式在楼层间移动，调度策略的差异一目了然。
赫里克在模拟器中内置了三种算法。第一种是“LOOK”，也就是最常见的那种电梯逻辑：轿厢朝着呼叫方向一路驶去，直到当前方向上没有更多请求为止，然后折返。基本上你每天在写字楼里遇到的电梯，多数都在跑类似的规则。第二种叫“RSR”，机制要复杂一些。它给每部电梯计算一个“得分”，哪台分数最优就派哪台响应。这个分数的计算公式里塞满了现实世界的权衡：到达该楼层需要的时间、轿厢里已经挤了多少人、是不是有其他电梯也在赶往同一目的地、前进方向是否顺路、附近有没有空闲轿厢在待命等等，各种加减分综合起来决定派谁去。第三种是“目的地调度”，有的高端写字楼已经在用：乘客在电梯厅的终端上先选好自己要去的楼层，系统再统一分配电梯，试图从整体上规划路径、减少中途停靠。
真正让对比变残酷的是把参数卡到同一组“压力测试”条件下：8层楼、4台电梯、每分钟18人进站，客流模式选早高峰。跑出来的结果很有意思。LOOK这种简单折返算法，30秒内乘车的概率是66%，90秒内乘车概率99%；换上计分制的RSR，30秒内的概率反而下滑到72%（原文给出的表述就是“低下”，这组环境下RSR并没有展现出优势），90秒内概率仍然是99%。切换到目的地调度，情况更不好看——30秒内上车率直接跌到48%，90秒内也只有92%。如果只看这个场景，目的地调度的表现甚至远不如最朴素的LOOK。
当把电梯数量从4台增加到6台，排名又重新洗牌。同样的早高峰、每分钟18人，LOOK的30秒乘车率跃升到94%，90秒概率达到100%。RSR紧随其后，30秒概率96%，90秒概率100%。目的地调度依然落后，但绝对值有所改善，30秒概率上升到77%，90秒概率达到100%。也就是说，在运力相对充裕的时候，三种算法都能把极端等待时间压到较低水平，但如果看30秒这个“舒适等待”的达成率，差距依然存在。
模拟器里没有给出某种算法在所有条件下通吃的结论，这是它最诚实的地方。早高峰时目的地调度被四台电梯拖累得厉害，RSR在某些场景下也不如简单规则稳定，而一旦增加运力，差距就会收窄。赫里克把这个工具完全开放，任何人在浏览器里就能调整楼层结构、乘客密度和电梯数量，亲眼看着三种算法在相同输入下跑出截然不同的概率曲线。你可以在 john.fun/elevators 找到这个模拟器，页面底部就能直接运行，带有动画演示，各算法的策略差异在图形中展露无遗。
电梯调度的选题听起来像是运维工程师或者物业经理才会关心的事，但这个模拟器把“一个好的调度策略到底值多少”变成了肉眼可见的概率差值：从48%到94%，中间隔着的可能就是早高峰大堂里乌压压排队的焦躁与安静快速分流之间的真实体感。没有哪种算法天然适用于所有大楼，但在特定条件下，选错规则的代价就是用脚投票的等梯时间。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
