我一直在研究一个全面的构建系统，它在很长一段时间内在多台机器上执行分布式构建。它正确地处理依赖关系并且似乎相当好地扩展，所以我们添加了更多的项目和更多的机器，但看起来它可以表现得更好。
我遇到的问题是资源分配问题。我有一个可用机器列表和一个我想要构建的项目列表，每台机器都列出了安装了什么软件，操作系统，编译器版本等，每个项目都列出了它需要的内容。当需要分配工作时，我可以运行列出可能的分配的数据库查询。现在我需要尽可能有效地执行这些任务。
最小的例子是两个项目1和2，有两台机器A和B.机器A可以构建任一项目，但机器B只能构建项目1.所以我最终得到一对（A，1），（ A，2），（B，1）。如果我按顺序处理分配，机器A构建项目1，我必须等到它完成才能构建项目2.将机器A分配给项目2并将机器B分配给项目1可能会更好。但是。机器A可能比机器B快得多，而根本不使用机器B可能是正确答案。
我确信这是一种“运营研究”问题，之前已经多次得到解决。我不一定需要一个最佳的解决方案...只是尝试一些比我更好的东西 - 似乎我经常最终排队等待的任务和机器闲置，这可以避免更好的分配。任何建议都是最受欢迎的。
答案 0 :(得分：4)
您尝试解决的问题等同于传统的Job Shop Scheduling问题。找到最佳时间表是NP难的。
人们已经发明了许多启发式方法来生成时间表，但哪些是好的，是高度依赖问题的。
一些常见的启发式方法是：
答案 1 :(得分：2)
首先，我的偏好是“拉动”模式。
每台计算机在空闲时从中央服务器中提取任务。
中央服务器提供一种优先级队列，包依赖顺序。每台机器都从中央服务器发出请求，并分配了一些工作要做。
您有一种池模型，您可以在其中进行任务分类，以及具有匹配分类的计算机池。例如，池1中的机器可以构建某些东西。池2中的机器可以构建任何东西。将它们视为“技能”，您将看到这是一种项目管理问题。
如果您的机器非常慢，您必须将它们优化到一个单独的池中，这样它们才能获得没有依赖关系的小分支。
这可能就是你所需要的。但是，如果您想进一步优化，请执行下一步。
运行几次后 - 并对性能有一些期望 - 然后您可以编写一个模块，试图让每台机器尽可能保持忙碌状态。这种调度正是微软项目所做的。
给定具有持续时间和依赖性的任务，您尝试进行“资源调配”。您希望每个资源（在您的情况下编译客户端）尽可能繁忙，与每个客户的技能和生产力保持一致。
答案 2 :(得分：0)
首先想一想，我建议在每台机器上运行Windows服务，其中一台机器也运行主服务来协调分配。主服务轮询每台机器是否正在处理分配，如果不是，则开始处理队列中能够处理的任何分配。