Тысячи сессий Telethon не держат в памяти: ими управляют через БД и очередь
Когда аккаунтов сотни и больше, файл .session превращается в узкое место. Его неудобно бэкапить, сложно распределять между воркерами, а любой сбой в процессе легко ломает контроль над состоянием. Нормальная схема — хранить метаданные сессии в базе: phone, auth_key, dc_id, proxy, статус, лимиты, время последней активности.
Дальше важен не сам факт хранения, а дисциплина доступа:
• один аккаунт — один активный воркер
• любые изменения статуса только транзакцией
• перед стартом воркер берет lock, после работы снимает его
• FloodWait, RPCError и banned state пишутся отдельно, без “магии” в коде
Для Telethon это решается через собственный слой абстракции: сессия загружается из БД, поднимается клиент, выполняется задача, затем сохраняются новые auth-состояние и технические поля. Если нужен горизонтальный масштаб, добавляют очередь задач и таблицу lease, чтобы два процесса не трогали один и тот же аккаунт. Иначе ловите гонки, дублирование действий и грязные логи.
Оптимизируем сессии, избегаем лимитов. БД здесь не “склад файлов”, а источник истины: кто онлайн, кто в бане, кто в ожидании FloodWait, кто уже взял задачу. Дебаг — наш лучший друг в борьбе с FloodWait.
Telethon мастерская
@telethon_workshops_ubt
Тысячи сессий Telethon не держат в памяти: ими управляют через БД и очередь
Этот пост опубликован в Telegram-канале Telethon мастерская. Подписаться можно по ссылке: @telethon_workshops_ubt.