Telegram bot-ის ჰოსტინგი: polling, webhook-ები და დეპლოი

Telegram bot არის პროგრამა, რომელიც Bot API-ს განახლებებს სთხოვს, ან რომელსაც ისინი გადმოეცემა. ეს არის მთელი არქიტექტურული გადაწყვეტილება, და ის განსაზღვრავს ჰოსტინგთან დაკავშირებულ ყველაფერს: long polling-ს არ სჭირდება დომენი, სერტიფიკატი და ღია პორტი, webhook-ს კი სამივე სჭირდება და სანაცვლოდ მცირე დაყოვნებას და უმოქმედო მოთხოვნების არარსებობას გაძლევს. bot-ების უმეტესობისთვის polling სწორი პასუხია, და ხალხი webhook-ს იმიტომ ირჩევს, რომ უფრო პროფესიონალურად ჟღერს.

ეს გზამკვლევი ორივე გზას სათანადოდ განიხილავს: რას აკონფიგურირებს რეალურად BotFather, რით განსხვავდება getUpdates და setWebhook პრაქტიკაში, ერთი ეგზემპლარის წესი, რომელიც შეცდომას იძლევა, რომელსაც ადრე თუ გვიან ყველა ხვდება, კოდი python-telegram-bot-ის, grammY-სა და Telegraf-ისთვის და როგორ გამოიყურება გაშვების ბრძანება და დეპლოი სერვერზე. თუ Discord bot-საც უშვებ, როგორ გაუშვა Discord bot 24/7 მოიცავს ნაწილებს, რომლებიც ნებისმიერი ხანგრძლივად მომუშავე bot-პროცესისთვის საერთოა.

როგორ აღწევს განახლება შენს bot-ს#

ყველაფერი, რასაც მომხმარებელი შენს bot-თან აკეთებს, Telegram-ის სერვერებზე Update ობიექტად იქცევა. მისი მიღების ზუსტად ორი გზა არსებობს და ისინი ერთმანეთს გამორიცხავს.

Long polling ნიშნავს, რომ შენი პროცესი getUpdates-ს timeout-ით იძახებს და Telegram მოთხოვნას ღიად აჩერებს, სანამ რამე არ მოხდება ან timeout არ ამოიწურება, შემდეგ კი ხელახლა იძახებ. კავშირი გამავალია, ამიტომ bot მუშაობს ლეპტოპიდან, NAT-ის უკნიდან, ნებისმიერი ადგილიდან, სადაც გამავალი HTTPS არსებობს. ფასი არის მუდმივი მიმდინარე მოთხოვნა და განახლების მოსვლისას მცირედი დაყოვნება.

Webhook ნიშნავს, რომ ერთხელ იძახებ setWebhook-ს საჯარო HTTPS URL-ით, და Telegram ყოველ განახლებას ამ URL-ზე HTTP POST-ად აგზავნის. უმოქმედო მოთხოვნა არ არსებობს, მიწოდება მყისიერია და bot გვერდზე მასშტაბირდება, თუ ოდესმე დაგჭირდება. ფასი ისაა, რომ ახლა ვებ სერვერს უშვებ, გჭირდება hostname და სერტიფიკატი და გაქვს საჯარო endpoint, რომლის გამოცნობაც ნებისმიერს შეუძლია.

ორივეს ერთად ვერ გამოიყენებ. თუ webhook დაყენებულია, getUpdates უარს ამბობს შეტყობინებით 409 Conflict: can't use getUpdates method while webhook is active. ჯერ გამოიძახე deleteWebhook. იგივე 409 სხვა ფორმულირებით ჩნდება, როცა შენი bot-ის ორი ასლი ერთსა და იმავე token-ს ეკითხება - ეს Telegram bot-ის ყველაზე გავრცელებული საკუთარი შეცდომაა და მიზეზი, რატომაც staging bot-ს საკუთარი token სჭირდება და არა production-ის ასლი.

bot-ის შექმნა: BotFather და პარამეტრები, რომლებსაც ივიწყებენ#

მისწერე @BotFather-ს Telegram-ში, გაგზავნე /newbot, აირჩიე გამოსაჩენი სახელი და მომხმარებლის სახელი, რომელიც bot-ით მთავრდება. მიიღებ token-ს ფორმით 123456789:AAH..., სადაც ორწერტილამდე ნაწილი შენი bot-ის რიცხვითი ID-ია. ეს პაროლია. /revoke ახალს გასცემს და ძველს მყისვე კლავს, რაც გაჟონვის გამოსწორებაცაა და გაუმართაობაც, სანამ ხელახლა არ დაადეპლოებ.

BotFather-ის სამი პარამეტრი bot-ის ქცევას ცვლის და მათი გამოტოვება ადვილია:

• ჯგუფის კონფიდენციალურობის რეჟიმი ნაგულისხმევად ჩართულია. ჯგუფებში bot, რომელსაც კონფიდენციალურობის რეჟიმი ჩართული აქვს, იღებს მხოლოდ შეტყობინებებს, რომლებიც ბრძანებებია, საკუთარ შეტყობინებებზე პასუხებია ან მასზე მოხსენიებებია. თუ შენს bot-ს ჯგუფში ყველაფრის წაკითხვა სჭირდება - მოდერაციის ან ლოგირების bot - გამორთე /setprivacy-ით, შემდეგ bot ჯგუფიდან ამოიღე და ხელახლა დაამატე, რადგან პარამეტრი bot-ის ჯგუფში შესვლისას გამოიყენება.
• ბრძანებები, რომლებიც /setcommands-ით ყენდება, ავსებს მენიუს შეყვანის ველის გვერდით. მომხმარებლები ბრძანებებს, რომლებიც არასოდეს დაგირეგისტრირებია, ვერ აღმოაჩენენ. ამის გაკეთება კოდიდანაც შეგიძლია setMyCommands-ით, რაც უკეთესი ვარიანტია, რადგან ის იმ კოდთან ცხოვრობს, რომელიც მათ ახორციელებს.
• Inline რეჟიმი გამორთულია, სანამ /setinline-ით არ ჩართავ. bot-ს, რომელიც ნებისმიერ ჩატში @yourbot query-ზე უნდა პასუხობდეს, ის ჩართული უნდა ჰქონდეს, სანამ inline handler-ი ოდესმე გაეშვება.

token შეინახე გარემოს ცვლადში. ლოკალურად ეს .env ფაილია, რომელსაც .gitignore ფარავს; სერვერზე ეს ცვლადია Startup ჩანართზე. სად შეინახო საიდუმლოებები აპლიკაციის სერვერზე განმარტავს, რატომ რჩება რეპოზიტორიაში მოხვედრილი token საშიში მისი წაშლის შემდეგაც დიდხანს.

Long polling პრაქტიკაში#

polling bot ერთ HTTP მოთხოვნას აკეთებს ერთდროულად და მასზე ბლოკდება. პარამეტრები, რომლებსაც მნიშვნელობა აქვს:

ყოველი ბიბლიოთეკა offset-ს შენ მაგივრად ამუშავებს, და ხელით დაწერილი bot ერთსა და იმავე შეტყობინებას სამუდამოდ იმიტომ ამუშავებს, რომ ის არასწორად აქვს გაკეთებული. allowed_updates-ის ცხადად დაყენება ღირს: ნაგულისხმევად chat_member განახლებები არ იგზავნება, და თუ ვიწრო სიას მოითხოვ, აღარ იღებ რედაქტირებულ შეტყობინებებს და არხის პოსტებს, რომლებსაც არასოდეს დახედავ.

Telegram მიუწოდებელ განახლებებს 24 საათამდე ინახავს. ეს სასარგებლო თვისებაცაა და უსიამოვნო სიურპრიზიც: bot, რომელიც მთელი ღამე გათიშული იყო, იღვიძებს და ღამის მთელ შეტყობინებებს ერთბაშად ამუშავებს, პასუხობს საუბრებს, რომლებიც საათების წინ დასრულდა. თუ ეს შენი bot-ისთვის არასწორია, გაშვებისას გამოიყენე drop_pending_updates, რომელიც დაგროვილს ხელახლა გაშვების ნაცვლად გაუქმებს.

ერთი ეგზემპლარის წესი აბსოლუტურია. ორი პროცესი, რომელიც ერთ token-ს ეკითხება, ერთმანეთს ეჯიბრება, თითოეული განახლებების შემთხვევით ნახევარს იღებს და ორივე 409-ებს წერს. ეს ხდება, როცა დეპლოი ახალ პროცესს ძველის გასვლამდე იწყებს, როცა bot ლეპტოპზე დარჩენილია გაშვებული და როცა staging production-ის token-ს იყენებს. დაამუშავე SIGTERM, გააჩერე poller და პროცესი გამოვიდეს - გამართული გაჩერება და health check-ები ზოგად ნიმუშს შეიცავს.

Webhook-ები პრაქტიკაში#

webhook პატარა ვებ სერვერია და ერთი API გამოძახება. Telegram-ის მოთხოვნები კონკრეტულია:

• მხოლოდ HTTPS, საჯარო ორგანოს სერტიფიკატით, ან საკუთარი ხელმოწერილი სერტიფიკატით, რომელსაც certificate პარამეტრით ტვირთავ.
• პორტი 443, 80, 88 ან 8443. სხვა პორტი არ მუშაობს, და სწორედ ეს მოთხოვნაა, რომელიც სახლის სერვერის უმეტეს მოწყობას ჩაშლის.
• URL გამოუცნობი უნდა იყოს. token-ის გზაში ჩადება ტრადიციული ხრიკი იყო; თანამედროვე პასუხია secret_token, რომელიც Telegram-ს ყოველ მოთხოვნაზე X-Telegram-Bot-Api-Secret-Token header-ის გაგზავნას აიძულებს. უარყავი ყველაფერი, რაც მას არ ემთხვევა, თორემ ვისაც შენი URL ეცოდინება, შენს bot-ს გამოგონილ განახლებებს მიაწვდის.

$ curl -X POST "https://api.telegram.org/bot$BOT_TOKEN/setWebhook" \    -d "url=https://bot.example.com/tg/hook" \    -d "secret_token=$WEBHOOK_SECRET" \    -d "max_connections=20" \    -d "allowed_updates=[\"message\",\"callback_query\"]"

max_connections (1-100, ნაგულისხმევი 40) ზღუდავს, რამდენ მიწოდებას გააჩერებს Telegram ერთდროულად. 0.5 vCPU-ს გეგმაზე 40 ერთდროული handler საჩუქარი არ არის; დაწიე, სანამ არ დაემთხვევა იმას, რასაც შენი აპლიკაცია რეალურად პარალელურად შეძლებს.

როცა რამე არასწორია, getWebhookInfo ზუსტად გეუბნება რა:

$ curl "https://api.telegram.org/bot$BOT_TOKEN/getWebhookInfo"

ის აბრუნებს რეგისტრირებულ url-ს, pending_update_count-ს და - რაც სასარგებლოა - last_error_date-სა და last_error_message-ს, ანუ Telegram შენივე სერვერის ჩავარდნას გიბრუნებს ციტატად. მზარდი pending_update_count ახალ შეცდომასთან ერთად ნიშნავს, რომ მიწოდება ვერ ხერხდება და Telegram ხელახლა ცდილობს. მზარდი მნიშვნელობა შეცდომის გარეშე ნიშნავს, რომ შენი handler ძალიან ნელია.

ეს ბოლო შემთხვევა webhook-ების დიზაინის წესია: HTTP მოთხოვნას მყისვე უპასუხე 200-ით და სამუშაო შემდეგ გააკეთე. handler, რომელიც პასუხამდე სამ API-ს იძახებს, Telegram-ის კავშირს ღიად აჩერებს, max_connections-ს ხარჯავს და საბოლოოდ timeout-ს იღებს. დაადასტურე, ჩააყენე რიგში, დაამუშავე - ფონური დავალებები პატარა სერვერზე განიხილავს რიგის მხარეს, როცა სამუშაო მართლა ნელია.

ჰოსტინგის მხრივ, ოთხიდან ერთი პორტის მოთხოვნა არის მიზეზი, რატომ აქვს proxy სლოტს მნიშვნელობა. შენი აპლიკაცია კონტეინერის შიგნით საკუთარ პორტზე უსმენს; proxy TLS-ს მის წინ 443-ზე ასრულებს, რომელიც Telegram-ის ოთხიდან ერთ-ერთია. მიუთითე A ჩანაწერი proxy ჩანართზე ნაჩვენებ მისამართზე და სერტიფიკატი ავტომატურად გაიცემა და განახლდება ვადის ამოწურვამდე 21-დღიან ფანჯარაში. კლიენტის მისამართი X-Forwarded-For-ში მოდის, რაც Telegram-ის webhook-ისთვის მხოლოდ მაშინაა სასარგებლო, თუ Telegram-ის გამოქვეყნებული მისამართების დიაპაზონით შეზღუდვა გინდა. რას აკეთებს reverse proxy სინამდვილეში და დომენის მიმართვა შენს სერვერზე ორივე ნახევარს განიხილავს; თუ DNS მხარე უცნობია, DNS ჩანაწერები ახსნილი შესავალია.

ბიბლიოთეკები, ორივე რეჟიმში#

სამი მთავარი ბიბლიოთეკა ორ რეჟიმს დაახლოებით ერთი და იმავე რაოდენობის სტრიქონებით გამოხატავს.

import osfrom telegram import Updatefrom telegram.ext import Application, CommandHandler, ContextTypesasync def start(update: Update, context: ContextTypes.DEFAULT_TYPE):    await update.message.reply_text("Ready.")app = Application.builder().token(os.environ["BOT_TOKEN"]).build()app.add_handler(CommandHandler("start", start))# Long pollingapp.run_polling(allowed_updates=Update.ALL_TYPES)# Or a webhook, on the port the plan allocatedapp.run_webhook(    listen="0.0.0.0",    port=int(os.environ["PORT"]),    url_path="tg/hook",    webhook_url="https://bot.example.com/tg/hook",    secret_token=os.environ["WEBHOOK_SECRET"],)

run_webhook webhook-ს Telegram-თან შენ მაგივრად არეგისტრირებს და პატარა სერვერს უშვებს. ყურადღება მიაქციე listen="0.0.0.0"-ს: 127.0.0.1-ზე მიბმა ნიშნავს, რომ კონტეინერს გარეთ არაფერი მიაღწევს მას, და ეს ყველაზე გავრცელებული მიზეზია, რატომ ჩანს webhook აპლიკაცია სწორად გაშვებული და არაფერს იღებს.

import { Bot, webhookCallback } from "grammy";import express from "express";const bot = new Bot(process.env.BOT_TOKEN);bot.command("start", (ctx) => ctx.reply("Ready."));if (process.env.MODE === "webhook") {  const app = express();  app.use(express.json());  app.use("/tg/hook", webhookCallback(bot, "express", {    secretToken: process.env.WEBHOOK_SECRET,  }));  app.listen(Number(process.env.PORT), "0.0.0.0");} else {  bot.start();}

Telegraf მსგავსია: bot.launch() long polling-ს იწყებს და არ სრულდება, სანამ bot არ გაჩერდება, ხოლო bot.createWebhook({ domain }) აბრუნებს middleware-ს, რომელსაც Express აპლიკაციაზე მიამაგრებ. რომელსაც არ უნდა იყენებდე, დაარეგისტრირე SIGINT და SIGTERM handler-ები, რომლებიც bot-ს აჩერებს, რადგან შუა მოთხოვნაზე მოკლული poller Telegram-ს რამდენიმე წამით აფიქრებინებს, რომ ეგზემპლარი ისევ მიბმულია - საკმარისად დიდხანს, რომ შემცვლელმა პროცესმა გაშვებისას 409 მიიღოს.

ერთი ოპტიმიზაცია, რომელიც მხოლოდ webhook-ებს აქვს: Telegram-ის POST-ს შეგიძლია უპასუხო JSON სხეულით, რომელიც მეთოდის გამოძახებას აღწერს, და ის სრულდება ისე, თითქოს მოთხოვნა შენ გაგეკეთებინოს. შეტყობინებაზე ამგვარად პასუხი ერთ სრულ წრეს დაზოგავს. კოდის გადაკეთებას არ ღირს, მაგრამ უფასოა, როცა შენი handler ზუსტად ერთ რამეს აკეთებს.

სერვერზე დადება#

დეპლოის ფორმა იგივეა, რაც ნებისმიერი რეზიდენტული პროცესისა. დააყენე lockfile-იდან ან requirements.txt-იდან, გაუშვი ერთი ბრძანება, გამოსვლისას გადატვირთე.

# Nodenpm ci --omit=dev && node bot.js# Pythonpip install --no-cache-dir -r requirements.txt && python -u bot.py

python -u, ან PYTHONUNBUFFERED=1, უფრო მნიშვნელოვანია, ვიდრე ჩანს: მის გარეშე შენი ლოგის სტრიქონები ბუფერში ზის და კონსოლი ცარიელი რჩება, მაშინაც კი, როცა bot შესანიშნავად მუშაობს. როგორ წაიკითხო სერვერის კონსოლი გამოცნობის გარეშე სწორედ ასეთი არაპრობლემის რეალურისგან გარჩევას ეხება.

გარემოს ცვლადები - BOT_TOKEN, WEBHOOK_SECRET, მონაცემთა ბაზის URL, რეჟიმის გადამრთველი - Startup ჩანართზე იდება. RE:NODE-ზე კოდი GitHub-იდან მოდის GitHub App-ით მოკლევადიანი token-ებით, ამიტომ კერძო რეპოზიტორიები მუშაობს, და ორი გადამრთველია: branch-ის pull ყოველ გაშვებაზე და დეპლოი push-ზე, რომელიც უკვე გაშვებულ სერვერს გადატვირთავს. ყოველი დეპლოი ერთი ჩანაწერია, რომელიც იხსნება, როცა push მოდის, და იხურება, როცა კონტეინერი ისევ გაშვებული ჩანს.

webhook bot-ს დეპლოის ერთი დამატებითი გასათვალისწინებელი აქვს. რეგისტრირებული URL გადატვირთვას გადარჩება, რადგან Telegram-ის მხარეს ცხოვრობს, ამიტომ ყოველ გაშვებაზე ხელახლა არ არეგისტრირებ. ხელახლა დაარეგისტრირე, როცა hostname ან საიდუმლო იცვლება, და შემდეგ getWebhookInfo შეამოწმე და ნუ დაეყრდნობი ვარაუდს. polling bot-ს საპირისპირო გასათვალისწინებელი აქვს: დარწმუნდი, რომ ძველი პროცესი წავიდა, სანამ ახალი დაიწყებს, თორემ ყოველი დეპლოის პირველი ოცდაათი წამი 409-ებით სავსეა.

bot-ისთვის, რომელსაც მნიშვნელობა აქვს, გაუშვი მეორეც. ცალკე BotFather-ის bot საკუთარი token-ით, საკუთარი სერვერით და branch-ით, რომლის merge-იც აპირებ, ძალიან იაფი ჯდება და არასწორ handler-ს შენს მომხმარებლებზე ადრე იჭერს. Staging და production ერთ ანგარიშზე ნიმუშს შეიცავს და ეს Telegram-ის კოდის შემოწმების ერთადერთი უსაფრთხო გზაა, რადგან sandbox API არ არსებობს.

სიხშირის ლიმიტები, ფაილის ზომები და რასაც Telegram არ გაძლევს#

Bot API-ს აქვს ლიმიტები, რომლებზეც მოლაპარაკება არ მიდის, და მათ გარშემო დაგეგმვა გვიან ძვირი ჯდება.

მათი გადაჭარბება აბრუნებს 429-ს retry_after მნიშვნელობით პასუხში, და ბიბლიოთეკები ჩვეულებრივ ელოდებიან. ამიტომ მომხმარებლების დიდ სიაზე გაგზავნა შენივე კოდმა უნდა დაარეგულიროს: რიგი, რამდენიმე შეტყობინება წამში და ჩანაწერი იმისა, ვისაც უკვე გაუგზავნე, რომ გადატვირთვამ თავიდან არ დაიწყოს. მასობრივი გაგზავნა მჭიდრო ციკლში bot-ის უსარგებლოდ შეზღუდვის ყველაზე სწრაფი გზაა.

ფაილის ლიმიტები ისაა, რაც media bot-ის მშენებლებს აკვირვებს. ეს საჯარო Bot API-ს ლიმიტებია და არა Telegram-ის, და მათი მოხსნა შეიძლება ღია წყაროს ლოკალური Bot API სერვერის საკუთარი ძალებით გაშვებით - ეს ცალკე კომპილირებული სერვისია საკუთარი API მონაცემებით და მანქანაზე უნდა იყოს, რომელსაც აკონტროლებ და არა შენი აპლიკაციის გვერდით. თუ იქით მიდიხარ, dedicated სერვერები ამისთვის სწორი ფორმაა.

პრობლემების მოგვარება#

`409 Conflict: terminated by other getUpdates request`. ორი პროცესი ერთ token-ზე. იპოვე მეორე: ძველი კონტეინერი, ლოკალური გაშვება, staging ასლი.

`409 Conflict: can't use getUpdates method while webhook is active`. გამოიძახე deleteWebhook, შემდეგ გააკეთე polling.

`401 Unauthorized`. token არასწორია, ცარიელია ან გაუქმებულია. დაუყენებელი გარემოს ცვლადი ზუსტად ამას იძლევა.

webhook დაყენებულია, მაგრამ არაფერი მოდის. შეამოწმე getWebhookInfo last_error_message-ისთვის. ჩვეულებრივი პასუხებია: სერტიფიკატი, რომელსაც კლიენტი ვერ ამოწმებს, 127.0.0.1-ზე მიბმული აპლიკაცია, გზის შეუსაბამობა რეგისტრირებულ URL-სა და route-ს შორის, ან framework-ის 404, რომელმაც route არასოდეს დაინახა.

განახლებები მოდის, მაგრამ დატვირთვისას ჩერდება. მზარდი pending_update_count ნიშნავს, რომ შენი handler მოსვლის სიჩქარეზე ნელია. ჯერ უპასუხე 200-ით, შემდეგ იმუშავე.

bot პირად ჩატებში პასუხობს, მაგრამ ჯგუფებს უგულებელყოფს. კონფიდენციალურობის რეჟიმი. გამორთე BotFather-ში და bot ჯგუფში ხელახლა დაამატე.

ყველაფერი მუშაობდა, შემდეგ bot დეპლოის შემდეგ გაჩუმდა. poller-ებისთვის - გაჩერებული ძველი პროცესი. webhook-ებისთვის - შეცვლილი hostname ძველი რეგისტრაციით.

FAQ#

გამოვიყენო long polling თუ webhook?

Long polling, თუ სხვა მიზეზი არ გაქვს. მას არ სჭირდება დომენი, სერტიფიკატი და შემომავალი პორტი, ის განვითარებაშიც და production-შიც ერთნაირად მუშაობს, და დაყოვნების განსხვავება წამის ნაწილია. webhook-ზე გადადი, როცა განახლებების დიდ მოცულობას აგზავნი, როცა გინდა რამდენიმე ეგზემპლარი ერთ endpoint-ს უკან, ან როცა უმოქმედო გამავალი მოთხოვნა მართლა პრობლემაა.

სჭირდება Telegram bot-ს დომენი?

მხოლოდ webhook-ებისთვის. polling bot-ს გამავალი HTTPS სჭირდება და სხვა არაფერი. თუ webhook-ის გზას აირჩევ, app გეგმის proxy სლოტი გაძლევს hostname-სა და ავტომატურად განახლებად სერტიფიკატს, ამიტომ DNS-ის ერთადერთი სამუშაო ერთი A ჩანაწერია.

რატომ ვიღებ 409 შეცდომას ყოველ დეპლოიზე?

იმიტომ, რომ ახალმა პროცესმა polling ძველის გაჩერებამდე დაიწყო. Telegram ერთ token-ზე ერთ getUpdates გამომძახებელს იძლევა. გააკეთე გაჩერება სუფთად და staging არასოდეს გაუშვა production-ის token-ზე.

შემიძლია Telegram bot უფასოდ დავაჰოსტო?

შეგიძლია სახლში გაუშვა და ის გათიშული იქნება, როცა ის მანქანა გათიშულია. უფასო პლატფორმები, რომლებიც უმოქმედო პროცესს აჩერებს, poller-ს არ ერგება, რომელიც დიზაინით უმოქმედოს ჰგავს. აქ უფასო დონე არ არსებობს; ყველაზე პატარა app გეგმა 1 GB-ია 0.5 vCPU-თი თვეში $4-დან, რაც ტექსტურ bot-ს მეტია, ვიდრე სჭირდება.

როგორ გავუგზავნო შეტყობინება ათასობით მომხმარებელს?

ნელა და პროგრესის ჩანაწერით. Telegram-ის გამოქვეყნებული რეკომენდაცია დაახლოებით 30 შეტყობინებაა წამში სხვადასხვა მომხმარებლებზე, ამიტომ გაგზავნა რიგში ჩააყენე, დაარეგულირე, შეინახე რომელი მომხმარებლის ID-ები დამუშავდა და თუ გადააჭარბებ, მოელოდე 429-ს retry_after-ით. გაგზავნა, რომელიც ჩავარდნის შემდეგ ნულიდან იწყება, უარესია ნელზე.

შეუძლია ერთ სერვერს რამდენიმე bot-ის გაშვება?

ორი პატარა bot ერთ კონტეინერში ეტევა, მაგრამ ისინი მეხსიერების ლიმიტსა და CPU წილს იზიარებენ, ამიტომ ერთის ციკლური ჩავარდნა მეორესაც მოაყოლებს. ცალკე გეგმები ზიანის რადიუსს პატარას ინახავს, და კონსოლის გრაფიკები იკითხება, რადგან თითოეული ერთ პროცესს აჩვენებს.