مسیج بروکر (Message Broker) واسطه دریافت، نگهداری یا هدایت پیام میان تولیدکننده و مصرفکننده است. بهجای آنکه ثبت سفارش مستقیما منتظر ارسال ایمیل و ساخت PDF بماند، میتوان پیام را منتشر کرد و Workerها در زمان مناسب آن را پردازش کنند. این الگو اجزا را از نظر زمان و وابستگی مستقیم جدا میکند.
مقایسه چند مسیج بروکر و سامانه رویدادی
| ابزار | مدل غالب | کاربرد پیشنهادی | نکته |
|---|---|---|---|
| RabbitMQ | Queue، Exchange و Routing | Jobها و مسیریابی پیام پیچیده | Acknowledgement و DLQ قابل پیکربندی |
| Apache Kafka | Log پارتیشنبندیشده و Retention | جریان رویداد بزرگ و Replay | مدیریت Offset و Partition |
| Redis Streams | جریان پیام و Consumer Group | سیستم ساده و نزدیک به Redis | رفتار Pending و Retention باید کنترل شود |
| NATS / JetStream | Pub/Sub و Stream | سرویسهای سبک و کمتاخیر | تضمین ماندگاری به JetStream وابسته است |
| Amazon SQS | صف مدیریتشده | Jobهای AWS بدون مدیریت Broker | Visibility Timeout و DLQ اهمیت دارند |
| Google Pub/Sub | پیامرسانی مدیریتشده | رویداد و پردازش در GCP | Ack، Redelivery و Ordering باید تنظیم شوند |
مثال استفاده از Queue در Laravel
// Dispatch a job after the order is committed.
DB::transaction(function () use ($data) {
$order = Order::create($data);
SendOrderEmail::dispatch($order->id)->afterCommit();
});
نمونه مفهوم Producer و Consumer در Python با RabbitMQ
import pika
connection = pika.BlockingConnection(pika.ConnectionParameters("localhost"))
channel = connection.channel()
channel.queue_declare(queue="order_emails", durable=True)
channel.basic_publish(exchange="", routing_key="order_emails",
body=b"order:42",
properties=pika.BasicProperties(delivery_mode=2))
connection.close()
نمونه بالا فقط ارسال پیام را نشان میدهد. در مصرفکننده باید تایید دریافت، مدیریت شکست، Retry و Idempotency نیز پیادهسازی شوند.
مسیج بروکر و دیتابیس یکی نیستند
دوام پیام، ترتیب تحویل و Exactly-once میان Brokerها متفاوت است. برای رخداد تجاری حساس، الگوی صندوق خروجی تراکنشی و صف پیامهای ناموفق را بررسی کنید.
اصطلاحات مرتبط: صف پیام، ورکر، ربیتامکیو و کافکا.