Tổng hợp 51 câu hỏi phỏng vấn RabbitMQ kèm đáp án chi tiết, song ngữ Việt–Anh — sắp xếp từ cơ bản đến nâng cao. Ôn luyện miễn phí, tự động lưu tiến độ.
RabbitMQ là message broker mã nguồn mở, cho phép các ứng dụng giao tiếp bất đồng bộ thông qua một broker trung gian thay vì gọi trực tiếp lẫn nhau. Dùng khi cần decouple các service, xử lý tác vụ nền như gửi email, resize…
AMQP (Advanced Message Queuing Protocol) là giao thức nhị phân tiêu chuẩn hoá cho message-oriented middleware, giúp các ứng dụng và ngôn ngữ lập trình khác nhau có thể giao tiếp đáng tin cậy. Nó giải quyết vấn đề vendor lock-in và không tương thích:…
Gọi API trực tiếp (REST, gRPC) yêu cầu cả hai service phải đang chạy đồng thời và biết nhau, tạo ra tight coupling — nếu service B chết thì service A cũng lỗi theo. Message broker đứng ở giữa: service A gửi message vào broker…
Kiến trúc RabbitMQ gồm: Producer (ứng dụng gửi message), Exchange (nhận message từ producer và định tuyến chúng), Queue (lưu trữ message chờ được consume), Consumer (ứng dụng nhận và xử lý message), và Binding (quy tắc kết nối exchange với queue). Hình dung như…
Queue là buffer lưu trữ message do producer gửi, chờ consumer lấy và xử lý. Message được giao theo thứ tự FIFO (vào trước ra trước), dù RabbitMQ cũng hỗ trợ priority queue. Một queue có thể có nhiều consumer, RabbitMQ phân phối message theo…
Producer là ứng dụng tạo và gửi message vào RabbitMQ, thường do một sự kiện nào đó kích hoạt (user đăng ký, đặt hàng, v.v.). Consumer là ứng dụng nhận và xử lý message từ queue. Một ứng dụng hoàn toàn có thể đóng cả…
Binding là quy tắc kết nối exchange với queue, xác định khi nào message được định tuyến từ exchange đến queue đó. Binding dùng một routingkey (chuỗi string) làm tiêu chí so khớp — ví dụ: bind queue "orders" vào exchange "direct" với routingkey "neworder",…
routingkey là nhãn string gắn vào message, exchange dùng nó để quyết định queue nào nhận message. Producer chỉ định routingkey khi publish (ví dụ "user.created.vn"), exchange so khớp với các binding rule và chỉ giao đến queue nào có rule phù hợp. Các loại…
Exchange là "bộ não" phân phối message: nhận message từ producer và định tuyến đến các queue phù hợp dựa trên binding và routingkey. Producer không bao giờ gửi trực tiếp vào queue — luôn publish lên exchange, sau đó exchange quyết định message đi…
Connection là một TCP socket giữa ứng dụng và RabbitMQ broker. Channel là "kết nối ảo" nhẹ, chạy multiplexed trên một TCP connection — bạn mở một connection duy nhất nhưng tạo nhiều channel trên đó để tránh overhead của nhiều TCP connection. Mỗi channel…
Message persistence nghĩa là RabbitMQ ghi message xuống disk thay vì chỉ giữ trong RAM. Khi publish với "delivery mode: persistent", message được ghi ngay lập tức, đảm bảo không mất dù broker crash trước khi consumer xử lý. Message không persistent (mặc định) chỉ…
Acknowledgment là cách consumer báo cho RabbitMQ biết "tôi đã nhận và xử lý xong message này, bạn có thể xoá nó đi". Mặc định là auto-ack — RabbitMQ gửi xong là coi như done. Best practice là manual ack: consumer xử lý xong mới…
Virtual host là một nhóm logic bên trong một RabbitMQ broker, cách ly hoàn toàn với các vhost khác — mỗi vhost có users, permissions, exchanges, queues, và policies riêng. Giống như có nhiều RabbitMQ broker độc lập trên cùng một máy chủ, rất hữu…
Khi queue không có consumer, message vẫn tiếp tục đến và tích luỹ trong queue vô thời hạn (hoặc đến khi hết TTL). Đây là thiết kế bình thường — queue sinh ra để buffer message khi consumer tạm thời không available. Tuy nhiên trong…
Message là đơn vị dữ liệu được truyền qua RabbitMQ, gồm hai phần: payload (dữ liệu thực — JSON, binary, text, v.v.) và metadata (headers, properties như delivery mode, correlation ID, timestamp, v.v.). RabbitMQ coi payload là mảng byte thô (opaque) — không inspect hay…
Dùng message queue cho các tác vụ bất đồng bộ không cần response ngay (gửi email, xử lý ảnh, ghi log analytics) hoặc khi cần buffer để hấp thụ traffic spike. Dùng API call trực tiếp cho các thao tác đồng bộ cần phản hồi…
Có 4 loại exchange chính: (1) Direct — định tuyến dựa trên exact match routingkey, dùng phân phối task đến worker cụ thể; (2) Fanout — broadcast mọi message đến tất cả queue đã bind bất kể routingkey, dùng cho notification; (3) Topic — định…
Direct exchange định tuyến message dựa trên khớp chính xác routingkey — so sánh routingkey của message với routingkey của binding, chỉ queue nào có binding khớp chính xác mới nhận được. Ví dụ: gửi message với routingkey "user.created" thì chỉ queue bind với routingkey…
Fanout exchange bỏ qua hoàn toàn routingkey và broadcast mọi message đến tất cả queue đã bind, tạo giao tiếp one-to-many. Nếu có 3 queue bind vào fanout exchange, mỗi queue nhận một bản sao y hệt của mọi message. Fanout lý tưởng cho notification:…
Topic exchange định tuyến message dùng wildcard pattern: khớp đúng một từ, khớp không hoặc nhiều từ. Ví dụ: pattern "user." khớp "user.created" và "user.deleted" nhưng không khớp "user.profile.updated"; trong khi "user." khớp cả ba. Topic exchange hợp với hệ thống event phân cấp —…
Headers exchange bỏ qua routingkey và định tuyến dựa trên header attributes của message. Khi bind, bạn chỉ định các header matching rule như "department: sales" và "urgent: true", message chỉ được route nếu header của nó match với criteria đó. Linh hoạt hơn routingkey…
Hoàn toàn có thể. Nhiều queue có thể bind vào cùng một exchange với các routingkey hoặc pattern khác nhau, tạo ra fan-out behavior — một message đến nhiều queue. Ví dụ: event "user.created" có thể gửi đến cả queue "emailnotifications" lẫn queue "analytics", mỗi…
Message bị âm thầm discard — RabbitMQ không có chỗ nào để route nó vì không có queue nào bound để nhận. Đây không hẳn là lỗi (có thể là chủ ý), nhưng thường là dấu hiệu misconfiguration hoặc consumer chưa start và chưa tạo…
"user." khớp đúng một từ sau "user" — match "user.created", "user.deleted" nhưng KHÔNG match "user.profile.updated". "user." khớp không hoặc nhiều từ sau "user" — match "user.created", "user.profile.updated", và thậm chí chỉ "user" không. Dùng khi muốn segment chính xác (event type cụ thể); dùng cho…
Dùng quy ước đặt tên rõ ràng và phân cấp: exchange nên phản ánh type hoặc domain (ví dụ: "events", "tasks", "notifications"), routingkey nên phản ánh resource hierarchy (ví dụ: "user.created", "order.payment.failed", "inventory.stock-low"). Tránh tên chung chung như "message" hay "data". Dùng lowercase và dấu…
Exchange là router message — nhận từ producer và quyết định message đi đâu dựa trên routing logic. Queue là buffer message — lưu trữ và chờ consumer lấy. Exchange không lưu trữ gì cả; queue mới lưu. Luồng message: Producer → Exchange → Queue…
Dead-letter exchange (DLX) là exchange đặc biệt nhận các message không thể xử lý được. RabbitMQ route message đến DLX khi: (1) basic.reject / basic.nack với requeue=false, (2) message hết TTL, (3) queue vượt max-length. RabbitMQ không tự track retry count — đó là logic…
Prefetch count (QoS setting) giới hạn số message chưa ack mà RabbitMQ gửi cho consumer cùng lúc — nếu prefetch là 1, broker chờ ack trước khi gửi message tiếp. Prefetch cao (ví dụ 1000) cho throughput nhanh hơn nhưng tốn bộ nhớ và rủi…
TTL (Time To Live) là thuộc tính message chỉ định thời gian message tồn tại trong queue trước khi hết hạn và bị discard (hoặc gửi đến dead-letter exchange). Dùng khi message trở nên stale — ví dụ: token "password reset" chỉ hợp lệ 1…
Priority queue cho phép gán mức ưu tiên cho message, message priority cao được consume trước. Khai báo queue với x-max-priority (khuyến nghị ≤ 10 để tránh overhead). Priority hợp lệ của message là từ 0 đến giá trị x-max-priority khai báo — không phải…
RabbitMQ không tự retry message bị lỗi — đó là nhiệm vụ của consumer. Các pattern phổ biến: (1) Nack + requeue: consumer bắt exception, gửi nack với requeue=true, message quay lại queue (cần cẩn thận để tránh loop vô hạn). (2) Dead-letter + retry:…
Persistent message có delivery mode 2, được ghi xuống disk, survive broker crash/restart — an toàn nhưng chậm hơn do disk I/O. Transient message có delivery mode 1, chỉ sống trong RAM, mất khi broker crash — nhanh nhưng rủi ro. Dùng persistent cho dữ…
Publisher confirms giống consumer ack nhưng ở phía producer: khi bật, RabbitMQ gửi ack cho producer sau khi message được route vào queue (hoặc persist nếu durable). Không có confirms, producer không có guarantee message đến được broker. Với confirms, producer chờ (hoặc handle async)…
RabbitMQ có hai cơ chế backpressure độc lập: (1) Memory watermark (mặc định 40% RAM): khi đạt ngưỡng, broker dừng nhận publish mới và block connection. (2) Disk free space alarm (mặc định 50MB free): khi disk sắp đầy, broker cũng block publishing — độc…
Trong môi trường high-throughput, nên dùng TCP connection riêng: một cho producer, một cho consumer. Khi dùng chung connection, backpressure từ phía producer (quá nhiều message) có thể block consumer gửi ack về broker, gây deadlock. Với connection riêng, consumer ack độc lập không bị…
Work queue pattern phân phối các tác vụ chạy lâu cho nhiều worker: producer gửi task vào một queue duy nhất, nhiều consumer cùng lắng nghe, RabbitMQ round-robin message giữa chúng. Nếu worker crash giữa chừng, message requeue sang worker khác. Dùng cho: resize ảnh,…
Pub/sub pattern broadcast cùng một message đến nhiều consumer độc lập: producer gửi lên fanout hoặc topic exchange, nhiều queue bind vào đó, mỗi queue gửi bản sao của mình đến consumer riêng. Khác work queue — pub/sub nhân bản message, không chia. Dùng cho:…
RPC pattern thực hiện request-response qua RabbitMQ thay vì REST đồng bộ: client gửi message vào server queue kèm replyto (tên temporary queue) và correlationid (định danh duy nhất), server xử lý và publish kết quả vào replyto queue, client nhận response từ đó. Tối…
Có ba cách, chọn theo độ phức tạp bạn chấp nhận. 1. TTL + dead-letter exchange (không cần plugin). Đẩy message vào một queue "chờ" không có consumer, đặt x-message-ttl = 30 phút và trỏ x-dead-letter-exchange sang exchange xử lý thật. Hết TTL, message tự…
Poison message là message luôn làm consumer lỗi. Vì consumer không ack, broker giao lại, consumer lại lỗi — tạo vòng lặp vô hạn chiếm trọn công suất consumer và các message hợp lệ phía sau bị đói. Nguyên nhân thường gặp: payload sai schema,…
