- RabbitMQ là gì và khi nào nên dùng 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 là gì và nó giải quyết vấn đề gì?
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:…
- Message broker khác gì so với gọi API trực tiếp giữa các service?
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 của RabbitMQ gồm những thành phần nào?
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 trong RabbitMQ là gì?
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 và consumer khác nhau như thế nào?
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 trong RabbitMQ là gì?
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",…
- Routing key là gì và được dùng như thế nào?
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…
- Vai trò của exchange trong RabbitMQ là gì?
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 và channel trong RabbitMQ khác nhau như thế nào?
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…
- "Persistence" (tính bền vững) của message nghĩa là gì?
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 (ack) trong RabbitMQ là gì?
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 (vhost) trong RabbitMQ là gì?
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…
- Điều gì xảy ra khi queue không có consumer nào?
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 trong RabbitMQ bao gồm những gì?
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…
- Khi nào dùng message queue, khi nào dùng API call trực tiếp?
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ó mấy loại exchange trong RabbitMQ và mỗi loại dùng khi nào?
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 hoạt động như thế nào?
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 hoạt động như thế nào?
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 hoạt động như thế nào và khi nào nên dùng?
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 hoạt động như thế nào?
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…
- Nhiều queue có thể bind vào cùng một exchange không?
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…
- Điều gì xảy ra khi publish message lên exchange không có binding nào?
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…
- Pattern "user.*" và "user.#" trong topic exchange khác nhau như thế nà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…
- Nên đặt tên routing_key và exchange như thế nào cho dễ maintainable?
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 và queue khác nhau như thế nào?
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 là gì và dùng như thế nào?
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 là gì và ảnh hưởng như thế nào đến performance?
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…
- Message TTL là gì và dùng khi nào?
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 trong RabbitMQ là gì và khi nào nên dùng?
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…
- Làm thế nào để xử lý message bị lỗi và retry trong RabbitMQ?
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 và transient message khác nhau như thế nào?
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 là gì và tại sao nên dùng?
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 xử lý backpressure như thế nào?
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…
- Khi nào nên tách riêng connection của producer và consumer?
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 (task queue) pattern là gì?
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,…
- Publish-subscribe (pub/sub) pattern là gì?
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 với RabbitMQ hoạt động như thế nào?
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…
- Saga pattern là gì và hoạt động với RabbitMQ như thế nào?
- Outbox pattern là gì và tại sao cần dùng?
- Circuit breaker pattern áp dụng với RabbitMQ như thế nào?
- RabbitMQ liên quan đến event sourcing như thế nào?
- RabbitMQ clustering hoạt động như thế nào và đảm bảo high availability ra sao?
- Quorum queue là gì và tại sao tốt hơn mirrored queue?
- Làm thế nào để monitor RabbitMQ và những metric nào quan trọng?
- Queue depth là gì và xử lý như thế nào khi nó tăng?
- Làm thế nào để phát hiện và xử lý connection/channel leak?
- Làm thế nào để cấu hình resource limits trong RabbitMQ?
- RabbitMQ và Kafka khác nhau như thế nào?
- Cần gửi email nhắc sau 30 phút kể từ khi user đặt hàng — làm thế nào với message queue?
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à gì? Phát hiện và chặn nó bằng cách nào?
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,…
