📰 مقالات › 📊 تحلیل › Redis، RabbitMQ، یا Kafka؟ — …

📝 مقاله 📊 تحلیل ⭐ ویژه

Redis، RabbitMQ، یا Kafka؟ — راهنمای انتخاب درست در ۲۰۲۶

سه ابزار که همه جا اسمشان هست اما تفاوت‌هاشان را کمتر کسی می‌داند — مقایسه کامل با مثال‌های واقعی

میثم شبانی

نویسنده

📅 ۱۴۰۵/۰۳/۱۱

⏱ 14 دقیقه

👁 312

❤️ 2

📋 فهرست مطالب ▼

اول از همه: Message Broker چیست؟
۱. Redis — سریع‌ترین، ساده‌ترین
۲. RabbitMQ — قابل‌اعتمادترین، انعطاف‌پذیرترین
۳. Apache Kafka — قدرتمندترین، پیچیده‌ترین
مقایسه عددی — اعداد واقعی ۲۰۲۶
کدام را انتخاب کنید؟ — درخت تصمیم
مثال واقعی: PyCourse از کدام استفاده می‌کند؟
بزرگ‌ترین تغییر ۲۰۲۶: Kafka بدون ZooKeeper
ترکیب هر سه — معماری واقعی
جمع‌بندی

در هر کنفرانس فنی، در هر تیم backend، در هر مصاحبه شغلی — این سه اسم را می‌شنوید: Redis، RabbitMQ، Kafka. همه می‌دانند که می‌توانند بعنوان «message broker» استفاده شوند. اما وقتی باید یکی یا دو یا هر سه را همراه با هم انتخاب کنید، سکوت می‌شود.

این مقاله را نوشتیم تا این سکوت را بشکنیم. نه با تعاریف خشک، بلکه با مثال‌های واقعی، اعداد واقعی، و یک راهنمای ساده برای انتخاب درست.

💡

نسخه‌های فعلی — ژوئن ۲۰۲۶

Apache Kafka: 4.3.0 (منتشر ۲۲ مه ۲۰۲۶) — حذف کامل ZooKeeper
RabbitMQ: 4.0.x (پایدار)
Redis: 8.0.x (با Redis Streams بهبودیافته)

اول از همه: Message Broker چیست؟

تصور کنید یک فروشگاه آنلاین دارید. کاربر سفارش می‌دهد — بلافاصله باید:
- ایمیل تأییدیه ارسال شود
- موجودی انبار کم شود
- پیامک به پیک فرستاده شود
- گزارش مالی آپدیت شود

اگر همه این‌ها را synchronous انجام دهید (یکی یکی و در همان request)، کاربر باید ۳ ثانیه منتظر بماند. و اگر یکی خطا دهد، کل تراکنش fail می‌شود.

Message Broker راه‌حل است: سفارش در یک صف (queue) گذاشته می‌شود، کاربر فوری پاسخ می‌گیرد، و سرویس‌های مختلف هر کدام در زمان خودشان پیام را پردازش می‌کنند.

۱. Redis — سریع‌ترین، ساده‌ترین

Redis یک in-memory data store است که pub/sub و Redis Streams را هم دارد. سرعتش از دو رقیب خود بیشتر است چون همه چیز در RAM است — اما این همان نقطه ضعفش هم هست: اگر سرور ری‌استارت شود، پیام‌ها از دست می‌روند مگر اینکه persistence را فعال کنید.

Redis Pub/Sub یک مدل fire-and-forget است — اگر consumer در لحظه انتشار پیام آنلاین نباشد، پیام را نمی‌بیند. Redis Streams این مشکل را حل کرد و پیام‌ها را نگه می‌دارد.

🐍 PYTHON — Redis Pub/Sub در Python

import redis

r = redis.Redis(host="localhost", port=6379)

# Publisher — ارسال پیام
r.publish("notifications", "سفارش #1042 تأیید شد")

# Subscriber — دریافت پیام
pubsub = r.pubsub()
pubsub.subscribe("notifications")

for message in pubsub.listen():
    if message["type"] == "message":
        print(f"پیام دریافت شد: {message['data'].decode()}")

# Redis Streams — با persistence
r.xadd("orders", {"order_id": "1042", "status": "confirmed"})
messages = r.xread({"orders": "0"}, count=10)
print(messages)

✅

Redis کِی انتخاب کنید؟

✓ notification های realtime (chat، live update)
✓ cache invalidation بین سرویس‌ها
✓ session sharing بین چند instance
✓ leaderboard و counter های real-time
✓ وقتی Redis را برای cache دارید و نمی‌خواهید سرویس جدید اضافه کنید
✓ پروژه‌های کوچک تا متوسط

🔴

Redis کِی مناسب نیست؟

✗ وقتی از دست رفتن پیام قابل قبول نیست (پرداخت، حسابداری)
✗ میلیون‌ها پیام در ثانیه
✗ نیاز به replay پیام‌های قدیمی
✗ پردازش توزیع‌شده پیچیده

۲. RabbitMQ — قابل‌اعتمادترین، انعطاف‌پذیرترین

RabbitMQ قدیمی‌ترین و پخته‌ترین گزینه است. در سال ۲۰۰۷ ساخته شده و با پروتکل AMQP کار می‌کند. مثل یک اداره پست هوشمند عمل می‌کند.

مهم‌ترین ویژگی آن سیستم ACK (تأیید دریافت) است: وقتی consumer پیام را پردازش کرد، یک تأیید به RabbitMQ می‌فرستد. اگر consumer crash کند قبل از تأیید، RabbitMQ پیام را به consumer دیگری می‌دهد. هیچ پیامی گم نمی‌شود.

سیستم Exchange و Routing آن بسیار انعطاف‌پذیر است — می‌توانید بر اساس topic، pattern، یا fanout پیام‌ها را route کنید.

🐍 PYTHON — RabbitMQ با Celery در Django

# settings.py
CELERY_BROKER_URL = "amqp://guest:guest@localhost:5672//"

# tasks.py
from celery import shared_task
from django.core.mail import send_mail

@shared_task(bind=True, max_retries=3)
def send_order_email(self, order_id, email):
    try:
        send_mail(
            subject=f"سفارش #{order_id} تأیید شد",
            message="سفارش شما با موفقیت ثبت شد.",
            from_email="shop@example.com",
            recipient_list=[email],
        )
    except Exception as exc:
        # اگر خطا داشت، 3 بار retry می‌کند
        raise self.retry(exc=exc, countdown=60)

# views.py — فراخوانی async
def checkout(request):
    order = Order.objects.create(...)
    send_order_email.delay(order.id, request.user.email)
    # فوری return می‌کند — email در background ارسال می‌شود
    return JsonResponse({"status": "success"})

✅

RabbitMQ کِی انتخاب کنید؟

✓ task queue — ارسال ایمیل، SMS، پردازش تصویر
✓ وقتی هر پیام باید دقیقاً یک بار پردازش شود
✓ workflow های پیچیده با routing مختلف
✓ یکپارچگی با Celery در پروژه‌های Python/Django
✓ پرداخت‌ها و تراکنش‌های مالی
✓ پروژه‌های enterprise با SLA بالا

🔴

RabbitMQ کِی مناسب نیست؟

✗ throughput بالای ۱۰۰K پیام در ثانیه
✗ نیاز به replay پیام‌های قدیمی (پیام پس از ACK حذف می‌شود)
✗ event streaming و تحلیل real-time
✗ وقتی چندین سرویس باید همان پیام را بخوانند (fan-out در مقیاس بزرگ)

۳. Apache Kafka — قدرتمندترین، پیچیده‌ترین

Kafka در اصل یک event streaming platform است، نه صرفاً یک message broker. LinkedIn آن را برای پردازش روزانه بیلیون‌ها event ساخت.

تفاوت اساسی Kafka با بقیه: پیام‌ها بعد از خواندن حذف نمی‌شوند — در disk ذخیره می‌مانند (به صورت پیش‌فرض ۷ روز). این یعنی هر سرویسی می‌تواند مستقل پیام‌ها را بخواند، و می‌توانید به گذشته برگردید و پیام‌ها را دوباره پردازش کنید.

Kafka 4.0 (ژانویه ۲۰۲۶) یک تغییر بنیادی داشت: ZooKeeper کاملاً حذف شد و KRaft جایگزین شد. Kafka 4.3.0 در ۲۲ مه ۲۰۲۶ منتشر شد.

🐍 PYTHON — Kafka با kafka-python

from kafka import KafkaProducer, KafkaConsumer
import json

# Producer — ارسال event
producer = KafkaProducer(
    bootstrap_servers=["localhost:9092"],
    value_serializer=lambda v: json.dumps(v).encode("utf-8")
)

# ارسال event خرید
producer.send("user-events", {
    "event": "purchase",
    "user_id": 1042,
    "product_id": 55,
    "amount": 299000,
    "timestamp": "2026-06-01T10:30:00Z"
})
producer.flush()

# Consumer — چندین سرویس مستقل می‌توانند همین topic را بخوانند
consumer = KafkaConsumer(
    "user-events",
    bootstrap_servers=["localhost:9092"],
    group_id="analytics-service",  # هر group_id مستقل است
    value_deserializer=lambda m: json.loads(m.decode("utf-8"))
)

for message in consumer:
    event = message.value
    print(f"event: {event['event']} — user: {event['user_id']}")
    # analytics-service این را پردازش می‌کند
    # recommendation-service با group_id دیگر همین پیام را جداگانه می‌خواند

✅

Kafka کِی انتخاب کنید؟

✓ میلیون‌ها event در ثانیه (click tracking، log aggregation)
✓ وقتی چندین سرویس باید همان event را بخوانند
✓ نیاز به replay — پردازش دوباره داده‌های گذشته
✓ real-time analytics و data pipeline
✓ audit log — سابقه کامل همه تغییرات
✓ microservices در مقیاس بزرگ (Netflix، Uber، LinkedIn)

🔴

Kafka کِی مناسب نیست؟

✗ پروژه‌های کوچک — overhead عملیاتی زیاد دارد
✗ وقتی به routing پیچیده نیاز دارید (RabbitMQ بهتر است)
✗ تیم کوچک بدون تجربه distributed systems
✗ نیاز به پاسخ فوری (request-reply pattern)

مقایسه عددی — اعداد واقعی ۲۰۲۶

معیار	Redis Pub/Sub	RabbitMQ	Kafka
سرعت	<1ms	1-10ms	5-100ms
throughput	~1M msg/s	50K-100K msg/s	1M+ msg/s per broker
persistence	اختیاری (RAM)	بله (disk)	بله (disk، 7 روز)
از دست رفتن پیام	ممکن است	خیر (با ACK)	خیر
replay پیام	خیر	خیر	بله
مقیاس‌پذیری	vertical	محدود	horizontal بی‌نهایت
پیچیدگی راه‌اندازی	خیلی ساده	متوسط	پیچیده
نیاز به RAM	کم	متوسط	زیاد
مناسب برای	realtime/cache	task queue	event streaming

کدام را انتخاب کنید؟ — درخت تصمیم

به جای جدول خشک، یک سری سوال بپرسید:

آیا Redis دارید؟ → اگر کار ساده است (notification، cache invalidation)، همان Redis کافی است
آیا پیام نباید گم شود؟ → اگر بله، Redis Pub/Sub را حذف کنید
آیا نیاز به retry و ACK دارید؟ → RabbitMQ انتخاب کنید
آیا بیش از ۱۰۰K پیام در ثانیه دارید؟ → Kafka
آیا چند سرویس باید همان پیام را بخوانند؟ → Kafka
آیا باید پیام‌های قدیمی را دوباره پردازش کنید؟ → Kafka
آیا تیم کوچک دارید؟ → RabbitMQ یا Redis، نه Kafka

مثال واقعی: PyCourse از کدام استفاده می‌کند؟

در PyCourse هم دقیقاً همین انتخاب‌ها را کردیم:

Redis برای: notification های realtime (WebSocket channel layer)، cache مقالات و داشبورد

Celery + Redis (به عنوان broker) برای: ارسال OTP، پردازش حذف پس‌زمینه تصویر

Kafka نداریم — چون با صد کاربر، Kafka overhead بیهوده‌ای اضافه می‌کند. اگر به ده‌هزار کاربر برسیم، RabbitMQ یا Kafka را بررسی می‌کنیم.

بزرگ‌ترین تغییر ۲۰۲۶: Kafka بدون ZooKeeper

اگر در ۲۰۲۴ با Kafka کار کرده باشید، می‌دانید که راه‌اندازی آن به ZooKeeper نیاز داشت — یک سرویس جداگانه فقط برای مدیریت metadata. این دو سرویس را باید به صورت موازی نگه می‌داشتید.

Kafka 4.0 در ژانویه ۲۰۲۶ این مشکل را حل کرد: KRaft (Kafka Raft) جایگزین ZooKeeper شد. حالا Kafka خودش metadata خود را مدیریت می‌کند. راه‌اندازی و نگهداری بسیار ساده‌تر شد.

💻 BASH — راه‌اندازی Kafka 4.3 بدون ZooKeeper با Docker

# docker-compose.yml
services:
  kafka:
    image: apache/kafka:4.3.0
    ports:
      - "9092:9092"
    environment:
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      # بدون ZooKeeper — KRaft مستقیم

  rabbitmq:
    image: rabbitmq:4-management
    ports:
      - "5672:5672"
      - "15672:15672"  # management UI

  redis:
    image: redis:8-alpine
    ports:
      - "6379:6379"

ترکیب هر سه — معماری واقعی

در پروژه‌های بزرگ اغلب هر سه با هم استفاده می‌شوند — هر کدام برای کاری که در آن بهترین است:

این معماری در شرکت‌هایی مثل Uber و Netflix واقعی است.

🐍 PYTHON — معماری ترکیبی — هر ابزار سر جای خودش

# ── Redis: notification فوری ──────────────────
import redis
r = redis.Redis()
r.publish("live-notifications", json.dumps({
    "user_id": 1042,
    "message": "سفارش شما ارسال شد"
}))
# کاربر بلافاصله در مرورگر می‌بیند

# ── RabbitMQ/Celery: task های مطمئن ────────────
@shared_task(bind=True, max_retries=5)
def process_payment(self, order_id):
    # اگر خطا دهد، 5 بار retry می‌کند
    # هیچ پرداختی گم نمی‌شود
    payment_gateway.charge(order_id)

# ── Kafka: event streaming برای analytics ──────
producer.send("user-behavior", {
    "event": "page_view",
    "user_id": 1042,
    "page": "/products/55",
    "duration_seconds": 45
})
# تیم data science این stream را real-time تحلیل می‌کند
# recommendation engine از همین data یاد می‌گیرد

از Kafka قبل از اینکه واقعاً نیاز داشته باشید استفاده نکنید. بسیاری از تیم‌ها Kafka را خیلی زود وارد می‌کنند و بیشتر وقتشان صرف نگهداری آن می‌شود تا ساختن محصول.

— Martin Kleppmann · نویسنده Designing Data-Intensive Applications

جمع‌بندی

ابزار	یک جمله	بهترین کاربرد
Redis	سریع‌ترین، ساده‌ترین	notification، cache، session
RabbitMQ	قابل‌اعتمادترین	task queue، پرداخت، ایمیل
Kafka	قدرتمندترین	event streaming، analytics، log

Redis را انتخاب کنید اگر: سادگی و سرعت مهم‌تر از persistence است
RabbitMQ را انتخاب کنید اگر: هر پیام باید دقیقاً یک بار پردازش شود
Kafka را انتخاب کنید اگر: میلیون‌ها event، چندین consumer، نیاز به replay
اگر مطمئن نیستید: با RabbitMQ شروع کنید — ساده‌تر است و بعداً می‌توانید مهاجرت کنید
Kafka 4.0+ دیگر به ZooKeeper نیاز ندارد — راه‌اندازی آسان‌تر شده

💫

قانون طلایی انتخاب

با ساده‌ترین ابزار شروع کنید. Redis دارید؟ از Redis Streams استفاده کنید. وقتی به محدودیت رسیدید، به RabbitMQ بروید. وقتی به ۱۰۰K+ پیام در ثانیه رسیدید یا به replay نیاز داشتید، Kafka را بررسی کنید.

🤍 لایک