Algorithm 搜索一种类似生产者-消费者的算法

我想问一下，对于以下场景，是否有人对最佳（最快）算法有想法：

• X进程生成一个非常大的文件列表。每个进程一次生成一个文件
• Y进程将收到文件准备就绪的通知。每个Y进程都有自己的队列来收集通知
• 在给定时间，1x进程将通过具有Round Rubin算法的负载平衡器通知1y进程
• 每个文件都有一个大小，当然，更大的文件会使X和Y更忙

限制

• 一旦文件进入Y进程，将其删除并移动到另一个Y进程是不切实际的

目前我想不出还有其他限制

这种方法的缺点

• 有时X会落后（不再推送文件）。它实际上不受排队系统的影响，无论我是否更改它，它仍然会有缓慢/良好的时间
• 有时Y落在后面（许多文件聚集在队列中）。再一次，和以前一样
• 1 Y进程正忙于处理一个非常大的文件。它的队列中还有几个小文件，可以由其他Y进程处理
• 通知本身是通过HTTP发送的，有时似乎不可靠。通知失败，调试未显示任何信息

还有一些细节将有助于更清楚地了解情况

• Y进程是DB线程/作业
• X进程是web应用程序
• 一旦文件到达X进程，这些进程也会通过查询数据库来烧掉数据库端的资源。它对生产零件有影响

现在我考虑了以下方法：

• X将像以前一样生成文件，但不会通知Y。它将保存一个缓冲区（表）来填充文件列表
• Y将不断搜索缓冲区中的文件，并自己检索它们，并将它们存储在自己的队列中

现在，这一改变是否切实可行？正如我所说，每个Y进程都有自己的队列，似乎不再有效地保留它了。如果是这样，那么我还没有决定下一点：

如何决定提取哪些文件

我已经通读了背包问题，我认为如果我从一开始就有完整的文件列表，而我没有，那么这个问题就有了应用。事实上，我确实有每个文件的列表和大小，但我不知道每个文件什么时候准备好

我已经经历了生产者-消费者问题，但它围绕着一个固定的缓冲区进行优化，但在这种情况下，缓冲区是无限的，我真的不在乎它是大还是小

下一个最好的选择是贪婪的方法，其中每个Y进程锁定最小的文件并获取它。起初，这似乎是最快的方法，我目前正在构建一个模拟来验证这一点，但第二个意见将是非常棒的

更新 为了确保每个人都了解全局，我在这里链接了一个快速完成的图表

• 作业独立于流程。它们将以一定的速度运行并处理可能的文件数量
• 当作业使用文件完成时，它将向LB发送HTTP请求
• 每个进程对来自LB的请求（文件）进行排队
• LB按照循环规则工作

---

当前的LB想法不好

正如您所描述的，负载平衡器是一个坏主意，因为预测未来是不必要的，您说这是不可能的。此外，当作业具有不同的长度时，循环调度是一种糟糕的调度策略

只要让消费者在闲置时通知LB即可。当新作业从生产者到达时，它选择第一个空闲消费者并将作业发送到那里。当没有空闲消费者时，生产者的作业将在LB中排队，等待空闲消费者出现

这样，消费者将始终处于最佳忙碌状态

你说“让一个队列服务100个应用程序（例如）将是低效的。”这是直觉的巨大飞跃，可能是错误的。只处理文件名的工作队列可能很快。您只需要比平均的“非常大的文件”处理操作快100倍（因为您推断有100个使用者）。文件处理通常是10秒或10秒。比如说，基于ApacheMod或Redis的队列处理程序（用于两个随机选择）可以很容易地每秒处理10000个请求。这距离成为瓶颈只有10倍之遥

如果在FIFO基础上从空闲消费者中进行选择，则当所有作业长度相等时，行为将是循环的

如果LB绝对不能排队工作

然后，让Ty（t）为在当前时刻t完成消费者y队列中的工作所需的总未来时间。LB的目标是使所有y和t的Ty（t）值相等。这就是理想

为了尽可能接近理想，需要一个内部模型来计算这些Ty（t）值。当一个新作业在时间点t从生产者处到达时，它会找到具有最小Ty（t）值的消费者y，将作业分配给该y，并相应地调整模型。这是“剩余时间最少”调度策略的一种变体，对于这种情况是最优的

该模型必然是一个近似值。近似值的质量将决定其有用性

标准方法（例如，从操作系统调度）是为每个用户y维护一对[t，t]\u。T是在过去的历元T计算的Ty（T）的估计值。因此，在稍后的时间点t+d，我们可以将Ty（t+d）估计为max（t-t，0）。最大值是因为对于d>t，估计的作业时间已过期，因此使用者应该已完成<