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:https:// либо 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) |
Кол-во горутин, которые будут запущены для разбора очереди из бд |
При данной стратегии запускается time.Ticker который автоматически "добавляет в корзину свободные токены". Данная стратегия нужна в случае если инстанс приложения запускается в единственном экземпляре и скорость выполнения запросов имеет важную роль и для внешнего сервиса не критичен резкий всплеск максимального кол-ва запросов за указанный интервал.
При выборе данной стратегии используется time/rate пакет от Golang. Принцип его работы следующий: высчитывать из интервала и кол-ва допустимых запросов некий rate, чтобы между попытками выдерживать эту паузу. Данная стратегия может работать исключительно только при единственном экземпляре инстанса. Из прочих минусов - ненужные ожидания между попытками, даже если уже и так прошло несколько минут. Но при этом если взрывной рост запросов под завязку для внешнего сервиса критичен - это то, что нужно.
Данная стратегия использует созданную функцию take_token в PostgreSQL, которая загружается миграцией. Она будет работать при запуске нескольких инстансов приложения, а также не будет делать интервалы между попытками.
Когда запускается инстанс приложения, генерируется некий ID этого инстанса для идентификации очереди.
Каждый инстанс будет пинговаться с указанным интервалом в Env переменной QUEUE_HEALTH_CHECK_INTERVAL
, по умолчанию это 15s
.
В процессе работы инстанс резервирует из очереди запросов за собой пачку request-ов для дальнейшей их обработки.
Если он не успевает их разобрать за какое-то время, а операционная система выслала сигнал завершаться - резерв снимается.
Если инстанс завершается нештатно, без передачи сигналов от операционной системы, когда уже зарезервировал за собой несколько задач, эти задачи возьмет на себя другой инстанс, увидя, что первый инстанс превысил время health check ping >= QUEUE_HEALTH_CHECK_INTERVAL * 1.5
.