Неправильно работает анти-флуд в боте телеграм, что делать?

Question

[ch1ps01]

Я придумал простую защиту от флуда в боте тг, работает она следующим образом: создаётся массив listmc, когда человек отправляет любой запрос боту, его айди вносится в массив, сам массив чистится каждую секунду, так вот, когда человек отправляет запрос боту, с помощью count проверяется, сколько раз его айди там засветился и если более 5, то на запрос бот не реагирует.

Выглядит это следующий образом:

global listmc

    if listmc.count(message.from_user.id) <=5:
        #условие, которое выполняется, если всё хорошо и запросов в эту секунду меньше пяти
    #после условия стоит цикл, в котором и просходит постоянная очистка массива
        while True:
        listmc.clear()
        time.sleep(1)

Но всё не работает как задумано, бот обрабатывает первые два сообщения и больше не отвечает на них вовсе, что не так? Заранее спасибо за ответ

Answer 1

[shurshur]

Пока бот выполняет time.sleep, он ниего не делает. Нужно использовать либо треды, либо asyncio (с асинхронным же asyncio.sleep).

Comments

[ch1ps01]

Скорее мой вопрос прозвучит глупо, но как использовать многопоточность в данном случае? Просто когда я с помощью треда запускаю поток с очисткой массива, то сообщения бот перестаёт обрабатывать

[shurshur]

ch1ps01, суть в том, что если не использовать треды, то любые операции выполняются по очереди. Например, если команда /start выполняется 10 секунд, то любой нажавший /start в боте блокирует на 10 секунд любую его деятельность. В частности, второй нажавший /start пользователь будет ждать эти 10 секунд реакции бота.

В приведённом куске кода запускается бесконечный цикл while, который никогда сам не завершится и не вернёт скрипт к выполнению других частей кода.

Решения есть.

Во-первых, можно использовать треды. Тред (thread - нить) - это как будто бы отдельный процесс, но это "недопроцесс", он выполняется в контексте той же программы и имеет доступ ко всей её памяти. Если запустить бесконечный цикл в отдельном треде, то он не будет мешать основному коду программы или другим тредам выполняться. (У Python есть с тредами известная особенность, которую можно и полезно для своего развития погуглить по словам global interpreter lock, но GIL влияет в основном на вычислительные алгоритмы, а боты в основном спят в ожидании событий, на них это практически не влияет).

В результате можно вынести задачу обновления счётчиков в отдельный тред, который будет время от времени их сбрасывать.

Во-вторых, можно использовать асинхронный код. Судь асинхронщины в том, что, хоть и кажется, что там есть какие-то "треды", на самом деле программа выполняется в один поток, но когда этот поток ожидает ввода-вывода, он может переключиться на любую другую задачу, которая ожидание ввода-вывода уже завершила. Например, если у нас веб-сервер примает запросы от слушателей, обращается к базе данных и попутно получает обновления от Телеграма - то у него есть несколько видов ввода-вывода, в ожидании завершения которого он может переключаться между конкретными задачами.

(Дальше будет "в-третьих", но пока побольше про asyncio)

Кроме ввода-вывода, программа может ожидать звершения асинхронных (async def) функций. В чём суть? Если функция описана как async def func, а потом мы сделали x = func(), то программа не будет ждать завершения func() - она продолжит работать дальше. При этом в x будет лежать не готовое значение выполнения функции, а так называемый future result. Его можно как угодно передавать в другие функции, возвращать, собирать future в массивы итд итп. Но когда потребуется реальный результат, нужно будет сделать final_value_of_x = await x, и программа уснёт, пока func() не завершится.

Можно будет делать "псевдотреды": запустить в цикле несколько func(), а потом начать по очереди await на их результаты (для удобства для этого даже есть готовая функция asyncio.gather). Но, в отличие от тредов, тут переключение не может происходить когда угодно. Только в момент ввода-вывода и ожиданий (await) асинхронных функций, а точнее в момент передаи управления циклу событий (event loop).

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

Например, пусть есть такая функция:

async def func():
    for i in range(10):
        time.sleep(1)

Тут нет никаких вводов-выводов, нет явных или неявных обращений к asyncio. Поэтому как только начнётся реальное выполнение этой функции, цикл событий не будет все 10 секунд выполнения функции выполняться. Это, конечно, не дело. Поэтому у asyncio есть свой аналог sleep:

async def func():
    for i in range(10):
        await asyncio.sleep(1)

Функция asyncio.sleep на самом деле не спит, а сразу же возвращает управление циклу событий, позволяя в это время выполнять другие ожидающие задачи (и уж если их нет - тогда уже спать по-настоящему). Когда пройдёт указанное время, цикл событий вернёт выполнение уснувшей функции. В итоге функция будет спать, но программа продолжит выполняться.

Наконец, если вызвать asyncio.sleep(0), то программа спать не будет, но будет принудительное возвращение в цикл событий. Это используют, чтобы куски синхронного кода с долгим выполнением (например, сложные вычисления) могли иногда позволять переключаться программе в другие задачи в цикле событий. Например:

async def func():
    for i in range(10):
        time.sleep(1)
        await asyncio.sleep(0)

Тут не будет хорошего и быстрого переключения в цикл событий, но хотя бы будут окошки между периодами сна в 1 секунду (это пример для иллюстрации, а не для подражания).

Асинхронщина очень популярна для разного рода ботов, сайтов, API-сервисов итд итп, потому что позволет довольно эффективно начать выполнять запрос другого пользователя, пока запрос предыдущего ещё не завершился. Собственно, нагруженные боты могут порой не оень справляться нагрузкой, несмотря даже на наличие свободных ресурсов, и asyncio им в этом помогает.

В-третьих, на самом деле к задаче можно подойти более творчески и вообще отказаться от каких-то там циклов! Дело в том, что реально необязательно очищать счётчики сразу как прошлё оговоренное время. Достаточно очищать их перед очередным использованием. Например, можно список из времени последних 5 сообщений каждого пользователя, а во время проверки антифлуда пробегаться по массиву и из каждого списка удалять все времена старше нужного периода (например, старше минуты). И пусть даже список будет часто содержать какое-то старьё (например, кто-то в полночь написал сообщение, а очистка его случилась в 7 утра, когда первый проснувшийся что-то написал), важно, что мы это количество используем только после очистки и всякое старьё не используем в расчёт.

[ch1ps01]

shurshur, но библиотеку asyncio можно применять лишь в библиотеке aiogram, насколько мне известно? Для телебот она не годится вроде как

[shurshur]

ch1ps01, да, конечно, правда, в последних версиях телебота у него появился асинхронный класс... Но насколько он работает я не интересовался.

[ch1ps01]

shurshur, понял, спасибо за уделённое время