Масштабування IV: дотримання лімітів

Telegram обмежує кількість повідомлень, які ваш бот може надсилати щосекунди. Це означає, що будь-який запит до API, який ви виконуєте, може призвести до помилки з кодом статусу 429 (Too Many Requests - Забагато запитів) і заголовком retry_after, як зазначено тут. Це може статися в будь-який момент.

Існує лише один правильний спосіб впоратися з такими ситуаціями:

1. Зачекайте вказану кількість секунд.
2. Повторіть запит.

На щастя, для цього існує плагін.

Цей плагін дуже простий. Він буквально просто чекає й повторює спроби. Однак його використання має серйозні наслідки: будь-який запит може сповільнюватися. Коли ви запускаєте свого бота на вебхуках, це означає, що технічно ви повинні використовувати чергу незалежно від того, що ви робите, або що вам потрібно налаштувати плагін auto-retry так, щоб він ніколи не займав багато часу, але тоді ваш бот може пропустити виконання деяких запитів.

Які саме ліміти існують

Вони не визначені.

Змиріться з цим.

У нас є кілька хороших ідей щодо того, скільки запитів ви можете виконати, але точні цифри невідомі. Якщо хтось скаже вам реальні ліміти, він не дуже добре обізнаний. Ліміти - це не просто жорсткі пороги, які ви можете дізнатися, експериментуючи з Bot API. Це скоріше гнучкі обмеження, які змінюються залежно від точного корисного навантаження запитів вашого бота, кількості користувачів та інших факторів, не всі з яких відомі.

Ось кілька хибних уявлень і помилкових припущень про ліміти:

• Мій бот занадто новий, щоб отримувати помилки перевищування кількості запитів.
• Мій бот не отримує достатньо трафіку, щоб отримувати помилки перевищування кількості запитів.
• Ця функція мого бота використовується недостатньо, щоб отримувати помилки перевищування кількості запитів.
• Мій бот залишає достатньо часу між викликами API, щоб не отримувати помилок перевищування кількості запитів.
• Цей конкретний виклик методу не може отримувати помилки перевищування кількості запитів.
• getMe не може отримувати помилки перевищування кількості запитів.
• getUpdates не може отримувати помилки перевищування кількості запитів.

Все це неправильно.

Давайте перейдемо до того, що ми дійсно знаємо.

Безпечні припущення щодо лімітів

З частих питаннь про ботів ми знаємо кілька лімітів, які не можна перевищувати ніколи.

1. “Під час надсилання повідомлень у певному чаті уникайте надсилання більше одного повідомлення на секунду. Ми можемо дозволити короткі серії, які перевищують цей ліміт, але зрештою ви почнете отримувати помилку з кодом 429.”

   Це має бути досить зрозуміло. Плагін auto-retry впорається з цим за вас.

2. “Якщо ви надсилаєте масові сповіщення кільком користувачам, API не дозволить більше 30 повідомлень в секунду або близько того. Для досягнення найкращого результату розгляньте можливість розподілення сповіщень на великі інтервали у 8-12 годин.”

   Це стосується лише масових сповіщень, тобто якщо ви активно надсилаєте повідомлення багатьом користувачам. Якщо ви просто відповідаєте на повідомлення від користувачів, то не проблема надсилати 1000 і більше повідомлень на секунду.

   Коли в частих питаннях про ботів сказано, що вам слід “розглянути можливість розподілення сповіщень на великі інтервали часу”, це не означає, що вам слід додавати будь-які штучні затримки. Натомість, головна ідея полягає в тому, що надсилання масових сповіщень - це процес, який займе багато годин. Ви не можете розраховувати на миттєве надсилання повідомлень усім користувачам одночасно.

3. “Також зверніть увагу, що ваш бот не зможе надсилати більше 20 повідомлень на хвилину в одну групу.”

   Знову ж таки, досить зрозуміло. Абсолютно не повʼязано з масовими повідомленнями або з тим, скільки повідомлень надсилається в групі. І знову ж таки, плагін auto-retry подбає про це за вас.

Існує кілька інших відомих обмежень, які були виявлені поза офіційною документацією Bot API. Наприклад, відомо, що боти можуть редагувати до 20 повідомлень на хвилину в груповому чаті. Однак це виняток, і ми також повинні припустити, що ці обмеження можуть бути змінені в майбутньому. Тож ця інформація не впливає на те, як запрограмувати вашого бота.

Зокрема, не варто обмежувати швидкість роботи бота на основі цих даних:

Обмеження запитів

Дехто вважає, що впиратися в ліміти - це погано. Вони вважають за краще знати точні ліміти, щоб пригальмувати свого бота.

Це неправильно. Ліміти - це інструмент, корисний для боротьби з надмірною кількістю запитів, і якщо ви діятимете відповідно, вони не матимуть жодного негативного впливу на вашого бота. Тобто перевищення лімітів не призводить до банів. А от ігнорування - призводить.

Більше того, згідно з Telegram, знати точні ліміти “марно і шкідливо”.

Марно, тому що навіть якби ви знали ліміти, вам все одно довелося б обробляти помилки перевищування кількості запитів. Наприклад, сервер Bot API повертає 429, коли вимикається, щоб перезавантажитися під час технічного обслуговування.

Це шкідливо, тому що якщо ви будете штучно затримувати деякі запити, щоб уникнути перевищення лімітів, продуктивність вашого бота буде далека від оптимальної. Ось чому ви завжди повинні робити запити якомога швидше, але з повагою ставитися до всіх помилок перевищування кількості запитів, використовуючи плагін auto-retry.

Але якщо погано обмежувати запити, то як можна робити трансляцію повідомлень?

Як транслювати повідомлення

Трансляцію можна здійснювати, дотримуючись дуже простого підходу.

1. Надішліть повідомлення користувачеві.
2. Якщо ви отримали 429, зачекайте і спробуйте ще раз.
3. Повторіть спробу.

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

Не ігноруйте 429 помилку. Це може призвести до бану.

Не відправляйте багато повідомлень паралельно. Ви можете надсилати дуже мало повідомлень паралельно (можливо 3 або близько того), але це може бути складно реалізувати.

2-й крок у наведеному вище списку виконується автоматично плагіном auto-retry, тому код виглядатиме так:

bot.api.config.use(autoRetry());
for (const [chatId, text] of broadcast) {
  await bot.api.sendMessage(chatId, text);
}

Найцікавіше тут - це те, чим буде broadcast (трансляція). Вам потрібно, щоб всі ваші чати зберігалися в якійсь базі даних, і ви мали можливість повільно їх отримувати.

Наразі вам доведеться реалізувати цю логіку самостійно. В майбутньому ми хочемо створити плагін для трансляції повідомлень. Ми будемо раді прийняти ваші внески! Приєднуйтесь до нас тут.