Глубокое погружение в Asyncio через разработку Telegram-бота

Фундамент асинхронности: Event Loop, корутины и нативный синтаксис async/await

Добро пожаловать в курс «Глубокое погружение в Asyncio через разработку Telegram-бота». Мы начинаем наше путешествие не с установки библиотек для ботов, а с фундамента, на котором они стоят. Многие разработчики начинают писать ботов, копируя примеры кода, но сталкиваются с проблемами, как только проект становится чуть сложнее «Hello World». Бот начинает «тупить», зависать или вести себя непредсказуемо.

Причина почти всегда одна: непонимание того, как работает асинхронность в Python. Сегодня мы разберем этот механизм до винтиков, чтобы вы могли писать высокопроизводительные приложения осознанно.

Почему Telegram-ботам нужна асинхронность?

Прежде чем нырять в код, давайте ответим на вопрос «Зачем?». Telegram-бот — это классическое приложение, связанное с вводом-выводом (I/O Bound). Большую часть времени бот не вычисляет сложные математические формулы, а ждет:

* Ждет сообщения от пользователя. * Ждет ответа от API Telegram. * Ждет ответа от базы данных. * Ждет ответа от внешнего сервиса (например, погоды или курса валют).

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

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

Синхронность vs Асинхронность: Аналогия из жизни

Чтобы понять разницу, представим работу кухни в ресторане.

Синхронный подход (Blocking I/O)

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

Итог: Очень медленно, ресурсы простаивают.

Асинхронный подход (Non-blocking I/O)

На кухне тот же один повар (это важно: Python в стандартном режиме использует один поток). Он кладет стейк на сковороду, засекает время и, пока мясо жарится, идет резать салат для другого заказа. В процессе он проверяет стейк, переворачивает его и снова переключается на нарезку овощей или прием нового чека.

Итог: Тот же один человек успевает сделать в разы больше работы за то же время, просто эффективно управляя периодами ожидания.

!Визуальное сравнение эффективности использования времени в синхронном и асинхронном подходах.

Event Loop (Цикл событий)

Сердцем asyncio является Event Loop (Цикл событий). Это бесконечный цикл, который управляет выполнением задач. Можно представить его как менеджера, у которого есть список дел.

Как работает Event Loop:

Он берет задачу из очереди.

Начинает её выполнять.

Если задача говорит: «Мне нужно подождать ответа от сети», Event Loop приостанавливает эту задачу и запоминает её состояние.

Он переходит к следующей задаче в очереди.

Периодически он проверяет: «Пришел ли ответ от сети для первой задачи?». Если да — он возвращается к ней и продолжает выполнение с того места, где остановился.

В Python доступ к циклу событий осуществляется через модуль asyncio.

Корутины (Coroutines)

Если Event Loop — это менеджер, то корутины — это специальные задачи, которые умеют ставить себя на паузу. В Python корутина — это функция, определенная с помощью ключевого слова async def.

Давайте посмотрим на синтаксис.

Обычная функция

При вызове обычной функции код внутри неё выполняется сразу, и мы получаем результат.

Корутина

Обратите внимание! При вызове функции с async def код внутри не выполняется. Вместо этого создается объект корутины. Чтобы код выполнился, эту корутину нужно запланировать в Event Loop.

Нативный синтаксис: async и await

С версии Python 3.5 мы используем ключевые слова async и await. Это сделало асинхронный код похожим на синхронный, что значительно упростило разработку.

Ключевое слово async

Ставится перед объявлением функции. Оно говорит интерпретатору: «Эта функция будет выполняться асинхронно, и её можно приостанавливать».

Ключевое слово await

Используется внутри async-функций. Оно говорит: «Здесь нужно подождать выполнения другой корутины. Пока мы ждем, Event Loop может заняться другими делами».

Важное правило: Использовать await можно только внутри функций, объявленных как async.

Ваш первый асинхронный скрипт

Давайте напишем код, который имитирует работу бота: он «обрабатывает» данные (спит), но делает это асинхронно.

Разберем, что здесь происходит:

asyncio.run(main()): Эта функция создает новый Event Loop, запускает в нем корутину main() и ждет её завершения. Это точка входа.

Внутри main мы встречаем await say_after(1, 'Привет'). Управление передается в say_after.

Внутри say_after встречаем await asyncio.sleep(delay). Это неблокирующий сон. Функция говорит циклу событий: «Разбуди меня через delay секунд». В этот момент управление возвращается в Event Loop.

Главная ловушка новичка: Блокирующий код

Самая частая ошибка при написании ботов — использование блокирующих функций внутри async def. Посмотрите на этот пример:

Если вы используете time.sleep() (или тяжелые вычисления, или синхронные запросы через библиотеку requests) внутри асинхронной функции, вы останавливаете всего повара. Даже если у вас 1000 пользователей ждут ответа, бот полностью зависнет на 5 секунд. В асинхронном мире всегда нужно использовать асинхронные аналоги: asyncio.sleep() вместо time.sleep(), aiohttp вместо requests.

Жизненный цикл корутины

Чтобы лучше понять процесс, давайте визуализируем состояния, через которые проходит корутина.

!Жизненный цикл корутины от создания до завершения.

Created: Вы вызвали func(), объект создан, но не запущен.

Running: Event Loop начал выполнять код корутины.

Suspended: Корутина встретила await и вернула управление циклу.

Running: Ожидание завершилось, цикл возобновил работу корутины.

Finished: Корутина выполнила весь код или выбросила исключение.

Резюме

Сегодня мы заложили первый камень в фундамент вашего будущего бота.

* Асинхронность — это про эффективное ожидание, а не про параллельные вычисления на процессоре. * Event Loop — это диспетчер, который переключает контекст между задачами. * async def — объявляет корутину. * await — приостанавливает выполнение текущей корутины и отдает управление обратно в Event Loop. * Никогда не блокируйте цикл синхронными вызовами вроде time.sleep.

В следующей статье мы научимся запускать несколько задач одновременно, чтобы наш бот мог обрабатывать множество запросов параллельно, используя asyncio.gather и Task.

Инструменты asyncio: управление задачами (Tasks), Gather и примитивы синхронизации

В предыдущей статье мы заложили фундамент: разобрали Event Loop, корутины и ключевые слова async/await. Мы выяснили, что корутина — это всего лишь «план» выполнения, который сам по себе ничего не делает, пока его не запланируют.

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

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

Задача (Task): Единица планирования

Корутина (async def) — это просто функция, которая может быть приостановлена. Чтобы Event Loop начал её выполнять, корутину нужно превратить в Задачу (Task).

asyncio.Task — это обертка над корутиной. Когда вы создаете задачу, вы говорите циклу событий: «Возьми эту корутину и выполняй её при любой возможности, пока я занимаюсь другими делами».

Создание задачи

Для создания задачи используется функция asyncio.create_task().

Сравним два подхода:

1. Последовательный (как мы делали раньше):

2. Конкурентный (с использованием Tasks):

!Визуализация конкурентного выполнения: задачи ожидают ввода-вывода одновременно, сокращая общее время выполнения.

Важно: create_task нужно вызывать внутри async-функции, когда цикл событий уже запущен.

Группировка задач: asyncio.gather

Представьте, что вашему боту нужно получить данные о пользователе из трех разных источников: базы данных, кэша Redis и внешнего API. Запускать их по очереди — медленно. Создавать переменную для каждой задачи (task1, task2, task3...) — неудобно.

Для этого существует asyncio.gather. Эта функция принимает список корутин (или задач), запускает их одновременно и ждет завершения всех.

Обработка ошибок в gather

По умолчанию, если одна из корутин внутри gather упадет с ошибкой, исключение сразу же всплывет в main, а остальные задачи будут отменены (или продолжат работу в фоне, но их результат будет потерян, в зависимости от версии Python и настроек).

Чтобы этого избежать, используйте параметр return_exceptions=True:

Тайм-ауты: wait_for

В мире сетей никто не гарантирует мгновенный ответ. Если внешний сервис завис, ваш бот не должен ждать его вечно. Для этого используется asyncio.wait_for.

Когда срабатывает тайм-аут, задача автоматически отменяется (Cancelled).

Примитивы синхронизации

Многие новички думают: «Раз у нас нет потоков (Threads) и GIL нам не мешает, значит, нам не нужны блокировки». Это опасное заблуждение.

Хотя asyncio выполняет код в одном потоке, переключение контекста происходит в точках await. Если у вас есть общий ресурс (например, глобальная переменная или соединение с БД), и вы делаете await в процессе его изменения, другая задача может вклиниться и испортить данные.

Lock (Блокировка)

Используется для обеспечения монопольного доступа к ресурсу. Представьте, что два пользователя одновременно нажали кнопку «Купить», а товар на складе всего один.

Semaphore (Семафор)

Это, пожалуй, самый полезный примитив для Telegram-ботов. Семафор ограничивает количество одновременных выполнений.

Зачем это нужно? Telegram API имеет жесткие лимиты (например, не более 30 сообщений в секунду). Если вы попытаетесь отправить рассылку 10 000 пользователям через asyncio.gather без ограничений, вы получите ошибку 429 (Too Many Requests) и бан.

Семафор работает как вышибала в клубе: он пускает внутрь только определенное количество людей одновременно.

!Семафор ограничивает количество задач, выполняемых одновременно, предотвращая перегрузку внешних систем.

Event (Событие)

Позволяет одной задаче сигнализировать другим, что что-то произошло. Это простой механизм «Светофор»: пока красный — все стоят и ждут, загорелся зеленый — все поехали.

Резюме

Теперь в вашем арсенале есть мощные инструменты:

asyncio.create_task — запускает корутины «в фоне», позволяя выполнять код конкурентно.

asyncio.gather — собирает результаты множества задач, запущенных параллельно.

asyncio.wait_for — защищает бота от вечных зависаний при работе с сетью.

Lock — защищает данные от гонки состояний (Race Conditions).

Semaphore — контролирует нагрузку на API, спасая от банов.

В следующей статье мы применим эти знания на практике и разберем работу с библиотекой aiohttp, чтобы наш бот мог взаимодействовать с внешним миром.

Создание асинхронного бота: архитектура на базе Aiogram и обработка событий

Мы прошли долгий путь, разбирая внутренности asyncio. Мы знаем, что такое Event Loop, как работают корутины и почему нельзя блокировать поток выполнения. Теперь пришло время применить эти знания на практике и построить что-то осязаемое.

В этой статье мы начнем разработку Telegram-бота, используя библиотеку Aiogram 3.x. Почему именно Aiogram? Потому что это полностью асинхронный фреймворк, написанный с учетом всех особенностей asyncio, которые мы изучали ранее. Он быстрый, мощный и идеально подходит для демонстрации конкурентного выполнения задач.

Архитектура Aiogram: Взгляд изнутри

Многие новички воспринимают бота как черный ящик: «Я написал функцию, она сработала». Но чтобы писать сложные системы, нужно понимать поток данных.

Глобально работу бота можно разделить на два компонента:

Bot — это клиент API Telegram. Его задача — отправлять запросы на серверы Telegram (отправить сообщение, скачать файл, забанить пользователя). Это «руки» вашей программы.

Dispatcher (Диспетчер) — это мозг. Он получает входящие события (Updates) от Telegram, фильтрует их и решает, какую функцию (хендлер) запустить для обработки.

!Путь обновления (Update) от серверов Telegram через слои фильтров и мидлварей до вашего кода.

Polling vs Webhook

Как Диспетчер узнает о новых сообщениях? Есть два пути:

* Long Polling (Опрос): Бот сам постоянно спрашивает у Telegram: «Есть что-то новое?». Если нет — соединение висит открытым некоторое время (асинхронно ждет), затем закрывается и открывается снова. Это идеально для разработки. * Webhook: Telegram сам стучится на ваш сервер, когда происходит событие. Это стандарт для продакшена, но требует наличия публичного IP и SSL-сертификата.

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

Установка и первая асинхронная точка входа

Установим библиотеку:

Вспомните нашу первую статью про asyncio.run(). В Aiogram мы используем ровно тот же паттерн. Бот не может работать в глобальной области видимости, он должен быть запущен внутри асинхронной функции.

Создадим файл main.py:

Разбор полетов

async def cmd_start: Все хендлеры в Aiogram — это корутины. Диспетчер создает для каждого входящего сообщения отдельную Task (задачу). Это значит, что если 100 человек одновременно напишут /start, бот обработает их конкурентно, не блокируясь.

await message.answer(...): Отправка сообщения — это I/O операция (сетевой запрос). Мы используем await, чтобы отдать управление Event Loop'у, пока ждем подтверждения от серверов Telegram.

dp.start_polling(bot): Под капотом эта функция запускает бесконечный цикл while True, в котором делает запросы getUpdates.

Система событий и фильтры

Диспетчер должен понять, какую функцию вызвать. Для этого используются Фильтры.

В Aiogram 3 появилась мощная система «Магических фильтров» (Magic Filter), обозначаемая буквой F.

Фильтры проверяются последовательно сверху вниз. Как только подходящий фильтр найден, выполнение передается в хендлер, и поиск прекращается.

Middleware: Слой перехвата

Это одна из самых важных концепций архитектуры. Middleware (Мидлварь) — это код, который срабатывает ДО того, как сообщение попадет в хендлер, и ПОСЛЕ того, как хендлер завершит работу.

Зачем это нужно? * Логирование всех запросов. * Проверка подписки на канал (бан пользователя до обработки команды). * Передача соединения с базой данных в хендлер.

Давайте напишем простую мидлварь, которая замеряет время обработки запроса. Это отличная практика для понимания асинхронности.

Обратите внимание на await handler(event, data). Это классический паттерн «обертки». Мы запускаем вложенную корутину (наш хендлер), ждем её завершения, а затем выполняем остальной код.

Главная ошибка: Блокировка в хендлере

В первой статье мы говорили про time.sleep(). В контексте бота это смертный грех. Если вы напишете так:

...то на 10 секунд ваш бот перестанет отвечать всем пользователям. Event Loop будет заблокирован. Правильный подход — использовать асинхронные аналоги или выносить тяжелые вычисления в отдельные потоки/процессы (об этом поговорим в будущих статьях).

Правильный вариант ожидания:

Структурирование проекта

Писать весь код в main.py можно только для примеров. В реальном проекте архитектура должна быть модульной. Рекомендуемая структура:

* bot.py — точка входа (main функция). * handlers/ — папка с хендлерами (отдельно для админов, отдельно для пользователей). * keyboards/ — файлы с кнопками и клавиатурами. * middlewares/ — ваши мидлвари. * database/ — работа с БД.

Для подключения хендлеров из других файлов в Aiogram используется Router (Роутер). Роутер — это как мини-диспетчер, который отвечает за свою часть логики.

Пример в handlers/user.py:

А в main.py мы просто подключаем этот роутер:

Резюме

Сегодня мы создали скелет нашего бота.

Aiogram полностью построен на asyncio и требует понимания await.

Dispatcher управляет потоком событий, пропуская их через Middlewares и Filters.

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

Никогда не используйте блокирующие функции внутри хендлеров.

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

Работа с внешними ресурсами: aiohttp для API и асинхронные драйверы баз данных

В предыдущих статьях мы построили архитектурный скелет нашего Telegram-бота на базе Aiogram и разобрались, как работает Event Loop. Наш бот уже умеет отвечать на команды и обрабатывать текст. Но пока он живет в вакууме: он не знает, какая погода на улице, какой курс биткоина и не помнит, кто писал ему пять минут назад.

Чтобы бот стал полезным, ему нужно общаться с внешним миром: запрашивать данные у сторонних API и сохранять информацию в базу данных. В этой статье мы разберем, как делать это правильно, не блокируя цикл событий, и почему привычные библиотеки здесь не работают.

Почему привычные инструменты убивают бота?

Многие Python-разработчики привыкли использовать библиотеку requests для HTTP-запросов и psycopg2 для PostgreSQL. Это отличные инструменты, но они синхронные (блокирующие).

Вспомните аналогию с поваром. Если вы используете requests.get(), ваш повар (Event Loop) отправляет заказ поставщику продуктов и стоит у телефона, пока поставщик не ответит. Если сеть медленная и ответ идет 2 секунды, ваш бот полностью зависает на 2 секунды. Никто другой не получит ответ.

Для асинхронного бота нам нужны инструменты, которые позволяют «сделать заказ и повесить трубку», чтобы продолжить работу, пока данные идут к нам.

aiohttp: Асинхронный HTTP-клиент

Стандартом де-факто для асинхронных HTTP-запросов в Python является библиотека aiohttp. Она работает поверх asyncio и позволяет выполнять тысячи запросов конкурентно.

Установка

Основы использования

Главное отличие от requests — необходимость создания сессии. В requests вы часто делаете просто requests.get(). В aiohttp мы работаем через ClientSession.

Обратите внимание на двойной async with. Первый открывает сессию, второй делает конкретный запрос. Метод response.json() также является корутиной (await), потому что чтение данных из сетевого сокета — это тоже операция ввода-вывода.

Правило одной сессии

Одна из самых частых ошибок новичков — создание новой сессии (ClientSession) внутри каждого хендлера бота.

Плохо:

Создание сессии — дорогая операция (выделение памяти, настройка пула соединений). Правильный подход — создать одну сессию при старте бота и переиспользовать её. Мы научимся прокидывать её в хендлеры чуть позже.

Асинхронные базы данных

С базами данных ситуация аналогичная. Нам нужен драйвер, который умеет «ждать» ответ от базы, не блокируя поток. Для PostgreSQL самым быстрым и популярным драйвером является asyncpg. Однако писать «сырые» SQL-запросы не всегда удобно, поэтому мы будем использовать SQLAlchemy 2.0 — мощную ORM, которая полностью поддерживает асинхронность.

Установка

Архитектура подключения

В асинхронном SQLAlchemy есть два ключевых понятия:

AsyncEngine — фабрика подключений. Она управляет пулом соединений.

AsyncSession — сессия базы данных, через которую мы выполняем запросы.

!Пул соединений позволяет Event Loop эффективно управлять множеством запросов к базе данных, не создавая новое подключение каждый раз.

Настройка Engine и модели

Создадим файл database.py:

Выполнение запросов

Теперь посмотрим, как записывать и читать данные. В SQLAlchemy 2.0 используется новый синтаксис запросов.

Обратите внимание: все операции, требующие обращения к БД (execute, commit, scalar), теперь требуют await.

Интеграция в Aiogram: Dependency Injection

Теперь у нас есть aiohttp сессия и фабрика сессий БД. Как передать их в хендлер? Использовать глобальные переменные — плохой тон, это усложняет тестирование и поддержку.

Лучший способ — использовать Middleware для внедрения зависимостей. Мы создадим мидлварь, которая будет открывать сессию БД перед выполнением хендлера и закрывать её после.

Создаем DbSessionMiddleware

Подключаем все в main.py

Теперь соберем все вместе в точке входа.

Благодаря магии Aiogram, если вы укажете аргумент session в функции хендлера, библиотека автоматически возьмет его из словаря data, куда мы положили его в мидлвари.

Пул соединений (Connection Pool)

Почему мы используем create_async_engine, а не просто открываем соединение? Потому что создание соединения с базой данных — это очень медленный процесс (TCP handshake, аутентификация).

Пул соединений — это набор уже открытых и готовых к работе соединений. Когда вашему боту нужно сделать запрос:

Он берет свободное соединение из пула.

Быстро выполняет запрос.

Возвращает соединение обратно в пул, не закрывая его.

Это позволяет обрабатывать тысячи запросов в секунду, имея всего 10-20 открытых соединений с базой.

Резюме

Сегодня мы сделали нашего бота по-настоящему мощным:

* Мы отказались от requests в пользу aiohttp, чтобы не блокировать Event Loop сетевыми ожиданиями. * Мы подключили PostgreSQL через асинхронный драйвер и SQLAlchemy. * Мы узнали про Пул соединений, который экономит ресурсы и ускоряет работу. * Мы научились прокидывать сессию базы данных прямо в хендлер через Middleware.

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

Best Practices: предотвращение блокировок, graceful shutdown и масштабирование бота

Поздравляю! Вы прошли путь от понимания того, что такое Event Loop, до написания бота, работающего с базой данных через пул соединений. Ваш бот функционален, но готов ли он к реальному миру?

В продакшене (реальной эксплуатации) возникают проблемы, о которых не пишут в «Hello World» туториалах:

* Что будет, если боту нужно обработать тяжелое изображение, и он зависнет? * Что произойдет с данными пользователей, если сервер перезагрузится? * Как запустить бота на нескольких серверах, если нагрузка вырастет?

В этой финальной статье курса мы превратим ваш проект в надежную, отказоустойчивую систему.

Враг №1: Блокировка Event Loop

Мы уже говорили, что time.sleep() — это зло. Но блокировки могут быть неочевидными. Любая синхронная библиотека, работающая с вводом-выводом (например, стандартный модуль zipfile для архивации или Pillow для обработки фото), остановит цикл событий.

Если ваш бот должен сжать 10 фотографий в архив, и это займет 5 секунд, то на эти 5 секунд бот «умрет» для остальных пользователей.

Решение для I/O Bound задач: Потоки

Если у вас есть синхронная функция, которая ждет ввода-вывода (например, работа с файловой системой или синхронный API, у которого нет асинхронного аналога), используйте asyncio.to_thread. Эта функция запускает код в отдельном потоке, не блокируя основной цикл.

Решение для CPU Bound задач: Процессы

Если ваш бот майнит криптовалюту, обучает нейросеть или накладывает фильтры на 4K изображения, asyncio.to_thread не поможет. В Python существует GIL (Global Interpreter Lock), который не позволяет потокам использовать несколько ядер процессора одновременно.

Для тяжелых вычислений нужно использовать ProcessPoolExecutor. Это создает отдельный процесс операционной системы.

!Разделение задач: Event Loop управляет легкими задачами, потоки — синхронным вводом-выводом, процессы — тяжелыми вычислениями.

Graceful Shutdown (Корректное завершение)

Представьте, что вы обновляете код бота и перезапускаете его. В этот момент:

Бот обрабатывал 50 сообщений.

Было открыто 10 соединений с базой данных.

Aiohttp сессия была активна.

Если просто «убить» процесс (SIGTERM/SIGINT), соединения могут остаться «висячими» на стороне базы данных, а пользователи не получат ответы. Graceful Shutdown — это процедура, при которой бот перестает принимать новые задачи, доделывает текущие и аккуратно закрывает ресурсы.

В Aiogram 3 это реализуется через регистрацию функций на событие shutdown.

Aiogram сам позаботится о том, чтобы дождаться завершения текущих хендлеров (в разумных пределах), прежде чем вызвать on_shutdown.

Обработка ошибок и Retry-политика

Сеть ненадежна. Telegram API может вернуть 500-ю ошибку, или база данных может временно отвалиться. Если ваш бот падает при любой ошибке — это плохой бот.

Экспоненциальная задержка (Exponential Backoff)

Если внешний сервис недоступен, нет смысла долбить его запросами каждую миллисекунду. Нужно ждать, постепенно увеличивая интервал. Формула задержки выглядит так:

Где — время ожидания на -й попытке, — базовый интервал (например, 1 секунда), а — номер попытки (начиная с 0). Это позволяет снизить нагрузку на упавший сервис.

Пример реализации декоратора для повторных попыток:

Масштабирование: От монолита к микросервисам

Когда ваш бот наберет 100 000 пользователей, один сервер может перестать справляться. Вы захотите запустить 5 копий бота параллельно.

Проблема FSM (Машины состояний)

По умолчанию Aiogram хранит состояния пользователей (например, то, что пользователь сейчас находится на шаге 2 из 5 в опросе) в оперативной памяти (MemoryStorage).

Если вы запустите два экземпляра бота:

Пользователь пишет сообщение, оно попадает на Сервер А. Бот запоминает состояние.

Пользователь пишет следующее сообщение, балансировщик отправляет его на Сервер Б.

Сервер Б ничего не знает о состоянии пользователя и выдает ошибку или сбрасывает диалог.

Решение: Redis

Чтобы масштабироваться, состояние нужно вынести во внешнее хранилище. Идеальный кандидат — Redis. Это сверхбыстрая база данных key-value, работающая в оперативной памяти.

Установка:

Подключение в коде:

Теперь, сколько бы копий бота вы ни запустили, все они будут обращаться к одному Redis за состоянием пользователя.

!Горизонтальное масштабирование: несколько экземпляров бота обрабатывают запросы параллельно, используя общий Redis для синхронизации состояний.

Webhooks vs Polling в продакшене

В курсе мы использовали Polling (бот сам спрашивает обновления). Это нормально для малых и средних ботов. Однако для высоких нагрузок рекомендуется использовать Webhooks.

Почему Webhooks лучше для масштабирования?

Меньше задержка: Telegram сразу присылает запрос, как только случилось событие.

Экономия ресурсов: Не нужно тратить CPU на пустые опросы серверов Telegram.

Балансировка: Вы можете поставить Nginx перед вашими ботами, и он будет распределять входящие вебхуки между запущенными инстансами.

Итоги курса

Мы прошли большой путь. Давайте оглянемся назад:

Мы поняли, что асинхронность — это не параллелизм, а эффективное управление ожиданием.

Мы научились использовать Tasks и Gather для конкурентного выполнения.

Мы освоили Aiogram и его систему фильтров и мидлварей.

Мы подключили PostgreSQL и Redis, используя асинхронные драйверы.

Мы узнали, как защитить бота от блокировок и подготовить его к нагрузкам.

Теперь у вас есть полный набор инструментов для создания профессиональных, быстрых и надежных Telegram-ботов. Дальше — только практика. Удачи в разработке!