Linux电梯算法（LOOK）通过让磁盘读写头沿单一方向移动直到触及该方向最远请求，随后立即反转方向，从而显著减少磁头空跑距离，是平衡寻道时间与系统吞吐量的最优解。
在操作系统底层,磁盘I/O是性能瓶颈的高发区，想象一下，如果电梯只上不下，或者随机乱跑，乘客体验会极差，Linux内核中的电梯算法正是为了解决这种“混乱”而设计的，它不再盲目地响应每一个到达的请求，而是像一位经验丰富的调度员，将请求排序，规划出一条最合理的运动轨迹。
为什么需要电梯算法替代先来先服务
早期的磁盘调度多采用先来先服务（FCFS）策略，这种策略简单粗暴，谁先请求谁先服务，虽然公平，但效率极低，磁头可能在磁盘的最左端和最右端之间来回摆动，产生大量的机械磨损和等待时间，业内专家指出，在高并发场景下，FCFS会导致平均寻道时间急剧增加，进而拖慢整个系统的响应速度。
相比之下,电梯算法（SCAN）及其改进版LOOK算法，通过引入“方向性”和“边界感”，极大地优化了路径。
SCAN与LOOK的核心差异解析
很多人容易混淆SCAN和LOOK,其实它们的核心区别在于“是否走到物理尽头”。
- SCAN算法：磁头必须移动到磁盘的最外侧或最内侧，即使该方向没有更多请求，也要走完整个行程再折返，这就像电梯到了1楼还要再往下探一下确认没人才上来，浪费时间在空跑上。
- LOOK算法：这是Linux默认且更高效的策略，磁头只移动到该方向上最后一个有请求的磁道，然后立即反转方向，它不需要走到物理边界，节省了不必要的空转时间。
实际场景对比
假设磁头当前位于第100磁道,请求序列为：[86, 150, 102, 97, 177, 130, 60, 120]，且磁头正向磁道号增加的方向移动。
-
FCFS表现：100 -> 86 -> 150 -> 102… 磁头频繁左右横跳，总移动距离巨大。
- LOOK表现：100 -> 102 -> 120 -> 130 -> 150 -> 177（到达最远请求，反转）-> 97 -> 86 -> 60。
可以看到,LOOK算法将连续的请求合并处理，减少了磁头的启停次数，在机械硬盘时代，这能提升约30%-50%的I/O效率；即使在SSD时代，它依然对减少I/O队列延迟有重要意义。
Linux中的IO调度器演进与配置
随着硬件技术的迭代,Linux内核中的IO调度器也在不断进化，从传统的CFQ（完全公平队列）到针对SSD优化的Noop，再到现代内核中强大的MQ-Deadline和BFQ，理解电梯算法的演变有助于更好地调优系统。
传统调度器与NVMe时代的变革
在SATA SSD普及之前，CFQ是主流，它假设磁盘是机械的，因此需要公平地分配时间片给每个进程，对于NVMe SSD这种拥有成千上万个队列的硬件，CFQ显得过于沉重。
大多数Linux发行版默认使用MQ-Deadline或BFQ。
- MQ-Deadline：专为多队列设备设计，它在保证低延迟的同时，尽量保持吞吐量，它本质上是一个改进版的电梯算法，增加了超时机制，防止长请求饿死短请求。
- BFQ（Budget Fair Queueing）：更加智能，它试图为每个进程提供公平的服务带宽，对于桌面用户或数据库服务器，BFQ往往能提供更稳定的响应体验。
如何查看当前使用的调度器
你可以通过以下命令检查当前磁盘使用的调度算法：
cat /sys/block/sda/queue/scheduler
输出可能类似：[mq-deadline] kyber none，方括号内的即为当前激活的调度器。
不同场景下的调度策略选择
没有一种调度算法是万能的,根据业务类型选择合适的策略，能发挥硬件的最大性能。
数据库服务器场景
对于MySQL、PostgreSQL等数据库，随机读写频繁，延迟敏感。
- 推荐策略：MQ-Deadline或BFQ。
- 理由：数据库需要快速响应查询，MQ-Deadline的超时机制能确保关键事务不被阻塞，BFQ则能防止某个大查询独占磁盘带宽，影响其他小查询。
视频流媒体与文件服务器
这类应用通常是顺序读写,对吞吐量要求高于随机延迟。
- 推荐策略：Kyber或None（直通）。
- 理由：Kyber算法轻量级，适合NVMe设备，能根据队列深度动态调整延迟目标，如果使用高性能NVMe，甚至可以直接使用None调度器，让硬件自身处理队列管理，减少内核开销。
桌面办公与开发环境
用户希望系统响应迅速,鼠标点击后窗口立即弹出。
- 推荐策略：BFQ。
- 理由：BFQ的公平性设计能确保前台应用的优先级高于后台任务，提升用户体验的流畅度。
常见疑问与实操建议
Linux电梯算法与Windows调度有何不同
Windows NT内核早期使用简单的FCFS，后来引入了更复杂的优先级调度，Linux则更早地引入了基于队列和优先级的复杂调度器，Linux的优势在于其调度器的可配置性极高，用户可以根据硬件特性微调参数，而Windows通常采用黑盒优化，用户干预空间较小。
如何优化Linux磁盘IO性能
除了选择合适的调度器,还可以从以下几个方面入手：
- 调整I/O队列深度：对于NVMe设备，增加队列深度可以显著提升并行处理能力。
- 使用SSD而非HDD：物理介质的进步是性能提升的根本。
- 合理分区：将系统盘、数据盘、日志盘分离，减少争用。
电梯算法在容器化环境中的表现
在Docker或Kubernetes环境中,多个容器共享同一物理磁盘，如果配置不当，可能会出现“噪音邻居”问题，即一个容器的密集I/O拖慢其他容器。
- 解决方案：使用cgroups限制每个容器的I/O带宽和IOPS，结合MQ-Deadline调度器，可以更精细地控制每个容器的磁盘访问优先级。
总结与核心结论
Linux电梯算法并非单一的技术,而是一套动态演进的I/O调度体系，从SCAN到LOOK，再到MQ-Deadline和BFQ，其核心目标始终不变：在公平性、吞吐量和延迟之间找到最佳平衡点。
对于大多数现代Linux用户而言,默认调度器已经足够优秀，但在特定场景下，如数据库优化或高性能计算，手动调整调度器参数可能带来显著的性能提升，理解其背后的逻辑，比盲目追求“最快”的算法更为重要。
Q&A模块
Linux电梯算法在SSD上还有意义吗
有意义,虽然SSD没有机械寻道时间，但内部控制器仍需处理请求队列，合理的排序可以减少内部垃圾回收的压力，降低延迟波动，对于多队列SSD，调度器负责将请求分发到不同的硬件队列，这直接影响并行效率。
如何判断当前调度器是否合适
使用iostat -x 1命令观察%util（利用率）和await（平均等待时间），如果%util很高但await也很高，说明调度器可能成为瓶颈或磁盘本身过载，如果%util低但await高，可能是调度策略导致请求排队过长。
BFQ调度器适合所有硬件吗
不适合,BFQ计算开销较大，在低端嵌入式设备或极高吞吐的NVMe集群中，可能会引入不必要的CPU占用，对于这类场景，Kyber或None调度器更为合适，因为它们更轻量，能更好地发挥硬件并行能力。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/455316.html
