我为一家车队跟踪公司工作，这个问题具体是关于我打算如何做报告。让我解释一下我们的环境。我们有1x数据库，1x负载分配过程和3x报告处理服务器（让我们假设它们在各方面都相同）。当客户请求报告时，该报告的所有参数都将进入数据库。我目前正在开发一个负载分配应用程序，它将从数据库中获取待处理的报告，并将它们委托给构建和通过电子邮件发送报告的3个报告处理服务器。当服务器完成报告（或出现错误）时，它会通知负载分发应用程序。报告可以有各种尺寸，从1辆车的1天GPS数据到数百辆车的3个月GPS数据。
我可以想到几种方法来实现负载平衡，但我对它们并不满意。我可以让每个服务器最多只做5个报告，但是1个服务器可能得到5个小报告而另一个得到5个大报告。我可以做一个“Round Robin”方法，只是在服务器上顺序分发报告，但这仍然不能防止任何服务器过载。
我认为我现在最好的想法是计算每个报告需要多少GPS数据（这是一项简单的任务），当我为每个服务器分配报告时，我保留每个服务器的运行总计。当服务器完成报告（并通知负载均衡器）时，从该服务器的运行总计中减去该报告的GPS数据量。这样，我可以将下一个报告分配给服务器，使用最少量的GPS数据。我也可以设置一个最大值，这样服务器就不能过度工作（导致我们重构整个报告过程的问题开始）。如果所有服务器达到最大值时有更多报告，它可以将它们排队，并在服务器完成一些报告后再尝试。
我不相信这是尽快完成报告的最佳方法。这些是我迄今为止所提出的最好的。
如何优化我的方法来跨多个服务器负载均衡不同大小的报告？
答案 0 :(得分：0)
假设您只有一个主表可以从中选择数据，那么我会先配置一台服务器来执行所有大型报表，然后让其他两台服务器执行从最小到最大的操作。否则大报告可能永远不会完成。
对于较小的报告，您希望在没有任何更好的情况下尝试让他们尝试运行“类似”报告，这意味着主要使用那些聚集在索引中类似值的报告。例如，如果服务器刚刚完成了2011年6月的报告，那么下一个要运行的最佳报告是同一时期，而不是跳到2012年11月。这虽然取决于实际的表，但我假设你订购了很多日期数据包括大部分选择。您真正要做的就是可能重用缓存索引/等的组报告，因为这应该可以提供最佳吞吐量。
我有一个类似的调度问题，任何针对主要表的查询都会转到一个服务器（慢速队列），而其他任何内容都转到另一个服务器（快速队列），特殊情况除外。