從爆發中傳播數據

Question

我正在嘗試傳播爆發中收到的數據。這意味着我有一些其他應用程序以大型突發接收的數據。對於每個數據條目，我需要在某些服務器上執行一些額外的請求，在這些服務器上我應該限制流量。因此，我嘗試在我擁有的時間內分發請求，直到下一個數據突發到達。

當前我正在使用token-bucket來分散數據。但是，由於我收到的數據已經很糟糕，我仍然要麼填滿待決請求的隊列，要麼每當有突發事件發生時我都會出現尖峯。所以這個算法似乎沒有做到我需要的那種整形。

有什麼其他算法可用來限制請求？我知道我有高負載和低負載的時間，所以兩者都應該通過應用程序來處理。

我不確定我是否真的能夠解釋我目前遇到的問題。如果您需要任何澄清，請讓我知道。

編輯：

我會盡力澄清問題多一些解釋，爲什麼一個簡單的速率限制不起作用。

問題在於流量的突然性和事實，即突發在不同時間有不同的大小。幾乎不變的是每次爆發之間的延遲。因此，我們得到一堆用於處理的數據記錄，並且我們需要儘可能均勻地分散出來，然後再進入下一羣。但是，我們並不是100％確定下一羣將進入什麼時候，只是大概地，所以一個簡單的divide time by number of records不應該像它應該那樣工作。

速率限制不起作用，因爲數據的擴散不足以這種方式。如果我們接近飽和的速度，一切都很好，我們均勻分散（儘管這不應該頻繁發生）。如果我們低於門檻，傳播會變得更糟糕。

我做出了榜樣，使這個問題更加清晰：

比方說，我們限制我們的流量每秒10個請求和新數據來自於每10秒左右。

當我們在一個時間範圍的開始獲得100條記錄時，我們將每秒查詢10條記錄，並且我們有一個完美的均勻傳播。但是，如果我們只有15條記錄，我們將在其中查詢10條記錄，其中我們查詢5條記錄的時間爲1秒，查詢0條記錄的時間爲8秒，所以隨着時間的推移，我們有非常不同的流量級別。相反，如果我們每秒只查詢1.5條記錄會更好。然而，設置這個速度也會產生問題，因爲新的數據可能會更早到達，所以我們沒有足夠的10秒鐘，1.5個查詢是不夠的。如果我們使用令牌桶，問題實際上會變得更糟，因爲令牌桶允許突發在時間框架開始時通過。

但是這個例子過於簡化，因爲實際上我們無法在任何給定的時刻完全知道未決請求的數量，而只是一個上限。所以我們必須根據這個數字來節制每一次。

Answer 1

這聽起來像是control theory域中的問題。具體來說，我想PID controller可能工作。

第一個解決問題的方法可能是將記錄數除以下一批的估計時間。這就像一個P控制器 - 只是成比例的。但是你會冒着高估時間的風險，並且建立一些未發表的記錄。因此，請嘗試添加一個詞 - 積分 - 以解釋構建錯誤。

如果批量大小的變化是隨機的，我不確定你甚至需要衍生術語。因此，請嘗試使用PI循環 - 您可能會在突發之間建立一些積壓，但它將由I期處理。

如果這是不可接受的有積壓，那麼解決辦法可能是更加複雜......

Answer 2

如果沒有其他約束條件，您應該做的是找出發送附加請求的最大數據速率，並根據此限制處理速度。然後監視發生了什麼。如果能夠快速完成您的所有請求，那就沒有任何傷害。如果它的持續處理水平不夠快，那麼你需要更多的容量。