Как ограничить кол-во запросов в секунду в Telegram боте?

Question

[den94ka]

Добрый день.

У меня есть Telegram бот, который выдает бонусы людям. Бонус выдается один раз в сутки. Для того, чтобы получить бонус, нужно нажать на кнопку (неважно, inline или обычную). И вот ушлые люди нажимают на кнопку десятки раз за несколько секунд и получают не один, а несколько бонусов в итоге.

Функция, которая обрабатывает нажатие, выглядит примерно так:

1. Проверить, когда начислялся бонус последний раз
2. Если больше дня назад, то начислить бонус и обновить дату получения

То есть всего 2-3 команды, ошибки в них быть не может, они банальны и я сто раз их проверил.

Если нажимать нормально, то есть хотя бы с паузой в несколько секунд (не долбя кнопку мыши), то функция работает правильно и начисляет только один раз, а в другие разы выводит ошибку (мол бонус уже был получен). А вот если нажать миллион раз (условно) за секунды, то начисление происходит несколько раз (как будто она не успевает обработаться).

Бот написан на PHP. Я думал над записью в базу даты последнего обращения к боту пользователя, но я боюсь, что оно тоже не сработает, как и функция начисления бонуса.
А так как Telegram посылает все запросы со своего API, то ограничить их через настройку сервера не получится.

Comments

[Chupaka]

"Ошибки в них быть не может" после описания самой ошибки звучит, конечно, весело. Где вы данные храните и как обновляете? При нормальной архитектуре приложения не должно быть таких повторных бонусов.

Answer 1

[Boris Köln]

Вам надо не "ограничить кол-во запросов", а изучить, что такое "race condition".

Answer 2

[VadosL]

Тоже замечал такую особенность поведения на ботах, написанных на Питоне. Но там, скорее всего, дело в том, что updater раскидывает обработку входящих апдейтов по потокам, и вот тут то и происходит race condition. Может Вам поискать в этом направлении?

Answer 3

[Артём Иннокентьев]

Ложите ID юзера в Redis и ставьте EX на сутки :)
При получении запроса на бонус проверяйте наличие ID юзера в Redis через EXISTS - если нету, значит не получал в течение суток. Если есть - значит получал в течение суток.

Answer 4

[Mysterion]

Банально можно в сессию добавлять параметр и проверять его наличие.
Перед обработкой нажатия его устанавливать и перед обращением к базе данных проверять.
Проверять, например, текущую дату, дату последнего обращения и вычислять разницу в нужном количестве времени.

Comments

[den94ka]

Я не могу установить сессии для каждого пользователя отдельно, потому что все запросы от пользователей приходят с серверов Telegram

Answer 5

[Иван Шумов]

Возьмите очередь, допустим, RabbitMQ или Kafka. Повесьте на другой конец обработчик отправки и пусть он перед отправкой проверяет сколько сообщений отправил за последнюю секунду. Если лимит исчерпал то кулдаун. Это, конечно, узкое горлышко получится, но для большинства задач должно хватить. Параллелить эту историю не очень надо ибо лимиты там не высокие, но если очень хочется то могу подсказать совсем дикие варианты

Comments

[Иван Шумов]

Iglint, mysql медленно - все в cache (redis, например)

[Иван Шумов]

Iglint, поэтому redis, а не memcached. И не забываем что всегда надо хэндлить ошибки и возвращать в очередь данные, которые нельзя отправить из-за таймаута. Этот механизм блокировки никуда не уйдет

Answer 6

[Олег]

Варианты:

• Реализовать что-то вроде mutex для функции начисления бонуса
  
• Сделать однопоточную очередь или воспользоваться внешней
  
• Сделать задержку в начислениях: по нажатию кнопки делается заявка на начисление, а бонус начисляется потом всем скопом, кто нажимал кнопку
  

Answer 7

[Adamos]

1. Проверить, когда начислялся бонус последний раз
2. Если больше дня назад, то начислить бонус и обновить дату получения

Если бонусы хранятся в базе, то нужно просто собрать эти два действия в один атомарный оператор обновления.

Comments

[Александр Талалаев]

короче говоря делать транзакцию и не парится.

[Adamos]

Александр Талалаев, для одного оператора транзакция не потребуется.
UPDATE ... (записываем бонус и время обновления) ... JOIN ... (таблицы бонусов и обновлений) ... WHERE ... (дата обновления старше суток)