Message Queue و Pub/Sub — طراحی سیستم نرم‌افزاری

در رستوران، گارسون سفارش را روی برگه می‌نویسد، به ریل آشپزخانه می‌زند، و برمی‌گردد سر میز. مشتری همان لحظه می‌شنود «سفارشت ثبت شد». غذا وقتی آماده شد می‌آید. گارسون معطل سرخ‌کردن سیب‌زمینی نمی‌ماند. در سیستم به آن ریل می‌گویند Message Queue.

شغل Queue این است که Producer و Consumer را از هم جدا کند. اپ فقط رویداد را ثبت می‌کند و می‌رود؛ کار سنگین بعداً، با سرعتِ Worker، انجام می‌شود. اسم این کار Decoupling است. ستون سیستم‌های مقاوم همین است.

ریل سفارش رستوران و آشپزخانه — گارسون برگه را به ریل می‌زند و برمی‌گردد سر میز. آشپز با سرعت خودش برمی‌دارد. مشتری معطل سرخ‌کردن نمی‌ماند — همان شغل Message Queue.

DIAGRAMپردازش Async بعد از ثبت سفارش

Producer — ثبت سفارش

→

Queue — Kafka / RabbitMQ

→

Worker 1

Worker 2

→

DB / Email / انبار

چرا اصلاً صف؟

سه درد را یک ریل حل می‌کند. اگر هر سه را با تماس مستقیم — synchronous — بخواهی حل کنی، ثبت سفارش به ایمیل و انبار گره می‌خورد و هر کدام که خوابید، صندوق هم می‌خوابد.

جذب Peak: جمعه سیاه ۱۰۰K سفارش در دقیقه می‌آید؛ Worker ها با سرعت خودشان خالی می‌کنند. هیچ‌چیز نمی‌سوزد.
Fault Tolerance: سرویس ایمیل خواب است؟ پیام‌ها روی ریل می‌مانند تا بیدار شود. سفارش گم نمی‌شود.
Decoupling تیم‌ها: Producer لازم نیست بداند چه کسانی مصرف می‌کنند. انبار فردا اضافه می‌شود، کد ثبت سفارش عوض نمی‌شود.

یک کارگر، یا همه بشنوند

ریل آشپزخانه یک شغل دارد: هر برگه را یک آشپز برمی‌دارد. بلندگوی سالن شغل دیگری دارد: «سفارش ۴۲ آماده است» را هم صندوق می‌شنود، هم پیک، هم مشتری. این دو را قاطی نکن.

Queue

هر پیام را دقیقاً یک Worker برمی‌دارد. توزیع کار: ارسال ایمیل، رمزگذاری ویدیو، ساخت تصویر بندانگشتی.

Pub/Sub

هر پیام به همه مشترک‌ها می‌رسد. «سفارش ثبت شد» را هم انبار می‌شنود، هم مالی، هم نوتیفیکیشن.

Kafka

یک لاگ پارتیشن‌بندی‌شده و ماندگار. ترتیب داخل هر Kafka Partition حفظ است. Consumer Offset خودش را جلو می‌برد — Replay ممکن است.

Consumer Group

چند instance از یک سرویس، تکه‌های لاگ را بین خود قسمت می‌کنند. Horizontal Scaling مصرف، بدون اینکه یک پیام دو بار به همان سرویس برسد.

تضمین تحویل — جای باگ‌های واقعی

«حتماً می‌رسد» سه معنی دارد. اگر فرقشان را ندانی، یا پیام گم می‌کنی، یا یک ویدیو را دو بار رمز می‌کنی و فایل خراب می‌شود.

At-most-once

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

At-least-once

هرگز گم نمی‌شود، شاید تکرار شود. پیش‌فرض عملی. پس Consumer باید Idempotent باشد.

Exactly-once

گران و مشروط. در عمل همان At-least-once است به‌اضافه Consumer Idempotent — مثلاً با event_id یکتا و upsert.

DLQ: پیامی که n بار شکست، کنار گذاشته و هشدار می‌شود. پیام سمی نباید تا ابد Queue را مسموم کند.
Backpressure: اگر تولید همیشه از مصرف بیشتر است، Queue بی‌نهایت رشد می‌کند. یا Worker را Scale Out کن، یا تولید را محدود کن.
ترتیب: فقط داخل یک Kafka Partition تضمین است. پیام‌های یک سفارش را با کلید همان order_id بفرست تا همه به یک تکه بروند.

به زبان ساده

گارسون برگه را به ریل می‌زند و برمی‌گردد سر میز؛ آشپز با سرعت خودش می‌پزد. آن ریل Message Queue است.

مثال واقعی

سفارش همان لحظه ثبت می‌شود؛ ایمیل در Queue می‌ماند. اگر سرویس ایمیل خوابید، سفارش گم نمی‌شود.