我正在尋找一種算法來限制傳入請求到REST HTTP服務器。泄漏桶算法的通用細胞率算法的優點
按我的理解漏桶有以下限制：我已經通過「漏桶」 &「虛擬Schedulling通用信元速率算法」不見了請求在時鐘滴答之前出現（當我們實際處理請求時），那麼請求必須等待時間直到時鐘滴答。在網絡域
我已經通過這個blog它實現「：虛擬Schedulling通用信元速率算法」不見了。
一些可以解釋我的以下內容： -
泄漏桶算法有兩個變體，meter和queue。這裏的儀表比較重要，所以我們來關注它。
這個想法是，一個桶被分配一個點滴速率（或者統一在桶之間，或者基於某一層）。進來的工作有一些與其相關的「音量」。它可以裝入桶中或不裝入。如果沒有，它會被丟棄。如果它適合，它將通過處理（至少在米級版本中）。
誰負責滴水桶？你提到的博客聲稱，這通常是通過後臺進程完成的，這個後臺進程圍繞桶循環並將其滴落。它提到了一個缺點，如果它可以處理桶的速度很低（極端情況下它會下線），可能會丟棄一項工作，這並不是因爲沒有足夠的空桶容量，而是因爲滴水過程只是沒有更新它。這基本上是你的觀點1;我沒有看到第2點的問題（儘管您可能已經閱讀了關於漏桶的版本之一的描述，該漏桶限制爲統一的卷，但沒有什麼內在的算法需要這個）。
這就是GCRA進來的地方。如果你仔細想想，單獨的滴水過程並不是真的需要。如果您跟蹤每個存儲桶當前的狀態併發布作業，則可以在下一次計算任何給定的未來作業大小時將有足夠的空卷。所以，當工作到達時，它只是檢查它是在這個時間之前還是之後。如果它來之前，它被丟棄。如果它來了，它會被通過，直到下一個工作的時間被更新。
關於您的問題（這是有關）：
由於與GCRA你不依賴於滴水一個單獨的進程，你會不會碰上它死亡或真不敢問題跟不上。這導致了下一點：特別是，
如果你運行分離過程的頻率很高，那麼，只要滴水過程保持不變，事情就很好。然而，頻率很高，滴水過程不會跟上。
注意，有沒有免費的午餐，雖然。無論您擁有哪種處理能力，都需要檢查空容量，並更新滴水。因人而異。對於某些設置和實現，可以很容易地想象單獨的滴流過程（假設某人設計好系統並且不會脫機），從而爲整個系統提供總體更低的延遲，更高的吞吐量或兩者。其他設置和實現可能會有相反的結果。