我正在尝试分发突发中收到的数据。这意味着我有一些其他应用程序在大突发中收到的数据。对于每个数据条目，我需要在某些服务器上做一些额外的请求，我应该限制流量。因此，我尝试在我拥有的时间内分散请求，直到下一个数据突发到来。
目前我正在使用token-bucket来分散数据。然而，因为我收到的数据形状已经很糟糕，我仍然要么填满待处理请求的队列，要么每当突发进入时我就会出现尖峰。所以这个算法似乎没有做我需要的那种整形。
还有哪些其他算法可以限制请求？我知道我有高负载时间和低负载时间，所以两者都应该由应用程序处理好。
我不确定我是否真的能够解释我目前遇到的问题。如果您需要任何澄清，请告诉我。
修改：
我会尝试更多地澄清问题并解释，为什么简单的速率限制器不起作用。
问题在于交通的突发性质以及爆炸在不同时间具有不同大小的事实。最常见的是每次爆发之间的延迟。因此，我们得到一堆数据记录进行处理，我们需要在下一批进入之前尽可能均匀地将它们展开。但是，当下一束进入时，我们并不是百分之百确定，只是近似，所以很简单{ {1}}无法正常工作。
速率限制不起作用，因为这种方式的数据传播不充分。如果我们接近饱和率，一切都很好，我们均匀分布（虽然这不应该经常发生）。如果我们低于门槛，那么传播会变得更糟。
我会举个例子来说明这个问题：
假设我们将流量限制为每秒10个请求，新数据大约每10秒钟发送一次。
当我们在一个时间段开始时获得100条记录时，我们将每秒查询10条记录，并且我们有一个完美的均匀分布。但是，如果我们只得到15条记录，我们将有一秒钟查询10条记录，一秒钟我们查询5条记录，8秒查询0条记录，因此我们的流量水平随时间变化非常大。相反，如果我们每秒查询1.5条记录会更好。然而，设置此速率也会产生问题，因为新数据可能更早到达，因此我们没有完整的10秒，1.5查询是不够的。如果我们使用令牌桶，问题实际上会变得更糟，因为令牌桶允许突发在时间帧的开始处通过。
然而，这个例子简化了，因为实际上我们无法在任何给定时刻完全告知待处理请求的数量，而只是一个上限。所以我们必须根据这个数字来限制每次。
答案 0 :(得分：1)
如果没有其他限制，您应该做的是计算出您发送其他请求所感到的最大数据速率，并根据该数据限制您的处理速度。然后监控正在发生的事情。如果快速通过您的所有请求，那么没有任何伤害。如果它的持续处理水平不够快，那么你需要更多的容量。
答案 1 :(得分：1)
这听起来像control theory域内的问题。具体来说，我认为PID controller可能有用。
问题的第一个问题可能是将记录数除以下一批的估计时间。这就像一个P控制器 - 只有比例。但是你冒着过高估计时间的风险，并建立一些未发表的记录。因此，请尝试添加I术语 - 积分 - 以解决构建错误。
如果批量大小的变化是随机的，我不确定您是否需要衍生术语。因此，尝试使用PI循环 - 您可能会在突发之间建立一些积压，但它将由I术语处理。
如果积压是不可接受的，那么解决方案可能会更复杂......