صف پیام (Message Queue)
صف پیام: جدا کردن اجزا با Producer/Consumer؛ Kafka و RabbitMQ، الگوها و مزایای async
چرا صف پیام؟
مسئله کلاسیک: کاربر عکس آپلود می‌کند؛ پردازش (تغییر اندازه، فیلتر، تشخیص) ۵ ثانیه طول می‌کشد. هم‌زمان انجام دهیم؟ کاربر ۵ ثانیه منتظر + سرور زیر بار!
راه‌حل: پیام بگذار در صف و برو! کارگرها (Consumerها) بعداً پردازش می‌کنند:
Producer (وب‌سرور) → [صف پیام] → Consumer (پردازش عکس)
سریع! بافر با سرعت خودشمزایای صف پیام
| مزیت | توضیح |
|---|---|
| جداسازی (Decoupling) | تولیدکننده و مصرف‌کننده همدیگر را نمی‌شناسند! |
| جذب بار پیک | سیل درخواست → صف می‌ماند → مصرف تدریجی |
| تضمین تحویل | پیام گم نمی‌شود (Persistence + Ack) |
| مقیاس مستقل | Consumer کم است؟ اضافه کن — Producer بی‌خبر! |
| خطایابی | Consumer مرد؟ پیام در صف می‌ماند، برمی‌گردد |
Kafka در برابر RabbitMQ
| ویژگی | Kafka | RabbitMQ |
|---|---|---|
| مدل | Log توزیع‌شده (append-only) | صف کلاسیک + routing |
| حجم | میلیون‌ها پیام/ثانیه ✓✓ | ده‌ها هزار ✓ |
| نگهداری پیام | روزها/همیشه (replay!) | تا مصرف (حذف) |
| ترتیب | تضمین در Partition ✓ | FIFO صف |
| کاربرد | Event Streaming، Big Data، Log | Task Queue، RPC async |
الگوهای کلیدی
- Work Queue: یک پیام → یک Consumer (تقسیم کار)
- Publish-Subscribe: یک پیام → همه مشترک‌ها (مبحث بعد)
- Dead Letter Queue: پیام‌های شکست‌خورده → صف جدا → بررسی
- Retry + Backoff: شکست؟ بعداً دوباره، با فاصله فزاینده
- Idempotency: مصرف دوباره پیام = نتیجه همان (شبکه «حداقل یک‌بار» تحویل می‌دهد!)
نکته مصاحبه: هر جا «عملیات سنگین» یا «پیک ناگهانی» یا «سرویس‌های مستقل» دیدید، صف پیام پیشنهاد دهید — و حتماً «Idempotency چون تحویل at-least-once است» را بگویید!
جمع‌بندی
- صف = بافر بین تولید و مصرف؛ جداسازی کامل
- مزایا: پیک‌گیری، تضمین تحویل، مقیاس مستقل
- Kafka: log عظیم و replay؛ RabbitMQ: صف و routing
- Idempotency + DLQ + Retry = سیستم مقاوم
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.