假设我有一个非常大的请求池，我想发送到远程主机。与任何服务器一样，远程主机的容量有限。最终必须传递所有信息，并且及时性是可取的，但并不重要。除了通过监视我发送的请求的响应时间和/或故障率之外，我无法知道远程主机的这种容量。
我需要开发一种算法，以最大化吞吐量的速率发送请求，而不会使远程主机崩溃。
最佳输出变量似乎是请求之间的时间段，因此请求N在请求N-1之后的M纳秒被调度。
我应该如何处理确定最佳费率的问题？有没有我可以建立的论文？或者任何人都可以提出一些奇迹算法？有人这么做过吗？
注意：令牌桶不是我正在寻找的答案。我已经在使用非常像令牌桶的东西，但我正在寻找一种方法来确定应该将令牌添加到桶中的速率。
答案 0 :(得分：2)
当我编写网络抓取工具时，我没有想出一个神奇的算法。我们使用了一些似乎做得相当不错的启发式方法，虽然肯定不是很完美。
首先，我们查看了该网站的robots.txt文件。如果它有一个爬行延迟条目，我们尊重它永远不会超过它。
对于其他服务器，我们将保持最后n个请求所需时间的运行平均值（我认为我们确定了值为5），并且我们确保我们从未比平均值更频繁地发送请求。我们测量了从我们提出请求到处理完响应的时间。
如果服务器超时，该请求的时间将进入运行平均值。
如果我们从服务器获得50x，我们会在向该服务器发出另一个请求之前延迟相当长的时间（五分钟或更长时间）。重复的50倍响应会导致我们停止发出请求，直到有人能够看到问题所在。
我们还跟踪了40倍的回复。许多未找到或访问被拒绝将导致爬虫停止处理域并提出一个标志，以便有人可以查看它。
我们有一个分布式抓取工具。任何单个爬虫都不会向同一个域发出并发请求，而且我们进行了一些跨服务器通信，这使得多个服务器对同一个域发出并发请求变得很不寻常。
我确信这并没有在任何特定服务器上最大化吞吐量，但它确实让较大的网站非常繁忙。更重要的是，它阻止了我们（大多数情况下，无论如何）被许多网站阻止。
我们还为许多使用API的网站进行了特殊情况处理。有人会说他们的请求限制是什么，我们会调整这些网站的设置，所以我们就在这条线上。但我们只有几十个。手动配置9,000台服务器的请求频率（然后跟上变化）是不现实的。但是，您可以手动配置十二个或两个。