我有一个架构问题。 在集群Web应用程序环境中，我可以想到三种处理后台作业的方法：
什么是首选方法？
如果你有这些资源，而且它们运行的后台任务并不重要，我会select1。
没有任何理由，除了为什么如果你不需要负担你的networking服务器。
这取决于你的预算，但最好的方法是在不同的服务器上运行作业。 它可以很好地区分顾虑，而且不必担心被繁重的工作所影响的networking体验。
IANAExpert，但我会想象，选项1将是可取的。 这背后的原因是一个简单的关注分离。 如果工作有自己的专用机器，你可以更好地pipe理发展。 如果使用选项2，那么您的作业处理潜力将与其要求不符。 尽pipe无论是一台机器还是多台机器运行这些工作，所使用的资源都应该是相同的，但我想象一下，您使用的任何排队系统都有一定的开销。 此外，如果队列或networking服务器出现问题，则不会将其他服务器closures。 你已经把应用程序的每一部分都划分了，所以你可以根据需要增长，而不是像你的架构所要求的那样。
每个选项都有优点和缺点，并在任何情况下select首选方式是需要（imho）多一点的信息。 例如，什么样的背景工作？ 这是一个至关重要的问题，因为例如，如果业务stream程利用已经存在的集群可能是有趣的。
例如，如果与业务不直接相关的维护过程（或用户需求）可能具有分离的硬件（或虚拟）更有意义。
根据我的经验，有的时候，我们所有的人都不太愿意充分利用这个群集，但是这个群集正在使用它们！
Peldi，考虑使用一种方法，允许有一个单独的作业队列（最好在数据库中），以及一个或多个作业运行者。 这样，您可以在一台或多台不同的机器上运行一个或多个作业工作人员 – 这将使您的configuration更为灵活。
我不知道你要运行什么types的任务，哪些技术可以使用，但是在Ruby / Rails世界中，这样的任务可以使用delayed_job来解决
有关后台处理的其他信息，请访问http://en.wikipedia.org/wiki/Job_scheduler
就个人而言，在我的项目中，我在数据库驻留的同一台机器上运行后台作业，但如果需要的话，以后可以添加更多的工人/机器。
希望这可以帮助 ：）
面对同样的情况，你在：
我不会去select1，因为你有一个单一的失败点。 或额外的架构工作，以防止失败
我不会去select3，因为你最终会得到不一样的networking节点，这将阻碍未来的自动化。
我会使用选项2，并有一个中央队列服务，最好是基于云的一个，因为它已经成群，从而为您节省了故障转移，比例等的负担
我假设你已经处理了故障转移并通过使用你的web节点的集群来加载，所以我只是简单地增加了这些马的工作负载，而是在一个单独的过程中运行。
希望有所帮助