Message Queue: Kiến trúc bất đồng bộ

Bạn có biết?

Khách hàng vừa đặt hàng — bạn phải gửi email xác nhận, gọi SMS, cập nhật kho, tính điểm tích lũy, thông báo cho bộ phận giao hàng. Nếu làm tất cả đồng bộ trong request đặt hàng, API của bạn chậm gấp 5 lần — và chỉ cần dịch vụ email chậm 2 giây là cả đơn hàng treo. Message Queue đảo ngược cách nghĩ: API chỉ xác nhận đơn hàng, mọi việc còn lại diễn ra nền — nhanh, chắc chắn, và các thành phần không còn phụ thuộc nhau.

Queue giải quyết 3 bài toán lớn

• Bất đồng bộ (async) — request trả về ngay, việc nặng chạy nền: API nhanh, user không chờ
• Giảm ghép nối (decoupling) — producer không cần biết consumer là ai, ở đâu, có bao nhiêu cái. Email service sập → đơn hàng vẫn được đặt, message nằm chờ trong queue
• Chịu tải đột biến (load smoothing) — flash sale 100.000 đơn trong 1 phút: queue hấp thụ, consumer xử lý đều theo khả năng (backpressure)

Kiến trúc cơ bản

[API / Producer] --publish--> [Queue] --consume--> [Worker / Consumer]
                                      |
                                      +--> [Worker 2]
                                      +--> [Worker 3]  (scale ngang consumer)

• Producer — gửi message vào queue (vd: "đơn hàng 123 đã đặt")
• Queue — nơi message chờ, bền vững (message không mất khi consumer chết)
• Consumer/Worker — nhận message, xử lý, báo thành công (ack)

Vòng đời message: publish → nằm queue → consumer nhận → ack (xác nhận xong) → xóa. Consumer xử lý fail không ack → message quay lại queue cho lần thử sau. Chính cơ chế ack tạo nên at-least-once: message có thể xử lý lại, nên consumer phải idempotent (xử lý 2 lần = xử lý 1 lần).

Chọn queue: Redis, RabbitMQ hay Kafka?

Quy tắc chọn: đã có Redis → bắt đầu với Redis Streams (xem bài Message Queue với Redis và Redis Streams); cần routing linh hoạt → RabbitMQ; cần replay, throughput cực cao, event sourcing → Kafka.

Tiêu chí	Redis List/Stream	RabbitMQ	Kafka
Mô hình	Queue đơn giản	Exchange/routing linh hoạt	Log phân tán, replay được
Độ bền