پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفه‌ای

‍ وقتی نرخ ورود داده به میلیون‌ها پیام در ثانیه می‌رسد، عامل تعیین‌کننده نه ارتقای پرهزینه‌ی سخت‌افزار است و نه تکیه بر زیرساخت‌های سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که می‌تواند تفاوت واقعی را رقم بزند.
📖 اخیراً با مقاله‌ای مواجه شدم که دقیقاً همین رویکرد را نشان می‌داد: تیمی که با استفاده از مفاهیم سبک‌وزن مانند goroutine در Go و چند تصمیم مهندسی‌شده، توانسته بودند تنها با یک سخت‌افزار معمولی، بیش از ۱ میلیون پیام در ثانیه را به‌صورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار می‌پردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستم‌های توزیع‌شده.
📄 مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup 👉

📦 چالش‌ها

⚠️هجوم سنگین داده‌ها از دستگاه‌های IoT و کاربران
⚠️نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
⚠️تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا

🛠 مکانیزم‌هایی که این معماری را ممکن کردند

✅ کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام می‌شود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گم‌شدن یا پردازش تکراری داده‌ها.
✅ مکانیزم Worker Pool کنترل‌شده با goroutine:
به‌جای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیام‌ها را موازی اما کنترل‌شده پردازش می‌کنند.
✅ یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون هم‌پوشانی، بدون رقابت اضافه.
✅ الگوی Dispatcher برای جداسازی دریافت از پردازش:

• بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
• بخش دوم: پردازش پیام از صف به کمک Worker Pool

✅ دسته بندی پیام ها یا Batching در ارسال خروجی:
پیام‌های پردازش‌شده به‌صورت گروهی ارسال می‌شوند، مثلاً به دیتابیس یا تاپیک‌های دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
✅مکانیزم Backpressure هوشمند:
با محدود کردن ظرفیت صف‌ها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف می‌شود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه می‌دارد.
✅مانیتورینگ دقیق با Prometheus و Grafana:
شاخص‌هایی مثل تأخیر پردازش، consumer lag و مصرف CPU به‌صورت لحظه‌ای مانیتور می‌شوند — برای تنظیم سریع و واکنش فوری.

📊 نتایج

• نرخ پردازش: ۱.۲M msg/sec
• تأخیر کل مسیر: <۳ms
• مصرف CPU: ۹۰٪ (پایدار و قابل پیش‌بینی)

💡 نکات مهم برای مهندسان داده و سیستم‌های توزیع‌شده

🔹طراحی درست مهم‌تر از افزایش منابع
🔹 طراحی commit دقیق، batching و backpressure = ستون‌های یک سیستم مقاوم
🔹تفکیک دریافت/پردازش + تقسیم کار بین پارتیشن‌ها = مقیاس‌پذیری مؤثر
🔹مانیتورینگ لحظه‌ای = پاسخ سریع به فشارها و خطاها