RabbitMQ vs Kafka: chọn cái nào cho bài toán nào

Câu này gần như chắc chắn gặp khi phỏng vấn. Đừng trả lời "Kafka nhanh hơn". Hãy trả lời theo mô hình dữ liệu: RabbitMQ hỏi "ai sẽ xử lý việc này?", Kafka hỏi "chuyện gì đã xảy ra?".

1. Bài toán: shop-app có nhiều kiểu message

a) OrderCreated → inventory, notification, analytics, fraud (thêm sau)
b) Gửi email xác nhận: một job, gửi một lần, retry có delay
c) Xuất hóa đơn PDF: job nặng, đơn VIP được ưu tiên
d) Clickstream người dùng: 50.000 event/giây, lưu 30 ngày để phân tích lại
e) Gọi "tính phí ship" và chờ kết quả (request/reply)

2. Vấn đề: một công cụ cho tất cả thường gượng

• Dùng RabbitMQ cho (d): queue phình to, message bị xóa sau ACK nên không phân tích lại được.
• Dùng Kafka cho (c): không có priority, không có delay từng message; một job chậm chặn cả partition.
• Dùng Kafka cho (e): làm được nhưng vụng; REST/gRPC hoặc RabbitMQ RPC tự nhiên hơn.

3. Giải pháp: hiểu bản chất của từng bên

4. Code: cùng event, hai cách publish trong Spring

RabbitMQ (bài 8.2):

rabbitTemplate.convertAndSend("order.exchange", "order.created", event);
// routing key quyết định queue nào nhận

Kafka (bài 8.6):

kafkaTemplate.send("orders", event.orderId(), event);
// key quyết định partition; group quyết định ai nhận

Dùng cả hai trong shop-app là chuyện bình thường:

spring:
  kafka:
    bootstrap-servers: ${KAFKA_BOOTSTRAP}
  rabbitmq:
    host: ${RABBIT_HOST}
    username: ${RABBIT_USER}
    password: ${RABBIT_PASSWORD}

@KafkaListener(topics = "orders", groupId = "notification-service")
public void onOrder(OrderEvent event) {
    if ("ORDER_CREATED".equals(event.type())) {
        // chuyển "sự kiện" thành "công việc" có retry/delay riêng
        rabbitTemplate.convertAndSend("email.exchange", "email.confirm",
                new SendEmailJob(event.eventId(), event.orderId()));
    }
}

5. Cách hoạt động: hai mô hình

RabbitMQ: "Ai sẽ XỬ LÝ việc này?"           Kafka: "Chuyện gì ĐÃ XẢY RA?"

Producer                                    Producer
   │                                           │ key=orderId
   ▼                                           ▼
Exchange ──binding──▶ Queue A ─▶ C1,C2       Topic orders
        └─binding──▶ Queue B ─▶ C3           P0 [0][1][2][3] ...
                                             P1 [0][1][2] ...
ACK → message xóa                             ▲          ▲
                                       group A offset  group B offset
                                       (record vẫn còn, có thể replay)

6. Quyết định cho từng bài toán shop-app

7. Khi nào nên dùng / không nên dùng

• RabbitMQ: task/job queue, routing phức tạp, priority, delay, request/reply, lưu lượng vừa, team nhỏ.
• Kafka: event-driven giữa nhiều service, event sourcing/CDC, stream processing, replay, throughput lớn.
• Không nên: chọn Kafka chỉ vì "nghe xịn" cho vài trăm job/ngày; chi phí vận hành cluster và thiết kế partition không đáng.

Đúng, chữ "partition" xuất hiện ở nhiều nơi nhưng ý nghĩa khác nhau một chút:

Ý tưởng chung: chia dữ liệu để phân phối. Nhưng Kafka partition còn gánh thêm hai vai: đơn vị song song cho consumer group và phạm vi thứ tự. Redis hash slot và DB sharding chủ yếu trả lời "dữ liệu này nằm ở node nào?".

Được. Gộp lại theo câu hỏi "chia tải bằng gì, giữ thứ tự ở đâu":

Lưu ý: Redis cũng có Pub/Sub và Streams, nhưng trong shop-app ta dùng Redis cho cache/lock, còn messaging giao cho RabbitMQ và Kafka.

Q1. Khác biệt cốt lõi giữa RabbitMQ và Kafka?

🇻🇳 Tiếng Việt:

RabbitMQ là message broker hướng task: producer gửi vào exchange, exchange route vào queue, consumer ACK thì message bị xóa. Kafka là distributed log hướng event: record được append vào partition, giữ theo retention, mỗi consumer group tự quản lý offset nên có thể replay. RabbitMQ mạnh về routing linh hoạt; Kafka mạnh về throughput, lưu trữ và thứ tự theo key.

🇬🇧 English:

RabbitMQ is a task-oriented message broker: producers publish to an exchange, the exchange routes to queues, and a message is removed once the consumer acknowledges it. Kafka is an event-oriented distributed log: records are appended to partitions and kept by retention, and each consumer group tracks its own offsets, so replay is possible. RabbitMQ shines at flexible routing; Kafka shines at throughput, storage and per-key ordering.

Q2. Trong dự án, em chọn thế nào?

🇻🇳 Tiếng Việt:

Trong shop-app, event đơn hàng đi qua Kafka với key là orderId, vì nhiều service cần đọc, cần giữ thứ tự theo đơn và có thể replay khi analytics sửa bug. Còn job gửi email và xuất hóa đơn đi qua RabbitMQ vì cần retry có delay bằng DLX, priority và ACK từng message. Hai công cụ bổ sung cho nhau, không loại trừ nhau.

🇬🇧 English:

In our shop app, order events go through Kafka keyed by orderId, because many services consume them, ordering per order matters, and we can replay when analytics fixes a bug. Email and invoice jobs go through RabbitMQ because we need delayed retries with DLX, priorities and per-message acknowledgements. The two tools complement each other rather than compete.

Q3. Cả hai đều đảm bảo exactly-once?

🇻🇳 Tiếng Việt:

Thực tế cả hai đều cho at-least-once khi cấu hình đúng: publisher confirm và manual ACK ở RabbitMQ, acks=all và commit sau xử lý ở Kafka. Kafka có exactly-once nhưng chỉ trong phạm vi Kafka. Nên dù chọn cái nào, consumer có side effect vẫn phải idempotent.

🇬🇧 English:

In practice both give at-least-once when configured correctly: publisher confirms and manual acks in RabbitMQ, acks=all and commit-after-processing in Kafka. Kafka offers exactly-once, but only within Kafka. So whichever we choose, consumers with side effects must be idempotent.

Cách nhớ ngắn gọn

• RabbitMQ = "ai làm việc này?" → exchange, queue, ACK xóa.
• Kafka = "chuyện gì đã xảy ra?" → topic, partition, offset, replay.
• Routing/priority/delay → RabbitMQ. Throughput/replay/thứ tự theo key → Kafka.
• Cả hai: at-least-once + idempotent consumer.

Tổng kết chương 8: Messaging