通用信元速率算法相对于漏桶算法的优势

漏桶算法有两种变体, meter 和 queue 米一在这里更相关,所以让我们关注它。

其思想是给一个桶分配一个滴水率(或者在桶之间统一,或者基于某一层)。传入的作业有一些与之关联的“卷”。它可以装进桶里也可以不装。如果没有,它将被丢弃。如果它适合,它将通过处理(至少在仪表版本中)。

谁负责滴水桶?你提到的博客声称,这通常是由一个后台进程完成的,该进程在桶周围循环并滴下。它提到了一个缺点,即如果它处理bucket的速度很低(在极端情况下,它会离线),那么作业可能会被丢弃,不是因为bucket没有足够的空卷,而是因为滴水过程没有更新它。这基本上是你的观点1;我不认为您的第2点有什么问题(虽然您可能已经阅读过关于限制为统一卷的无数版本的leaky bucket之一的描述,但算法本身并不需要这样做)。

这就是GCRA的用武之地。如果你考虑一下,一个单独的滴水过程其实并不必要。如果您跟踪每个存储桶的当前状态和作业进入,您可以计算下一次对于任何给定的未来作业大小将有足够的空卷的时间。所以,当一份工作到来时,它只是检查它是在这段时间之前还是之后到来的。如果它以前出现过,则会被丢弃。如果它出现在之后,它就会通过,直到下一个作业的时间也会更新。

关于您的问题(相关):

1. 由于使用GCRA,您不需要依赖单独的过程来滴水,因此您不会遇到它死掉或无法跟上的问题。这引出了下一点:特别是,

2. 如果你以非常高的频率运行单独的过程,那么,只要滴水过程持续下去,一切都很好。不过,如果频率很高,滴水过程可能会跟不上。

不过请注意,这里没有免费午餐。无论您拥有何种处理能力,都需要有人检查空卷,并更新滴水。基督教青年会。对于某些设置和实现,很容易想象一个单独的滴水过程(假设有人很好地设计了系统,并且它不会离线)会给系统带来整体较低的延迟和/或较高的吞吐量。其他设置和实现可能会有相反的情况。