电梯的一点浅优化
电梯的一点浅优化
1、调度方案的选择
第六次作业要做一个可捎带的电梯,如何呢?指导书给了ALS,我觉得ALS也有固有弊端,比如可能会在有乘客时掉头。从用户体验上,这是极差的,而且一般情况下(除非是这一层刚走了狼半秒钟又来了虎,比如某组变态的数据)这种掉头会增加时间开销。所以,我采取了贴近生活的look算法,就是咱们楼道里那个电梯的调度算法。
查了一下,电梯的几种调度算法,包括:scan算法,look算法,ALS,还有FAFS,最近距离等。
scan算法是上下循环调度,类似于摆渡车、轮渡,缺点是没有乘客的楼层也要停。
look是scan的改进,没有乘客和请求的楼层不停,直接掉头。
ALS和FAFS太熟悉了,不用说。
还有一种是最近距离,也就是当电梯内有乘客时,乘客优先。无乘客时,距离当前楼层最近的请求优先。但这会出现某些请求“饿死”的情况。
综合以上几种,还是look比较好。
基本思想就是,请求要分为电梯外请求和电梯内乘客两部分。电梯外请求按照出发楼层分类,电梯内请求按照目标楼层分类。每当电梯到达某一层时,检查是否需要上客或下客,有则开门,无则甩过直接走。每当准备移动到下一层时,检查是否需要掉头(检查是否掉头是一个扫描过程,如果电梯内有乘客则不能掉头,否则扫描电梯外请求,如果当前方向上没有请求则掉头,如果两边都没有请求,则停下来等待)。
一个最简单的优化,就是停在某一层的时候,以关门时间为粒度,检查要上的乘客。比如我现在是开门状态,就等待200毫秒,如果这200毫秒内有需要上的乘客则让他上,并继续等待200ms,如此循环,直到某个200ms内没有乘客可以上为止。这种方法虽然增加了停靠时间,但往往减少了捎带乘客的遗漏,在大量乘客请求中表现良好。
另外,如果还想骗一点分,还可以变通一下,在某一层开门,一股脑都上,不管方向如何,运行到目标楼层再放出去。这就减少了开关门总次数。但是在多电梯中不适用,因为多个电梯是并行的,不顾一切地把乘客吸走,不仅影响调度器,而且会有超载等问题。
2、大量数据下时间性能的提高--平摊分析
第七次作业不仅增加了两部电梯,而且增加了乘客数量限制、停靠层限制。所以,这决定我们需要一个调度盘来把乘客请求分配到合适的电梯上去。并且,考虑换乘问题。
架构就是三个电梯、一个调度盘,请求队列分三块,一块是原始请求,也就是刚输入的时候,没有经过调度器分配,可以理解为站在大厅门外。一块是分配后请求,可以理解为站在某个电梯门口。最后是电梯内乘客。
换乘不难解决,为了一劳永逸的防止出错,我们把未完成的请求扔回原始请求中,也就是回滚。这样保证各个电梯互相独立。电梯只负责运送乘客,不管任何调度问题。
但是调度问题比较棘手。最简单又保证正确的就是按照A,B,C的顺序来搜索合适的电梯,搜索到第一个合适的电梯即为所求。但是,这样就有一个弊端,因为每个电梯都有人数限制,一部电梯门口排太多人会导致有些人等待时间太长从而影响效率。而且,与其让B、C空着,不如让它们动起来,减小A的压力。
所以,我们要尽可能地把这些人分配到不同的电梯中。这时,搜索可分配电梯的顺序就至关重要。
什么叫尽可能?做到任何情况下最优是一个NP完全问题。真正关心的是大量乘客下平均时间性能。所以,摊还分析又大显身手了。
我们把A、B、C的六种搜索顺序(ABC ACB BAC BCA CAB CBA)排成一列,然后每次随机取一种顺序进行搜索,搜索到的第一个可行电梯作为分配目标。这样多个请求就会分配到多个电梯中。有了三个电梯的并行,效率会大大提高。
// Dispatcher.java(调度器)部分源码
private final Random random = new Random();
private final int[][] arr = {
{0, 1, 2}, {0, 2, 1},
{1, 0, 2}, {1, 2, 0},
{2, 0, 1}, {2, 1, 0}
}; // 六种顺序
// 注:fixFloor()方法是寻找合适的换乘点,如果返回值等于出发楼层,说明这个电梯不能上。如果返回值等于目标楼层,说明不需要换乘。
private void dispatch(PersonRequest request, int fromFloor)
throws InterruptedException { // 分配函数
int i;
int toFloor = Elevator.realFloor(request.getToFloor());
int[] tmp = arr[random.nextInt(6)]; // tmp就是选取的搜索顺序
for (i = 0; i <= 2; i++) {
if (selfRequests[tmp[i]].containsKey(fromFloor)
&& fixedFloor(tmp[i], fromFloor, toFloor) != fromFloor) {
selfRequests[tmp[i]].get(fromFloor).put(request); // 找到第一个可行电梯
return; // 这个return是一定能执行到的,因为每一层至少有一个电梯可以上
}
}
}
看强测结果已经是出乎意料的好了,最终得分92.7,得到一半的性能分,甚至有的点达到96。自己测试的话,20个随机请求,大约是3~50秒之间发出,最初的贪心算法是91秒跑完,换随机之后降低到74秒。效果还是非常好的。
所以说,一个良好的随机算法有时能轻松碾压某些确定性算法的。毕竟按照请求做最短路搜索这种工作量又大,又不能保证优化效果,因为电梯不是无限载客的。尤其是电梯这种注重平均性能的东西,平摊分析更是制胜法宝。
以上就是我对电梯优化的一个办法。dalao们如果有实时调度的算法,欢迎交流。