Đáp án Quiz RabbitMQ — 37 câu hỏi có giải thích

Đáp án: B

Producer luôn publish vào exchange, không bao giờ vào queue trực tiếp. Exchange nhìn routing key của message và các binding để quyết định chuyển sang queue nào. Ngay cả khi code có vẻ "gửi vào queue", thực chất là gửi qua default exchange với routing key trùng tên queue.

Đáp án: C

Exchange = bộ định tuyến, queue = bộ đệm lưu trữ. Message đi producer → exchange → (theo binding) → queue → consumer. Exchange không giữ message; nếu không có queue nào nhận thì message biến mất chứ không nằm lại trong exchange.

Đáp án: C

Fanout. Nó sao chép message tới mọi queue đã bind và bỏ qua hoàn toàn routing key. Ghi nhớ nhanh 4 loại: direct = match key chính xác, topic = match theo pattern (*/#), fanout = broadcast tất cả, headers = match theo header của message.

Đáp án: C

Chỉ q_error. Direct exchange so khớp chính xác routing key của message (error) với binding key của từng queue. q_info bind với key info nên không nhận. Nếu nhiều queue cùng bind key error, tất cả đều nhận một bản sao.

Đáp án: B

Message mất. noAck: true (autoAck) nghĩa là broker coi message đã giao xong ngay khi đẩy ra socket — không chờ consumer xử lý. Consumer crash sau đó thì không còn gì để giao lại. Với việc quan trọng, dùng manual ack: chỉ ch.ack(msg) sau khi xử lý xong.

Đáp án: D

Round-robin: message thứ n cho consumer A, thứ n+1 cho consumer B, xoay vòng đều — mỗi message chỉ giao cho một consumer. Đây chính là mô hình work queue (competing consumers): thêm consumer là tăng khả năng xử lý song song.

Đáp án: D

Chỉ trong một queue với một consumer. Nhiều consumer cùng đọc một queue thì message được chia round-robin, mỗi consumer xử lý nhanh chậm khác nhau nên thứ tự hoàn thành không còn được đảm bảo.

Đáp án: D

Broker requeue toàn bộ message chưa ack và giao lại cho consumer còn sống. Lần giao lại có cờ redelivered=true — dấu hiệu message này có thể đã được xử lý một phần trước đó.

Đáp án: C

DLX là exchange nhận các message bị loại khỏi queue — thay vì biến mất, chúng được định tuyến sang một queue khác để điều tra hoặc retry. Khai báo qua argument x-dead-letter-exchange trên queue gốc.

Đáp án: D

"Unacked" = message đã được giao cho consumer nhưng chưa nhận được ack. "Ready" = message còn nằm trong queue chờ giao. Tổng của hai cột là depth thật của queue. Unacked cao bất thường là dấu hiệu consumer xử lý chậm hoặc quên gọi ack.

Đáp án: D

Vhost là không gian cô lập logic trong một broker: mỗi vhost có queue, exchange, binding, user permission riêng, và tài nguyên trùng tên giữa hai vhost không liên quan gì nhau. Tương tự database trong một PostgreSQL server. Dùng để tách môi trường (staging/dev) hoặc tách team/ứng dụng dùng chung broker.

Đáp án: B

Chỉ q2. Trong topic exchange: * thay đúng một từ (từ = đoạn giữa hai dấu chấm), # thay không hoặc nhiều từ. order.payment.failed có hai từ sau order nên order.* trượt, còn order.# khớp. Nếu publish order.created thì cả hai queue đều nhận.

Đáp án: B

Message bị drop âm thầm — không lỗi, không cảnh báo. Producer muốn biết thì phải bật cờ mandatory (broker trả message về qua basic.return) hoặc cấu hình alternate exchange để hứng message unroutable sang một queue riêng.

Đáp án: B

Poison message loop: message lỗi vĩnh viễn (sai định dạng, thiếu field) sẽ được giao lại ngay và lỗi tiếp, chiếm CPU và làm ngập log vô hạn — RabbitMQ không có backoff hay giới hạn số lần giao lại mặc định. Lỗi vĩnh viễn thì nack với requeue=false kèm dead-letter exchange.

Đáp án: A

Không set prefetch, broker đẩy message không giới hạn cho consumer: một consumer ôm hàng nghìn message unacked trong bộ nhớ trong khi consumer khác ngồi không, và consumer đó crash thì tất cả phải giao lại. prefetch(n) giới hạn tối đa n message chưa ack trên mỗi consumer — hết hạn mức thì broker chờ ack rồi mới giao tiếp.

Đáp án: A, B

Cần CẢ HAI: queue durable và message persistent (delivery_mode=2, trong amqplib là { persistent: true }). Thiếu một trong hai là mất: queue không durable thì cả queue biến mất; message không persistent thì queue còn nhưng ruột rỗng.

Đáp án: B

Mỗi service một queue riêng, cả ba bind vào một fanout exchange — mỗi message được nhân bản vào cả ba queue. Quy tắc nền tảng: trong MỘT queue, các consumer chia nhau message (work queue); muốn ai cũng nhận đủ (pub/sub) thì tách queue. Trong một service vẫn scale nhiều instance cùng đọc chung queue của service đó.

Đáp án: B

Broker đã nhận message và chịu trách nhiệm về nó — với message persistent trên queue durable, confirm chỉ bắn sau khi đã ghi đĩa. Không có confirm, publish là fire-and-forget: mạng đứt giữa chừng là mất message mà producer không hề biết.

Đáp án: D

Vì RabbitMQ giao at-least-once: consumer xử lý xong nhưng ack chưa tới broker (chết, mạng đứt) thì message được giao lại và bị xử lý lần hai. Cách chống chuẩn: gắn message id duy nhất khi publish, consumer lưu id đã xử lý và bỏ qua id trùng.

Đáp án: C, D, E

Ba đường vào DLX: reject/nack với requeue=false, hết TTL, và queue tràn max-length. Mất kết nối thì message được requeue chứ không dead-letter — phân biệt hai đường đi này là điểm hay bị nhầm.

Đáp án: D

Dùng delay queue: một queue chờ không có consumer, đặt x-message-ttl=30000 và x-dead-letter-exchange trỏ về exchange của queue chính. Message lỗi được publish vào queue chờ, nằm đó 30 giây, hết TTL thì broker tự dead-letter nó quay về queue chính.

Đáp án: A

Mọi lỗi đều bị nack(msg, false, true) — tức requeue vô điều kiện. Message hỏng dữ liệu (JSON sai) sẽ lỗi lại y hệt, tạo vòng lặp poison message chiếm CPU và chặn queue. Cần tách lỗi vĩnh viễn (requeue=false, đi DLX) khỏi lỗi tạm thời.

Đáp án: C

x-message-ttl là hạn sống của từng message: quá hạn thì bị loại (dead-letter nếu có DLX). x-expires là hạn sống của cả queue: không có consumer và không ai đụng tới trong khoảng đó thì broker xoá luôn queue, kèm toàn bộ message bên trong.

Đáp án: A

Mặc định là drop-head: message cũ nhất bị loại để nhường chỗ cho message mới — producer không hề được báo. Nếu queue có DLX, message bị loại sẽ được dead-letter với reason maxlen thay vì mất hẳn.

Đáp án: C

Cho message ra đĩa sớm thay vì giữ trong RAM. Trước đây là x-queue-mode=lazy; từ RabbitMQ 3.12, classic queue mặc định đã hành xử kiểu lazy (giữ trong RAM chỉ phần nhỏ sắp giao), còn quorum queue tự quản lý bộ nhớ tương tự. Backlog triệu message khi đó chỉ tốn đĩa, không kéo node vào vùng memory alarm.

Đáp án: B

Chọn RabbitMQ khi bài toán là hàng đợi công việc: mỗi message được một worker xử lý rồi biến mất, cần routing phức tạp (topic/headers exchange), priority, TTL, ack từng tin. Chọn Kafka khi dữ liệu là event log cần giữ lại để replay, nhiều consumer độc lập, thông lượng rất lớn.

Đáp án: D

Channel là kênh ảo multiplex trên một TCP connection. Mở connection mới tốn TCP + TLS handshake và tài nguyên ở broker, còn mở channel gần như miễn phí. Mẫu chuẩn: mỗi process một connection, mỗi thread một channel — không share channel giữa các thread.

Đáp án: B

Client gửi request kèm replyTo (queue nhận kết quả) và correlationId (mã định danh request). Server xử lý xong publish response vào replyTo, gắn lại đúng correlationId. Vì một reply queue có thể nhận nhiều response, client dựa vào correlationId để khớp response với đúng request đang chờ.

Đáp án: A, D, E

Depth tăng dần nghĩa là tốc độ vào lớn hơn tốc độ ra. Ba hướng đúng: thêm consumer, chỉnh prefetch nếu đang nghẽn ở round-trip, và điều tra vì sao consumer xử lý chậm đi. Purge chỉ xoá triệu chứng kèm mất dữ liệu; priority không đổi tổng thông lượng.

Đáp án: C

Heartbeat là khung dữ liệu nhỏ hai bên gửi định kỳ để phát hiện connection chết trong các tình huống TCP im lặng: mạng rớt đột ngột, firewall/NAT cắt kết nối idle, máy đối phương mất điện. Bỏ lỡ heartbeat liên tiếp thì bên còn lại coi connection đã chết và đóng nó.

Đáp án: A

Mẫu TTL + DLX: publish vào một queue chờ không có consumer, đặt x-message-ttl: 300000 và x-dead-letter-exchange trỏ về exchange xử lý chính. Hết 5 phút, message hết hạn và được dead-letter sang đích — thành delayed message mà không cần plugin.

Đáp án: C

Exclusive queue = queue thuộc riêng một connection: chỉ connection tạo ra nó được dùng, và queue tự xoá khi connection đóng. Hợp cho reply queue của RPC client, hoặc queue riêng của một phiên làm việc — những thứ vô nghĩa khi chủ nhân biến mất.

Đáp án: A

Transaction đồng bộ: producer chờ mỗi lần commit hoàn tất, nên thông lượng rất thấp. Confirm bất đồng bộ: producer gửi liên tục và broker gửi xác nhận về sau kèm số thứ tự. Với cùng độ an toàn, confirm nhanh hơn nhiều lần.

Đáp án: A

Dựa vào thời gian xử lý mỗi message và độ trễ mạng: giá trị phải đủ lớn để consumer không rảnh chờ message tiếp theo. Xử lý nhanh và mạng chậm thì cần giá trị lớn; xử lý lâu thì giá trị nhỏ, thường bằng một, để việc phân phối công bằng.

Đáp án: C

Client phải kết nối lại có backoff, mở lại kênh, khai báo lại queue và binding nếu chúng do client tạo, và đăng ký nhận message lại. Nhiều thư viện có sẵn cơ chế khôi phục tự động, nhưng cần bật và cần hiểu nó khôi phục những gì.

Đáp án: C

Chế độ này ghi message xuống đĩa ngay thay vì giữ trong bộ nhớ. Nhờ đó queue chứa được hàng triệu message mà không làm cạn bộ nhớ broker — phù hợp cho các queue có lúc dồn ứ lớn. Đánh đổi là độ trễ cao hơn khi consumer đọc.

Đáp án: C

Nó khớp theo các thuộc tính trong header thay vì chuỗi khoá định tuyến, và khai báo được là phải khớp tất cả hay chỉ cần một thuộc tính. Phù hợp khi việc định tuyến phụ thuộc nhiều tiêu chí độc lập mà nhồi hết vào một chuỗi khoá sẽ rất khó đọc.