Я пытаюсь распространить данные, полученные в пакетном режиме. Это означает, что у меня есть данные, полученные другим приложением большими пакетами. Для каждого ввода данных мне нужно сделать несколько дополнительных запросов на каком-то сервере, на котором я должен ограничить трафик. Поэтому я пытаюсь распределить запросы за то время, которое у меня есть до следующего пакета данных.
В настоящее время я использую token-bucket для распространения данных. Однако, поскольку данные, которые я получаю, уже имеют плохую форму, я все еще либо заполняю очередь ожидающего запроса, либо получаю всплески всякий раз, когда поступают пакеты. Так что этот алгоритм, похоже, не выполняет нужное мне формирование.
Какие еще алгоритмы доступны для ограничения запросов? Я знаю, что у меня бывают периоды высокой нагрузки и периоды низкой нагрузки, поэтому оба приложения должны хорошо обрабатываться.
Я не уверен, смог ли я действительно объяснить проблему, которая у меня сейчас есть. Если вам нужны какие-либо разъяснения, просто дайте мне знать.
EDIT
Я попытаюсь прояснить проблему еще и объяснить, почему простой ограничитель скорости не работает.
Проблема заключается в прерывистом характере трафика и том факте, что пакеты имеют разные размеры в разное время. То, что в основном является постоянным, - это задержка между каждым всплеском. Таким образом, мы получаем кучу записей данных для обработки, и нам нужно распределить их как можно более равномерно, прежде чем поступит следующая пачка. Однако мы не уверены на 100%, когда появится следующая пачка, просто приблизительно, поэтому просто divide time by number of records не работает должным образом.
Ограничение скорости не работает, поскольку распространение данных таким образом недостаточно. Если мы близки к насыщению ставки, все в порядке, и мы распределяемся равномерно (хотя это не должно случаться часто). Если мы ниже порога, спрэд становится намного хуже.
Я приведу пример, чтобы прояснить эту проблему:
Допустим, мы ограничиваем наш трафик до 10 запросов в секунду, а новые данные поступают примерно каждые 10 секунд.
Когда мы получим 100 записей в начале периода времени, мы будем запрашивать 10 записей каждую секунду, и у нас будет идеальный равномерный спред. Однако если мы получим только 15 записей, у нас будет одна секунда, когда мы запрашиваем 10 записей, одна секунда, когда мы запрашиваем 5 записей, и 8 секунд, когда мы запрашиваем 0 записей, поэтому у нас очень неравные уровни трафика с течением времени. Вместо этого было бы лучше, если бы мы просто запрашивали 1,5 записи каждую секунду. Однако установка этой скорости также создаст проблемы, поскольку новые данные могут поступать раньше, поэтому у нас нет полных 10 секунд и 1,5 запросов будет недостаточно. Если мы используем блок токенов, проблема на самом деле становится еще хуже, потому что блоки маркеров позволяют пакетам проходить в начале таймфрейма.
Однако этот пример упрощен, потому что на самом деле мы не можем полностью определить количество ожидающих запросов в любой данный момент, но только верхний предел. Таким образом, нам придется каждый раз ограничивать газ, основываясь на этом числе.