我正在尝试分散接收到的突发数据。这意味着我有一些其他应用程序以大量突发方式接收的数据。对于每个数据条目，我需要在某些服务器上执行一些额外的请求，我应该在这些服务器上限制流量。因此，我尝试在下一个数据突发到达之前的时间内分散请求。
目前我正在使用 token-bucket分散数据。然而，因为我收到的数据已经被严重整形，所以我仍然要么填满待处理请求的队列，要么在突发事件到来时出现峰值。所以这个算法似乎没有做我需要的那种整形。
还有哪些其他算法可用于限制请求？我知道我有高负载的时候和低负载的时候，所以应用程序应该很好地处理这两者。
我不确定我是否真的能够解释我目前遇到的问题。如果您需要任何说明，请告诉我。
编辑:
我将尝试进一步澄清问题并解释为什么简单的速率限制器不起作用。
问题在于流量的突发性质以及突发在不同时间具有不同大小的事实。几乎不变的是每次突发之间的延迟。因此我们得到了一堆数据记录进行处理，我们需要在下一批进来之前尽可能均匀地分散它们。但是我们不能 100% 确定下一批何时进来，只是大概，所以一个简单的 按记录数划分时间没有正常工作。
速率限制不起作用，因为这种方式的数据传播不够充分。如果我们接近速率饱和，一切都很好，我们均匀分布(尽管这种情况不应该经常发生)。如果我们低于阈值，则传播会变得更糟。
我会举个例子让这个问题更清楚:
假设我们将流量限制为每秒 10 个请求，并且大约每 10 秒接收一次新数据。
当我们在时间范围开始时获得 100 条记录时，我们将每秒查询 10 条记录，并且我们有一个完美的均匀分布。但是，如果我们只获得 15 条记录，我们将有 1 秒查询 10 条记录，1 秒查询 5 条记录，8 秒查询 0 条记录，因此随着时间的推移，我们的流量水平非常不均等。相反，如果我们每秒查询 1.5 条记录会更好。然而设置这个速率也会产生问题，因为新数据可能会提前到达，所以我们没有完整的 10 秒，1.5 次查询是不够的。如果我们使用 token 桶，问题实际上会变得更糟，因为 token 桶允许突发事件在时间帧开始时通过。
但是这个例子过于简化了，因为实际上我们无法完全知道在任何给定时刻待处理请求的数量，而只是一个上限。因此，我们每次都必须根据这个数字进行限制。
最佳答案
这听起来像是 control theory 领域内的问题.具体来说，我在想 PID controller可能有用。
解决该问题的第一步可能是将记录数除以到下一批的估计时间。这就像一个 P Controller - 仅成比例。但是你会冒着高估时间的风险，并建立一些未发送的记录。因此，尝试添加一个 I 项 - 积分 - 来解释累积误差。
如果批量大小的变化是随机的，我不确定您是否需要导数项。因此，请尝试使用 PI 循环 - 您可能会在突发事件之间积累一些积压，但它将由 I 术语处理。
如果积压是 Not Acceptable ，那么解决方案可能会更复杂......
关于algorithm - 从突发中传播数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7037635/