每个人都经历过这样的时刻：站在电梯厅里盯着楼层指示灯，心里默念”我按了按钮，为什么还不来？”电梯是如此日常的设施，以至于很少有人想过它背后的调度逻辑。本周，一篇发布在 john.fun 上的交互式长文《Elevators》登上 Hacker News 榜首（813 分、200+ 评论），用一系列可交互的可视化动画，把电梯调度这个”隐藏的算法世界”拆解得清清楚楚。
背景：1961 年就诞生的经典算法
最简单的电梯调度算法叫 SCAN，1961 年就获得了专利：电梯从大堂出发一路坐到顶层，然后掉头向下，沿途接送所有乘客。这个算法逻辑简单，但大多数时候你并不需要坐到顶层——于是有了改进版 LOOK 算法：电梯只升到”有请求的最高楼层”就反向，这也是大多数人印象中电梯应有的行为方式。
真正的复杂度出现在多部电梯协同的场景。最基础的方案是中央调度器：新请求进来时，分配给”最近的电梯”。但文章很快指出，这个朴素策略远非最优——如果最近的电梯已经满载呢？如果两部电梯正挤在同一个方向、同一楼层”扎堆”呢？
核心洞察：你记住的不是平均等待，而是 p90
如何衡量一个电梯算法的好坏？最直观的指标是等待时间，比如”90% 的情况下电梯能否在 30 秒内到达”。但文章用直方图展示了更严谨的视角：等待时间的完整分布。平均等待 1 分钟并不重要——乘客记住的永远是那些”等了半天都不来”的极端时刻，也就是 p90 分位值。优化电梯算法的本质，是在压平这条长尾。
更难的是，客流并不是均匀分布的。早高峰几乎所有流量都是从大堂涌向楼上，晚高峰完全反转，午间双向混合，其余时间以楼层间流动为主。早高峰的等待统计永远最难看——这也是所有调度算法的”期末大考”。
技术分析：Otis 的 RSR 评分机制
文章的重头戏是奥的斯（Otis）公司的 RSR（Relative System Response，相对系统响应）算法。它不再简单地”派最近的车”，而是为每部电梯打一个”接客适合度”分数，分数越低越合适：
RSR 分数 = 预计到达时间 + 载客量惩罚 + 反扎堆惩罚 − 同方向加成 − 附近空闲加成 − 低负载加成
其中几个设计颇具巧思：
· 反扎堆惩罚：如果另一部电梯已经同方向驶向同一楼层，就 penalize 当前电梯，避免两部车做重复功；
· 空闲加成：奖励呼叫楼层两层以内的空闲电梯；
· 每 5 秒重新优化：原本分配给 A 电梯的乘客，如果 A 遇到延误，可以被重新路由给 B。文章指出，这种持续的再优化正是平滑客流的关键。
配合文中实时的交互模拟——每部电梯会”亮灯”显示此刻它是响应 3 楼呼叫的最佳选择，而随着电梯移动这个最佳选择不断变化——读者可以直观看到调度系统在”思考”什么。
社区反响
这篇文章在 HN 上引发了强烈共鸣。点赞最多的评论戏称它”勾起了 5 年前那场恼人的面向对象设计面试的回忆”——电梯调度是 CS 面试和课程作业的经典题目，不少人分享了 2011 年”造一个更好的电梯控制捕鼠器”的课程论文。还有多位读者推荐了编程游戏 Elevator Saga（play.elevatorsaga.com），让玩家自己编写电梯调度策略来通关，堪称这篇文章的”可玩版”。也有人感慨：每次等电梯时都在想，做这套算法的人要同时最小化接人和送人的等待，该有多纠结。
结语
《Elevators》的价值不仅在于科普了一个垂直交通领域的经典问题，更在于它展示了”交互式解释”这种内容形态的力量：抽象的分位数、惩罚项、再优化策略，在动画面前都变得可触摸。下次再吐槽电梯慢的时候，你或许会对那个每 5 秒重新计算一次的调度器多一分敬意。
原文链接：https://john.fun/elevators
HN 讨论：https://news.ycombinator.com/item?id=49124218