Bài 1

Khái niệm cốt lõi

RabbitMQ là một message broker mã nguồn mở triển khai chuẩn AMQP 0-9-1. Nó đứng giữa các service để nhận, lưu tạm và định tuyến message — giúp các phần của hệ thống giao tiếp bất đồng bộ, tách rời nhau (decoupling). Bài này nắm vững các thành phần và luồng đi của một message.

RabbitMQ là gì
Smart broker theo chuẩn AMQP

RabbitMQ là một message broker: phần mềm trung gian nhận message từ bên gửi (producer/publisher) và chuyển tới bên nhận (consumer). Thay vì service A gọi trực tiếp service B, A chỉ cần "ném" message vào broker rồi quên đi; B lấy message ra xử lý khi rảnh. Nhờ vậy hai bên không cần online cùng lúc, không cần biết nhau, và có thể scale độc lập.

RabbitMQ nói "ngôn ngữ" AMQP (Advanced Message Queuing Protocol) — một giao thức nhị phân chuẩn hóa cách publish, route, lưu và nhận message. Đặc trưng của RabbitMQ là smart broker / dumb consumer: broker gánh phần logic định tuyến phức tạp, còn consumer chỉ việc nhận và xử lý.

Decoupling: producer và consumer chỉ "biết" tới broker, không biết tới nhau. Thêm/bớt consumer, thay đổi xử lý phía nhận đều không ảnh hưởng tới phía gửi.
Luồng đi của một message
Producer → Exchange → Queue → Consumer

Điểm dễ nhầm nhất với người mới: producer KHÔNG gửi thẳng vào queue. Producer luôn gửi message vào một exchange. Exchange căn cứ vào loại của nó cùng các bindingrouting key để quyết định sao chép message vào (các) queue phù hợp. Consumer lắng nghe trên queue để nhận message.

Luồng message RabbitMQ — Producer đến Consumer Scroll / zoom · Mở draw.io ↗
Các thành phần
Từ vựng cần thuộc lòng
Thành phầnVai trò
ConnectionKết nối TCP giữa ứng dụng và broker. Tốn kém, nên giữ lâu dài và dùng lại.
ChannelKênh ảo (lightweight) chạy bên trong một connection. Mọi thao tác publish/consume đều qua channel — cho phép nhiều luồng dùng chung một connection TCP.
ExchangeNơi producer gửi message vào. Định tuyến message tới queue dựa trên loại exchange + binding + routing key.
QueueBộ đệm (buffer) lưu message theo thứ tự FIFO cho tới khi consumer lấy ra. Là nơi message thực sự "nằm chờ".
BindingQuy tắc liên kết exchange với queue, thường kèm một binding key, cho broker biết message nào chảy vào queue nào.
MessageDữ liệu gửi đi: gồm body (payload, dạng byte) và properties/headers (routing key, delivery_mode, content_type...).
ConsumerỨng dụng đăng ký nhận message từ queue và xử lý chúng.
Ack (acknowledgement)Tín hiệu consumer báo "đã xử lý xong" để broker xóa message khỏi queue. Chưa ack thì broker giữ lại để giao lại nếu consumer chết.
RabbitMQ vs Kafka
Hai triết lý khác nhau

Cả hai đều xử lý message nhưng sinh ra cho mục đích khác nhau. Hiểu rõ điểm khác biệt giúp chọn đúng công cụ.

Tiêu chíRabbitMQKafka
Mô hìnhSmart broker / dumb consumer — broker lo định tuyếnDumb broker / smart consumer — consumer tự quản offset
Lưu trữXóa message sau khi đã ack (queue là buffer tạm)Giữ message theo retention (vd 7 ngày) dù đã đọc
Thứ tựFIFO trong một queueĐảm bảo thứ tự trong từng partition
ReplayKhông (message đã ack thì mất)Có — đọc lại từ offset bất kỳ trong retention
Định tuyếnRất linh hoạt qua exchange (direct/topic/fanout/headers)Đơn giản theo topic/partition
Use caseTask queue, RPC, công việc nền, định tuyến phức tạpEvent streaming, log, pipeline dữ liệu lớn, replay
Khi nào chọn RabbitMQ: cần phân phối công việc cho nhiều worker (task queue), cần định tuyến message linh hoạt theo nhiều tiêu chí, cần RPC/giao tiếp bất đồng bộ giữa các microservice, hoặc cần độ trễ thấp và cơ chế ack/retry tinh vi cho từng message. Chọn Kafka khi cần lưu trữ lâu, replay, và throughput cực lớn cho event streaming.
← Quay lại
Tổng quan RabbitMQ