پرش به محتوای اصلی
داریان تک
CS-01مقیاس‌پذیری

رباتی که در پیک کمپین
پیام‌ها را از دست نمی‌دهد.

وقتی کمپین می‌ترکد، تلگرام آپدیت‌ها را با همان سرعت می‌فرستد چه شما آماده باشید چه نباشید. اگر پردازش هر پیام درجا انجام شود، صف ورودی بالا می‌رود و پیام‌ها می‌سوزند. راه‌حل، جدا کردن دریافت از پردازش است.

۰۱مسئله

چه چیزی باید حل می‌شد

ربات‌هایی که آپدیت تلگرام را همان لحظه پردازش می‌کنند، در ترافیک بالا دچار تجمع صف می‌شوند. تلگرام برای هر آپدیت پاسخ سریع می‌خواهد؛ اگر دیر جواب بگیرد دوباره می‌فرستد و بار بیشتر می‌شود — یک چرخهٔ باطل که ربات را از کار می‌اندازد.

۰۲رویکرد

تصمیم‌های فنی و دلیلشان

هر بند اینجا یک تصمیم است که می‌شد جور دیگری گرفته شود. اگر تیم فنی دارید، همین‌ها را زیر سؤال ببرید.

  • وب‌هوک فقط آپدیت را تحویل می‌گیرد و بلافاصله پاسخ می‌دهد؛ هیچ کار سنگینی در مسیر پاسخ انجام نمی‌شود
  • کار واقعی وارد صف Redis می‌شود و کارگرهای جداگانه آن را برمی‌دارند
  • کارگرها مستقل از هم مقیاس می‌گیرند، پس بار سنگین یک بخش بقیه را متوقف نمی‌کند
  • هر پیام کلید یکتا دارد تا ارسال دوبارهٔ تلگرام باعث پردازش تکراری نشود
  • محدودسازی نرخ به‌ازای کاربر، جلوی سوءاستفاده و اسپم را می‌گیرد
۰۳دموی تعاملی

خودتان امتحان کنید

این دمو با دادهٔ نمونه کار می‌کند و به سیستم واقعی وصل نیست. برای درک رفتار سامانه ساخته شده، نه برای نمایش.

۰۴مشخصات فنی

با چه چیزی ساخته شده

دریافت
FastAPI · Async Webhook
صف
Redis Streams
کارگر
Python Worker Pool
پایگاه داده
PostgreSQL
استقرار
Docker Compose

ظرفیت و اعداد عملکردی به منابع سروری بستگی دارد که پروژه رویش مستقر می‌شود. عدد قطعی پس از تست بار روی همان سرور اندازه‌گیری و در قرارداد ثبت می‌شود.

قدم بعدی

مسئلهٔ مشابهی دارید؟

اگر چیزی از این صفحه به کار شما می‌خورد، یک جلسهٔ کوتاه کافی است تا بگوییم برای مورد شما چه چیزی منطقی است — و چه چیزی نیست.