Принцип работы

Запуск

Make:

make go-run #через локальный go
make docker-run #через docker-compose

Вручную через docker-compose:

HTTP_PORT=9000 POSTGRESQL_PORT=5432 docker-compose up --build

Конфигурация

Переменная	Описание	Значение по умолчанию
DB_DSN	Адрес базы данных, in-memory:// либо DSN	Нет
RATE_LIMIT_STRATEGY	realtime	linear - все запросы будут выполнены равномерно с одинаковым rate ожидания между запросами, даже если интервал времени уже прошел. realtime - все запросы будут выполняться сразу же, пока не упрутся в лимит.
RATE_LIMIT_REQUESTS_LIMIT_PER_INTERVAL	1s	Формат time.Duration. Указывается интервал для лимитированного кол-ва запросов.
RATE_LIMIT_REQUESTS_INTERVAL	100	Максимальное кол-во запросов за указанный интервал.
QUEUE_INTERVAL_CHECKING_NEW_REQUESTS	1s	Формат time.Duration. Указывается интервал опроса базы данных очередью, обрабатывающую поступающие запросы.
QUEUE_WORKERS_SIZE	runtime.GOMAXPROCS(0)	Кол-во горутин, которые будут запущены для разбора очереди из бд

Стратегии rate-limiter-ов

1. Стратегия realtime

При данной стратегии запускается time.Ticker который автоматически "добавляет в корзину свободные токены". Данная стратегия нужна в случае если инстанс приложения запускается в единственном экземпляре и скорость выполнения запросов имеет важную роль и для внешнего сервиса не критичен резкий всплеск максимального кол-ва запросов за указанный интервал.

2. Стратегия linear

При выборе данной стратегии используется time/rate пакет от Golang. Принцип его работы следующий: высчитывать из интервала и кол-ва допустимых запросов некий rate, чтобы между попытками выдерживать эту паузу. Данная стратегия может работать исключительно только при единственном экземпляре инстанса. Из прочих минусов - ненужные ожидания между попытками, даже если уже и так прошло несколько минут. Но при этом если взрывной рост запросов под завязку для внешнего сервиса критичен - это то, что нужно.

3. Стратегия database

Данная стратегия использует созданную функцию take_token в PostgreSQL, которая загружается миграцией. Она будет работать при запуске нескольких инстансов приложения, а также не будет делать интервалы между попытками.

Пограничные кейсы и нештатные ситуации

Когда запускается инстанс приложения, генерируется некий ID этого инстанса для идентификации очереди. Каждый инстанс будет пинговаться с указанным интервалом в Env переменной QUEUE_HEALTH_CHECK_INTERVAL, по умолчанию это 15s. В процессе работы инстанс резервирует из очереди запросов за собой пачку request-ов для дальнейшей их обработки. Если он не успевает их разобрать за какое-то время, а операционная система выслала сигнал завершаться - резерв снимается. Если инстанс завершается нештатно, без передачи сигналов от операционной системы, когда уже зарезервировал за собой несколько задач, эти задачи возьмет на себя другой инстанс, увидя, что первый инстанс превысил время health check ping >= QUEUE_HEALTH_CHECK_INTERVAL * 1.5.