Идея и реализация Token Bucket (3)

Java алгоритм

существуетпервый раз,Статья 2В статье представлен принцип работы алгоритма корзины токенов Guava и ограничитель тока SmoothBursty, производящий токены с фиксированной скоростью. Но в реальной среде, если вы хотите снова вызвать систему на начальном этапе или через какой-то промежуток времени, происходит процесс прогрева, то есть скорость производства токенов при запуске медленнее, а затем постепенно ускоряется. , и достигает нормального уровня после стадии прогрева.Производительность подобна фазе запуска автомобиля, начиная с 1-й передачи и постепенно увеличивая, 2-ю, 3-ю и самую быструю 6-ю передачу.

RateLimiter.java обеспечивает реализацию этого алгоритма.

Рисунок 1

Класс реализации, который он возвращает, представляет собой встроенный класс SmoothWarmingUp в классе SmoothRateLimiter.java.

Каков принцип реализации SmoothWarmingUp, давайте посмотрим на рисунок ниже.

Рисунок II

Ось X представляет количество токенов, хранящихся в корзине токенов, а ось Y — скорость текущего ограничения.Единицей является скорость генерации одного токена. X * Y представляет собой прямоугольную область, ограниченную осью координат, которая равна (скорость производства токена) * (количество токенов), что это значит? Да, это время для производства n жетонов, которое рассчитывается с использованием баллов. Трапециевидная область справа представляет собой общее время производства жетонов в зоне прогрева, а прямоугольная область внизу слева представляет время производства жетонов в стабильный период. Проиллюстрируем на конкретном примере.

Рисунок 3

Здесь 2,0 означает количество запросов в секунду, 4000 означает, что прогрев составляет 4 секунды, 3,0 означает, что coldFactor — это коэффициент охлаждения, поэтому

стабильный интервал = 1/QPS = 1/2 = 0,5 секунды = 500 миллисекунд,

coldinterval=coldFactor*стабильный интервал=1500 мс.

Задайте параметры корзины токенов через функцию инициализации:

Рисунок 4

где для thresholdPermits установлено значение

thresholdPermits = 0.5 *warmupPeriodMicros / 

stableIntervalMicros;

То есть 0,5*4000/500=4,

maxPermits=thresholdPermits + 

2.0 * warmupPeriodMicros / 

(stableIntervalMicros +coldIntervalMicros);

maxPermits также является основанием трапеции справа, а WarmupPeriodMicros — это площадь трапеции, поэтому maxPermits выводится с использованием формулы площади трапеции. В то время как наклон представляет собой наклон косой черты, это поле используется для расчета времени производства маркера в области прогрева. В начальном состоянии ведро токенов находится в состоянии охлаждения, то есть скорость производства ведра токенов в начале самая медленная, а storePermits равен maxpermits.

Рисунок 5

Когда мы получим токен от вышеуказанного ограничителя,

Рисунок 6

Выходное событие: «R0.00, R1.38, R1.13, R0.88, R0.63, R0.50, R0.50, R0.50» (Примечание: см. com.google.common.util . метод testWarmUp в concurrent.RateLimiterTest).

Из предыдущей статьи мы знаем, что R представляет собой время задержки, например: R0,00 представляет получение токена без задержки, а R1,38 представляет собой ожидание 1,38 секунды для получения токена.

i=0, первый цикл, по первой статье мы знаем, что ratelimiter — это идея живой пищи, потому что начальное значение nextFreeTicketMicros равно 0, и текущие часы также равны 0, поэтому задержка равна 0 , а время производства токена используется для следующего потребления Компенсация времени, то есть площадь первой маленькой трапеции справа.

Рисунок 7

availablePermitsAboveThreshold – это количество сохраненных токенов, превышающее пороговое значение. В первом цикле

availablePermitsAboveThreshold=maxpermits-threshold=4,

AllowsAboveThresholdToTake — это количество заявленных токенов, равное 1.

частные двойные разрешенияToTime(двойные разрешения) используются для вычисления высоты верхнего и нижнего днищ маленькой трапеции, здесь разрешенияToTime(availablePermitsAboveThreshold) получают высоту нижнего основания, AllowsToTime(availablePermitsAboveThreshold -

разрешенияAboveThresholdToTake) — это высота верхнего низа, поэтому

Метод StoredPermitsToWaitTime предназначен для расчета времени производства токенов.Когда количество хранимых токенов больше порогового значения, то есть availablePermitsAboveThreshold > 0.0, вычисляется площадь маленькой трапеции справа.Результат расчета здесь 1,38 секунды.В противном случае вычисляется площадь маленького прямоугольника слева.

При i=1, 2, 3 повторяем процесс второго цикла. Времена задержки соответствуют площадям 2-й, 3-й и 4-й малых трапеций, а площади уменьшаются и составляют 1,13, 0,88 и 0,63 соответственно.

При i=4, поскольку было израсходовано 4 токена, общая продолжительность 1,38, 1,13, 0,88 и 0,63 составляет в сумме 4,02 (из-за ошибок округления значение не совсем равно 4), период прогрева прошел, так он входит в стабильный период, площадь маленького прямоугольника слева микрос += (длинный) (stableIntervalMicros * AllowsToTake), высота стабильный IntervalMicros, 0,5 секунды, а AllowsToTake равен 1, то есть производство время 0,5 секунды.

i=5, 6, 7, 8 повторить описанный выше процесс. Время производства последнего цикла должно быть возмещено последующими заявителями.

На данный момент представлен исходный код ограничителя тока ratelimiter в режиме прогрева.Если у вас есть какие-либо вопросы, вы можете подписаться на официальный аккаунт и ответить.

Статьи по Теме:

Анализ исходного кода реализации алгоритма корзины токенов Guava (1)

Анализ исходного кода реализации алгоритма корзины токенов Guava (2)