我想问一下，对于以下情况，有人会对最佳（最快）算法有所了解：
限制
目前我无法想到其他限制。
此方法的缺点
还有一些细节可以帮助您更清楚地看到图片。
现在我考虑了以下方法：
现在这种变化是否切合实际？就像我说的，每个Y进程都有自己的队列，保持它似乎没有效率。如果是这样，那么我仍然不确定下一点：
如何决定要提取的文件
我已经阅读了背包问题，我认为如果我从一开始就拥有整个文件列表，那么它就有应用程序。实际上，我确实有每个文件的列表和大小，但我不知道何时可以准备好每个文件。
我已经解决了生产者 - 消费者问题，但是它以固定缓冲区为中心并进行了优化，但在这种情况下，缓冲区是无限的，我不关心它是大还是小。
下一个最佳选择是贪婪的方法，其中每个Y进程锁定最小的文件并接受它。起初它看起来似乎是最快的方法，我目前正在建立一个模拟来验证，但第二个意见会很棒。
更新 为了确保每个人都能得到全局，我在这里链接一个快速完成的图表。
答案 0 :(得分：0)
目前的LB想法不好
你所描述的负载均衡器是一个坏主意，因为预测未来是不必要的，你说这是不可能的。此外，当作业有不同的长度时，循环法是一种糟糕的调度策略。
让消费者在闲置时通知LB。当新作业从生产者到达时，它会选择第一个空闲消费者并将作业发送到那里。当没有空闲的消费者时，生产者的工作在LB排队等待免费消费者出现。
这样，消费者将始终处于最佳状态。
你说“拥有一个服务100个应用程序的队列（例如）会效率低下。”这是直觉的巨大飞跃，可能是错误的。只处理文件名的工作队列可以很快。您只需要比平均“非常大的文件”处理操作快100倍（因为您推断有100个消费者）。文件处理通常是秒的十分之一秒。例如，基于Apache mod或Redis的两个随机选择的队列处理程序可以非常容易地每秒处理10,000个请求。这是一个因素而不是瓶颈的因素。
如果您从基于FIFO的空闲消费者中进行选择，则当所有作业长度相等时，行为将是循环的。
如果LB绝对不能排队工作
然后让Ty（t）为在当前时期完成消费者y队列中的工作所需的总未来时间。 LB的目标是使所有y和t的Ty（t）值相等。这是理想的选择。
为了尽可能接近理想值，需要一个内部模型来计算这些Ty（t）值。当一个新工作在时代到达生产者时，它会找到具有最小Ty（t）值的消费者y，将该工作分配给该y，并相应地调整模型。这是“剩余最少时间”调度策略的变体，对于这种情况是最佳的。
模型必然是近似值。近似的质量将决定其有用性。
标准方法（例如来自OS调度）将为每个消费者y维持一对[t，T] _y。 T是在过去的时期计算的Ty（t）的估计值。因此，在稍后的时期t + d，我们可以将Ty（t + d）估计为max（T-t，0）。最大值是因为对于d> t，估计的作业时间已到期，因此消费者应该完成。
LB使用它可以获得的任何信息来更新模型。例子是作业需要的时间估计（根据您的描述可能基于文件大小和其他特征），消费者实际完成作业的通知（LB通过已完成作业的预计持续时间减少T并更新t），赋值一项新工作（LB将新工作的估计持续时间增加T并更新t），以及长期工作期间消费者估计剩余时间的中间进度更新。
如果LB的可用信息是详细的，您将需要将[t，T] _y对中的总时间T替换为在y处排队的工作的更完整模型：例如估计作业的列表持续时间，列表的头部是当前正在执行的那个。
LB模型越准确，消费者在工作可用时就会越不可能挨饿，这是您要避免的。
