مسیج بروکر (Message Broker) واسطه دریافت، نگهداری یا هدایت پیام میان تولیدکننده و مصرف‌کننده است. به‌جای آنکه ثبت سفارش مستقیما منتظر ارسال ایمیل و ساخت PDF بماند، می‌توان پیام را منتشر کرد و Workerها در زمان مناسب آن را پردازش کنند. این الگو اجزا را از نظر زمان و وابستگی مستقیم جدا می‌کند.

مقایسه چند مسیج بروکر و سامانه رویدادی

ابزارمدل غالبکاربرد پیشنهادینکته
RabbitMQQueue، Exchange و RoutingJobها و مسیریابی پیام پیچیدهAcknowledgement و DLQ قابل پیکربندی
Apache KafkaLog پارتیشن‌بندی‌شده و Retentionجریان رویداد بزرگ و Replayمدیریت Offset و Partition
Redis Streamsجریان پیام و Consumer Groupسیستم ساده و نزدیک به Redisرفتار Pending و Retention باید کنترل شود
NATS / JetStreamPub/Sub و Streamسرویس‌های سبک و کم‌تاخیرتضمین ماندگاری به JetStream وابسته است
Amazon SQSصف مدیریت‌شدهJobهای AWS بدون مدیریت BrokerVisibility Timeout و DLQ اهمیت دارند
Google Pub/Subپیام‌رسانی مدیریت‌شدهرویداد و پردازش در GCPAck، 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ها متفاوت است. برای رخداد تجاری حساس، الگوی صندوق خروجی تراکنشی و صف پیام‌های ناموفق را بررسی کنید.

اصطلاحات مرتبط: صف پیام، ورکر، ربیت‌ام‌کیو و کافکا.