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 tách ghép (decouple) các service, xử lý tác vụ nền như gửi email, resize ảnh, và tăng độ tin cậy của hệ thống khi có lỗi xảy ra.
• Điểm khác biệt so với gọi API trực tiếp: nếu một service bị down, messages sẽ nằm đợi trong RabbitMQ cho đến khi service đó khôi phục.

AMQP (Advanced Message Queuing Protocol) là giao thức nhị phân tiêu chuẩn hóa 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: ứng dụng Python có thể gửi message mà ứng dụng Java consume được mà không cần tầng chuyển đổi riêng. AMQP đảm bảo tính interoperability giữa các client bất kể ngôn ngữ hay hệ điều hành.

RabbitMQ sử dụng AMQP 0-9-1 là protocol chính. AMQP 1.0 là tiêu chuẩn ISO hoàn toàn khác — được hỗ trợ trong RabbitMQ 4.0 (built-in, không cần plugin riêng).

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 mà không cần biết ai sẽ nhận, broker giữ message và giao khi consumer sẵn sàng.
• Điều này tạo loose coupling, service hoạt động độc lập, và tự nhiên xử lý được lỗi.
• Đánh đổi là độ phức tạp tăng thêm và latency cao hơn một chút, nhưng đổi lại được độ tin cậy và linh hoạt vượt trội.

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ư bưu cục: producer bỏ thư (message) vào bưu cục (exchange), nhân viên phân loại (binding) gửi vào hộp thư (queue), và bưu tá (consumer) giao thư đến tay người nhận.

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 round-robin mặc định để cân bằng tải.
• Message tồn tại trong queue cho đến khi được consumer acknowledge hoặc hết hạn TTL.

Producer là ứng dụng tạo và gửi message vào RabbitMQ, thường được kích hoạt bởi một sự kiện nào đó (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ả hai vai — ví dụ payment service consume message "order" và produce message "payment_processed" cho các service khác tiếp tục xử lý.

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 routing_key (chuỗi string) làm tiêu chí so khớp — ví dụ: bind queue "orders" vào exchange "direct" với routing_key "new_order", thì chỉ message có routing_key đó mới vào queue này.
• Không có binding, exchange không biết gửi message đi đâu.

routing_key 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 routing_key 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 khác nhau diễn giải routing_key theo cách khác: direct exchange cần khớp chính xác, topic exchange hỗ trợ wildcard.

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à routing_key.

• 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 đâu.
• Các loại exchange khác nhau (direct, topic, fanout, headers) thực hiện logic định tuyến khác nhau để hỗ trợ các pattern giao tiếp đa dạng.

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 hoạt động độc lập, gửi/nhận trên các queue khác nhau, rất hiệu quả cho ứng dụng multi-threaded.
• Best practice: dùng lại một connection với nhiều channel thay vì liên tục tạo connection mới.

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ỉ sống trong RAM — nhanh hơn nhưng sẽ mất khi crash.
• Dùng persistent cho dữ liệu quan trọng như thanh toán, đơn hàng; non-persistent cho notification không quan trọng lắm.

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ể xóa 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 gửi ack; nếu crash trước khi ack, RabbitMQ tự động giao lại message cho consumer khác.
• Đây là cơ chế cốt lõi đảm bảo không mất message khi consumer gặp sự cố.

Virtual host là một nhóm logic bên trong một RabbitMQ broker, cung cấp sự cách ly hoàn toàn — 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 ích cho ứng dụng multi-tenant.
• Một user chỉ có quyền truy cập vào các vhost được cấp phép, ngăn chặn các team can thiệp vào nhau.

Khi queue không có consumer, message vẫn tiếp tục đến và tích lũy 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 production cần monitor vì "zero consumer" thường báo hiệu worker pod bị crash hoặc bug trong startup logic.
• Đó là lý do cần alert khi "consumer count == 0" kéo dài.

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 không rõ nghĩa — không inspect hay sửa nội dung, ứng dụng tự chịu trách nhiệm serialize/deserialize.
• Message có thể rất nhỏ (vài byte) hoặc lớn (megabytes), nhưng message quá lớn sẽ ảnh hưởng performance.

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 ngay lập tức (đăng nhập, validate thanh toán, truy vấn dữ liệu).
• Thực tế hầu hết hệ thống dùng cả hai: REST cho critical path đồng bộ, RabbitMQ cho background task và event giữa các service.
• Message queue đánh đổi latency để lấy reliability và decoupling.

Có 4 loại exchange chính:

1. Direct — định tuyến dựa trên exact match routing_key, 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ể routing_key, dùng cho notification;
3. Topic — định tuyến theo pattern wildcard (* khớp một từ, # khớp không hoặc nhiều từ), dùng cho hệ thống event phân cấp;
4. Headers — định tuyến theo header attribute thay vì routing_key, dùng khi logic phức tạp

Thực tế hay dùng Direct và Topic nhất.

Direct exchange định tuyến message dựa trên khớp chính xác routing_key — so sánh routing_key của message với routing_key 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 routing_key "user.created" thì chỉ queue bind với routing_key "user.created" mới nhận, không phải "user.updated". Direct exchange phù hợp cho one-to-one communication hoặc phân phối các loại task khác nhau đến worker tương ứng.

Fanout exchange bỏ qua hoàn toàn routing_key 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: sự kiện "user signup" gửi đến cả email service, SMS service, và logging service cùng lúc.
• Đây là exchange đơn giản nhất vì logic định tuyến trivial — tất cả hoặc không có gì.

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 hoàn hảo cho hệ thống event phân cấp — subscribe "orders.#" để nhận mọi order event, hoặc "orders.payment." chỉ cho payment events. Tính linh hoạt này cho phép consumer subscribe có chọn lọc mà không cần tạo queue riêng cho từng loại.

Headers exchange bỏ qua routing_key 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 routing_key cho logic phức tạp, nhưng cũng đắt hơn — headers matching chậm hơn so khớp string.
• Trong thực tế headers exchange hiếm dùng; chỉ dùng khi logic routing thực sự không thể diễn đạt bằng routing_key pattern.

Hoàn toàn có thể. Nhiều queue có thể bind vào cùng một exchange với các routing_key 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 "email_notifications" lẫn queue "analytics", mỗi bên xử lý độc lập. Đây chính là cách implement publish-subscribe pattern — một exchange phân phối đến nhiều processing pipeline độc lập.

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 binding.
• Mặc định bạn không nhận được error gì — message biến mất.
• Để phát hiện: dùng publisher confirms (nhận ack khi message được route thành công) hoặc monitor "messages dropped due to no routes".

"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 subscription rộng (toàn bộ category).

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"), routing_key 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 chấm làm separator.
• Document rõ routing_key schema trong code comment hoặc file riêng để team hiểu architecture.
• Đặt tên nhất quán giúp hệ thống tự document và dễ mở rộng.

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 → Consumer.
• Bạn bind queue vào exchange để tạo routing rule.
• Không có queue, exchange không có chỗ nào để gửi message.

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 phía consumer, thường qua header x-death. Bạn bind một queue khác vào DLX để inspect lỗi, log, gửi alert, hoặc retry với logic khác

Ví dụ: consumer chính fail → message vào dead-letter queue → service phân tích riêng inspect và route đến human review queue.

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 ro mất nhiều message nếu consumer crash.
• Prefetch thấp (1) an toàn hơn, phân phối đều hơn nhưng latency cao hơn.
• Best practice: prefetch = số thread worker trong consumer (ví dụ prefetch 10 cho 10 thread), cân bằng giữa throughput và safety.

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 giờ, notification "giờ cao điểm" chỉ relevant 30 phút.
• Khi TTL hết, message bị xóa, tiết kiệm storage và ngăn consumer xử lý dữ liệu lỗi thời.
• Cấu hình TTL per-message (linh hoạt hơn) hoặc per-queue (đơn giản hơn).

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 luôn luôn 0-255.
• Dùng cho: request hỗ trợ của VIP user ưu tiên hơn user thường, critical system alert trước routine logging, tính năng paid tier trước free tier.
• Giữ x-max-priority thấp để tránh overhead lưu trữ và memory.

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: message fail → dead-letter queue → retry consumer đợi N giây rồi republish lên queue gốc.
3. Circuit breaker: phát hiện liên tục fail, tạm dừng consume, kiểm tra sau

Để cap số lần retry, consumer đọc header x-death — RabbitMQ populate header này mỗi khi message đi qua DLX.

Kết hợp manual ack, DLX, và monitoring tạo nên retry handling robust.

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ữ liệu critical (thanh toán, đơn hàng, user account), transient cho dữ liệu có thể thay thế (notification, analytics, cache invalidation).

Lưu ý: queue durable KHÔNG đủ — cần cả queue durable VÀ message persistent mới đảm bảo survive hoàn toàn.

Publisher confirms là tương đươ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) ack trước khi coi publish thành công — nếu timeout, retry.
• Đánh đổi: confirms tăng latency nhưng ngăn mất message ở phía producer.
• Dùng cho message critical (order, payment), bỏ qua cho non-critical (analytics).

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 lập với memory

Cả hai đều có thể block producer đồng thời.

Producer bị block sẽ gặp timeout, nên cần monitor queue depth và consumer lag để phòng ngừa.

Giải pháp: thêm consumer, tối ưu throughput consumer, hoặc tăng memory/disk broker.

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ị ảnh hưởng bởi producer flow.
• Với ứng dụng traffic thấp, một connection với nhiều channel là ổn.
• Best practice production: connection riêng cho publisher và consumer, mỗi bên có thread pool và connection pool phù hợp.

Work queue pattern phân phối các tác vụ dài hạn 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, gửi email, tạo report, xuất PDF.
• Implementation: producer → direct exchange → một queue; consumer dùng prefetch=1 để phân phối công bằng, manual ack để đảm bảo xử lý thành công, DLX cho message fail.
• Scale bằng cách thêm worker instance.

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: hệ thống notification (gửi email, SMS, push notification độc lập nhau), phân phối event, đồng bộ dữ liệu.
• Scale bằng cách thêm queue và consumer mới mà không cần sửa producer.

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 reply_to (tên temporary queue) và correlation_id (định danh duy nhất), server xử lý và publish kết quả vào reply_to queue, client nhận response từ đó.

• Tối ưu hiện đại: dùng "direct reply-to" (amq.rabbitmq.reply-to) để tránh overhead tạo queue.
• Phù hợp cho cross-service query khi RPC an toàn hơn REST (không timeout mạng), tích hợp async system với sync requirement.