Как реализовать очередь запросов на обычном веб хостинге

129

08 марта 2022, 06:00

У меня есть телеграм-бот, который работает по принципу запрос-ответ.

Но так как в будущем пользователей будет больше - надо создавать очередь. При чем с приоритетом, так как есть сообщения, на которые надо ответить немедленно, а есть автоматические, которые 5-10 секунд могут подождать.

Это так же сделано для того, чтобы не превысить лимит в 30 запросов/секунду.

Следующая проблема - время выполнения скрипта. Связь обрывает на 30 с, в то время как крон может срабатывать только каждую минуту.

Если делать редиректом - запросы следующего крона и текущие могут либо перекриться (бан) либо 5-6 секунд пауза, что так же не хорошо - много потерь.

Вопрос: Можно ли как-то новым кроном остановить старый крон? Или возможно есть нормальная библиотека, предназначена для подобных задач?

Answer 1

Можно завести таблицу в которую писать все что надо отослать боту. Можно с колонкой приоритет. Любой из обработчиков, будь то запрос от клиента или запуск по крону при необходимости что то отправить только добавляет работу в эту таблицу.

Завести вторую, сигнальную таблицу в которой будет лежать ровно 1 запись. Любой обработчик в конце работы (можно после того, как завершит работу с клиентом (на сколько я понимаю средства у php для этого есть)) в транзакции читает сигнальную таблицу с опциями for update skip locked. Если запрос не вернул запись - значит кто то другой ее сейчас держит, а значит работает, ничего больше не делаем, завешаемся. Если запись удалось прочитать, значит в данный момент более никто не пытается ничего отсылать. Читаем таблицу с очередью рассылок в порядке поля приоритета, с нужной скоростью шлем сообщения, удаляем из очереди. Стоит обратить внимание на такие настройки как максимальное время работы скрипта, что бы его сервер не прибил слишком быстро.

И да, конечно это костыль, на случай, что у вас на хостинге невозможно запустить отдельный, постоянно запущенный процесс, который бы выполнял задачи из очереди и в остальное время спал в ожидании работы. (возможно на более приспособленных для таких целей, нежели MySQL, системах вроде брокеров сообщений)