Message Queue: Đảm bảo delivery và xác nhận hoàn thành tường minh

3 giờ chiều, một payload JSON lỗi chứa trường dữ liệu null bất thường vượt qua lớp kiểm tra lỏng lẻo ở tầng ngoài và được đẩy thẳng vào hàng đợi xử lý đơn hàng chính. Worker 1 nhặt message, vấp phải ngoại lệ (exception) chưa được bắt và sập (crash) ngay lập tức. Vì tiến trình bị ngắt đột ngột nên message chưa từng được gửi xác nhận hoàn tất (ACK), message broker phát hiện kết nối đứt và lập tức giao lại (redeliver) message đó cho worker tiếp theo. Worker 2 nhận việc, gặp đúng ngoại lệ đó và tiếp tục crash. Chỉ trong vài phút ngắn ngủi, tin nhắn độc (poison pill) này quay vòng qua toàn bộ cụm worker, đánh sập từng tiến trình một trong một vòng lặp tử thần (infinite crash loop). Toàn bộ nhóm worker cạnh tranh (competing consumers) bị tê liệt hoàn toàn, độ sâu hàng đợi (queue depth / backlog) tăng vọt lên hàng trăm nghìn đơn hàng ùn ứ, tuổi của message lâu nhất kéo dài hàng giờ và thông lượng xử lý của hệ thống rơi tự do về con số 0.

Đó chính là cơn ác mộng kinh điển của lỗi hàng đợi không được kiểm soát. Message queue phân tách bên gửi (producer) khỏi bên xử lý (consumer) và hỗ trợ mở rộng các nhóm worker cạnh tranh, nhưng nếu thiếu hàng đợi thư chết (Dead-Letter Queue - DLQ), chiến lược giãn cách thử lại (retry backoff) và xác nhận gửi (publisher confirmation), một tin nhắn lỗi duy nhất cũng đủ sức quật ngã toàn bộ hệ thống xử lý bất đồng bộ của bạn.

TL;DR

💡 Quy tắc bỏ túi: Hoàn tất ở tầng truyền tải (transport) không đồng nghĩa với hoàn tất nghiệp vụ. Tuyệt đối không gửi xác nhận (ACK) trước khi hiệu ứng bền vững được ghi nhận an toàn, luôn bảo vệ worker bằng hàng đợi thư chết (DLQ) kết hợp retry backoff để cô lập tin nhắn độc, và thiết kế consumer có tính lũy đẳng để hấp thụ an toàn các đợt phát lại (redelivery).

• Tách rời xử lý và worker cạnh tranh (competing consumers): Message queue cho phép bên gửi (producer) giải phóng công việc bất đồng bộ tới nhiều worker cùng cạnh tranh xử lý, giúp hấp thụ lưu lượng đột biến và san phẳng áp lực lên hạ tầng.
• Xác nhận (ACK) định nghĩa quyền sở hữu giao nhận: Gửi ACK quá sớm sẽ làm mất trắng dữ liệu nếu worker sập giữa chừng; ngược lại, ACK sau khi thực thi nghiệp vụ sẽ mở ra cửa sổ phát lại (redelivery) đòi hỏi bên nhận phải có tính lũy đẳng (idempotent).
• Trạng thái in-flight và thời hạn ẩn (visibility timeout): Quyền xử lý một message bản chất là một hợp đồng thuê (lease) có thời hạn (như visibility timeout trong Amazon SQS hay prefetch trong RabbitMQ); các tác vụ chạy lâu bắt buộc phải gia hạn lease trước khi hết hạn để tránh việc worker khác tưởng nhầm tin nhắn bị bỏ rơi và lao vào xử lý trùng.
• Cô lập tin nhắn độc bằng Dead-Letter Queue (DLQ): Các message lỗi lặp lại phải được ngắt khỏi vòng lặp sau khi cạn ngân sách retry kèm backoff và jitter, chuyển hướng vào hàng đợi thư chết (DLQ) để kỹ sư điều tra thay vì để nó làm sập toàn bộ dàn worker.
• Cạm bẫy chết người: Bật chế độ tự động xác nhận (auto-ACK) ngay khi vừa nhận tin nhắn trước khi bắt đầu xử lý, hoặc gửi ACK trước khi commit cơ sở dữ liệu, khiến dữ liệu bị mất vĩnh viễn không thể cứu vãn mỗi khi worker pod bị Kubernetes dừng đột ngột hoặc sập nguồn.

Quy tắc trung tâm là: hoàn tất ở tầng transport và hoàn tất nghiệp vụ là hai sự thật khác nhau.

1. Tách cơ chế queue khỏi ngữ nghĩa job

Background job mô tả công việc ở tầng ứng dụng: identity, lifecycle, retry, cancellation, progress và terminal state. Message queue mô tả quyền sở hữu transport và trạng thái giao nhận.

Một job có thể được chở bởi một queue message:

job_id: export_9281
job_type: GENERATE_EXPORT
attempt_hint: 3
payload_ref: db://exports/export_9281

Bản ghi ứng dụng bền vững có thể nói logical export đang PROCESSING, trong khi broker chỉ nói một delivery cụ thể đang in-flight. Hai trạng thái liên quan nhưng không thể thay thế nhau.

Không dùng message body làm bản ghi nghiệp vụ bền vững duy nhất nếu operator cần xem trạng thái sau khi ack. Ngược lại, một job table trong database cũng không tự có routing, flow control hay publisher confirmation giống broker.

2. Thành công phía bên gửi cần xác nhận riêng

Một flow nguy hiểm là:

send(message)
trả success cho caller

send thành công nghĩa là gì? Tùy client và broker, nó có thể chỉ nghĩa byte đã vào socket buffer cục bộ, broker đã nhận message, hoặc một đường ghi bền vững trong broker đã xác nhận.

RabbitMQ tách publisher confirms khỏi consumer acknowledgements. Publisher confirms bảo vệ phía producer → broker; consumer acknowledgements bảo vệ phía broker → consumer. Chúng xử lý hai failure window khác nhau.

Xét chuỗi sau:

1. producer publish message M
2. broker nhận M
3. kết nối mạng mất
4. producer không nhận được confirmation

Producer không thể suy ra từ kết nối hỏng rằng M đã được nhận hay chưa. Retry có thể là lựa chọn tốt cho availability, nhưng hệ thống phải chịu được hai message tương đương về logic.

Đó là lý do message ID, job ID, idempotency key hoặc ranh giới deduplication ổn định rất quan trọng. “Code chỉ gọi send một lần” không phải delivery guarantee.

3. Worker cạnh tranh chia sẻ một work pool

Ví dụ ba worker:

queue: [A B C D E F]
worker-1 <- A, D
worker-2 <- B, E
worker-3 <- C, F

Cách chia cụ thể phụ thuộc broker; ownership model mới là điểm quan trọng. Nếu email, fraud và analytics đều phải thấy mọi OrderPlaced, ba consumer cạnh tranh trên một queue không phải fan-out. Guide Queue vs Event Stream xử lý sâu quyết định kiến trúc đó.

4. Ack định nghĩa hoàn tất ở tầng transport

Hướng an toàn thường là:

nhận -> validate -> tạo effect lặp an toàn -> ghi completion bền vững -> ack

Nhưng không có thứ tự nào tự động biến external side effect và broker acknowledgement thành một transaction nguyên tử.

Nếu worker gửi email rồi crash trước ack, broker có thể giao lại message. Nếu handler gửi mù lần nữa, khách nhận hai email. Nếu effect phải xảy ra đúng một lần về logic, hãy bảo vệ invariant tại effect boundary bằng idempotency key, unique record, state transition hoặc cơ chế dedup phù hợp.

Automatic acknowledgement trước khi xử lý có thể tăng throughput nhưng làm recovery yếu hơn: broker có thể quên delivery trong lúc application code vẫn chạy. Chỉ dùng khi mất message được chấp nhận tường minh hoặc ứng dụng có nguồn recovery khác.

5. In-flight là một lease, không phải độc quyền vĩnh viễn

Các queue system biểu diễn ownership đang xử lý khác nhau.

Amazon SQS dùng visibility timeout: sau khi consumer nhận message, message vẫn nằm trong queue nhưng tạm bị ẩn. Nếu consumer không xóa trước khi timeout hết, message lại visible cho một lần receive khác. Standard queue của SQS vẫn là at-least-once; visibility không bảo đảm duplicate không bao giờ xảy ra.

RabbitMQ với push consumer dùng acknowledgements cùng prefetch, tức cửa sổ giới hạn số delivery chưa xác nhận có thể đang outstanding.

Đây là các API khác nhau quanh cùng một câu hỏi:

Một worker được sở hữu bao nhiêu work chưa chứng minh hoàn tất, và ownership đó hết hạn hoặc quay về broker bằng cách nào?

Nếu xử lý thường mất hai phút nhưng thời gian ẩn/visibility timeout chỉ 30 giây, worker thứ hai có thể nhận cùng message trong lúc worker đầu vẫn chạy. Nếu một consumer prefetch hàng trăm message nặng, một worker có thể ôm work và RAM trong khi worker khác rảnh.

Chọn thời lượng visibility/lease từ latency xử lý đã đo; gia hạn ownership có chủ đích cho work dài khi broker hỗ trợ. Giới hạn prefetch hoặc số in-flight để một worker không tích lũy nhiều work hơn mức có thể xử lý an toàn.

6. Giao lại là cơ chế recovery bình thường

Queue nên làm failure có thể phục hồi thay vì âm thầm mất work. Các nguyên nhân giao lại thường gồm:

• worker crash;
• mất connection/channel;
• acknowledgement không tới broker;
• visibility timeout hoặc lease hết;
• negative acknowledgement/requeue tường minh;
• lỗi tạm thời được route qua retry mechanism.

Vì vậy handler nên giả định at-least-once delivery trừ khi hợp đồng broker thật và toàn bộ effect boundary chứng minh được mức mạnh hơn.

Claim exactly-once luôn có scope. Broker có thể deduplicate send hoặc transaction bên trong nó nhưng không tự atomically bao gồm HTTP call, email, payment hoặc mutation ở datastore khác. Effect bên ngoài phải được thiết kế riêng.

Một message envelope hữu ích có identity ổn định:

message_id
logical_job_id hoặc event_id
message_type
schema_version
created_at
correlation_id / trace_id
payload hoặc durable payload reference

Không tạo logical idempotency identity mới cho mỗi lần giao lại.

7. Thứ tự là một phạm vi, không phải checkbox toàn cục

“FIFO” chưa đủ nếu chưa nói ordering scope và semantics của completion.

Ngay cả khi broker giao A trước B, hai worker có thể hoàn tất B trước A. Retry cũng có thể khiến message cũ hoàn tất sau message mới.

Hãy hỏi:

• Có thật cần global ordering không?
• Hay chỉ cần thứ tự theo account, order, document hoặc aggregate key?
• Chỉ delivery order quan trọng, hay cả effect completion order?
• Nếu một message trong ordered group lỗi lặp lại thì các message sau phải làm gì?

Ordering mạnh thường làm giảm parallelism. Nếu toàn bộ work phải qua một consumer tuần tự, throughput và fault isolation thay đổi. Hãy dùng ordering key hẹp nhất vẫn bảo toàn invariant thật.

Khi state mới supersede state cũ, version check đôi khi bảo vệ correctness tốt hơn serialize toàn hệ thống:

chỉ apply nếu incoming_version > stored_version

Cơ chế đúng đi từ business model chứ không đi từ nhãn “FIFO”.

8. Dead-letter path ngăn poison work chiếm worker fleet

Dead-letter không phải thùng rác. Operator cần đủ context để quyết định:

• sửa data rồi replay;
• sửa code rồi replay;
• loại bỏ message invalid có chủ đích;
• compensate effect đã chạy một phần;
• escalate bug phía producer/schema.

Giữ original message identity, failure classification, attempt metadata cần thiết và correlation identifiers. Không nhét secret hoặc debug dump quá lớn vào dead-letter metadata.

Retry phải phân biệt transient failure với terminal failure. Schema hỏng, business object đã bị thu hồi hoặc validation deterministic không nên nhận cùng retry policy như network timeout tạm thời.

9. Backpressure nằm ở backlog, tuổi message và in-flight work

Queue hấp thụ burst, nhưng backlog là tải bị trì hoãn chứ không phải capacity miễn phí.

Theo dõi tối thiểu:

• queue depth / backlog — có bao nhiêu message ready đang chờ;
• tuổi của message lâu nhất — work tệ nhất đã bị trì hoãn bao lâu;
• số in-flight/chưa ack;
• publish rate so với completion rate;
• retry/redelivery rate;
• dead-letter rate;
• worker concurrency và saturation;
• processing latency theo message.

Độ sâu hàng đợi một mình có thể đánh lừa. 10.000 job 10ms có thể khỏe hơn 500 job 10 phút. Tuổi message lâu nhất thường ánh xạ trực tiếp hơn tới objective về thời gian chờ của người dùng.

Backpressure/áp lực ngược phải thay đổi hành vi. Có thể:

• giới hạn worker concurrency và prefetch/in-flight;
• làm chậm hoặc từ chối producer không critical;
• ưu tiên work quan trọng một cách có kiểm soát;
• scale worker trong giới hạn downstream capacity;
• tạm dừng job tùy chọn tốn kém;
• hiển thị trạng thái xử lý chậm cho người dùng;
• bảo vệ database và third-party API khỏi một đợt drain queue quá mạnh.

Dashboard chỉ cho thấy backlog tăng mà không nối tới admission/capacity action mới là observability, chưa phải kiểm soát áp lực.

10. Queue không tự giải quyết dual write giữa database và broker

Flow sau có partial-failure window kinh điển:

1. commit order vào database
2. publish OrderReadyForFulfillment

Nếu process crash sau bước 1 nhưng trước bước 2, order tồn tại mà queue message không có. Đảo thứ tự lại tạo vấn đề ngược: consumer có thể nhận work cho một database write cuối cùng không commit.

Không giả định publisher confirms giải quyết database-to-broker atomicity. Pattern như transactional outbox ghi business mutation và intent-to-publish trong cùng local transaction, rồi publish bất đồng bộ với duplicate-safe handling.

Đây là concept riêng với queue delivery, nhưng ranh giới rất quan trọng: broker durability chỉ bắt đầu sau khi publication thực sự tới broker.

Tình huống production: visibility timeout ngắn hơn fulfillment

Một order-fulfillment queue dùng visibility timeout 30 giây. Hầu hết warehouse reservation call hoàn tất dưới 10 giây nên default trông an toàn trong test. Một dependency inventory trở nên chậm và một số reservation mất 70–90 giây.

Worker A nhận FulfillOrder:ord_742 và bắt đầu giữ stock. Tới giây 30, message visible trở lại. Worker B nhận cùng message trong khi Worker A vẫn hoạt động. Cả hai cùng gọi endpoint tạo shipping label không lũy đẳng và tạo hai label riêng trước khi một worker cuối cùng xóa message.

Hậu quả: cùng một order có duplicate label và duplicate warehouse work; một số order bị pack hai lần và cần reconciliation thủ công.

Nguyên nhân cốt lõi: nhóm coi visibility timeout như tuning hiệu năng thay vì ownership lease. Processing latency vượt lease và effect fulfillment không có idempotency boundary ổn định cho lần giao lại.

Cách khắc phục chuẩn: chọn và giám sát visibility từ processing latency thật, gia hạn ownership cho attempt dài hợp lệ, giới hạn in-flight work và làm effect fulfillment lũy đẳng theo order/job identity ổn định. Chỉ ack/xóa sau khi completion state bền vững đã được ghi. Alert theo redelivery, tuổi message lâu nhất và attempt chạy dài để dependency quá tải lộ ra trước khi duplicate work trở thành triệu chứng.

Bài học sâu hơn là queue phục hồi khỏi uncertainty bằng cách đưa work ra lại để xử lý. Consumer đúng phải biến recovery behavior đó thành sự lặp lại an toàn.

Tự kiểm tra

Một producer publish billing job. Broker đã nhận, nhưng mạng lỗi trước khi producer nhận publisher confirmation. Producer retry với một random message ID mới. Sau đó cả hai bản sao tới hai worker. Mỗi worker charge cùng invoice thành công rồi ack delivery.

Cơ chế queue nào đã hỏng?

Checklist review message queue

• Mục đích: Đây có phải work queue cho competing consumers, không phải fan-out/event-history vô tình không?
• Publish proof: Chính xác điều gì xác nhận publication của bên gửi, và chuyện gì xảy ra khi xác nhận gửi trở nên mơ hồ?
• Identity: Lần giao lại có giữ logical message/job/effect identity ổn định không?
• In-flight: Mỗi worker được giữ bao nhiêu work chưa ack?
• Lease: Visibility/ack ownership có khớp processing duration thật, kể cả long-tail latency không?
• Ack: Xác nhận hoàn tất có xảy ra sau durable effect/completion record thay vì trước meaningful work không?
• Duplicate: Business effect có chịu được redelivery một cách lũy đẳng không?
• Thứ tự: Ordering có được scope theo business key hẹp nhất, và completion order có được xét riêng với delivery order không?
• Retry: Transient failure có được tách khỏi terminal/poison work không?
• Dead letter: Operator có thể inspect, repair, replay hoặc discard terminal message có chủ đích không?
• Backpressure: Queue depth, tuổi message lâu nhất, in-flight work và downstream capacity có kích hoạt control action không?
• Dual write: Nếu database mutation phải gây ra message, failure window database → broker đã được xử lý tường minh chưa?

Quy tắc cho agent

Khi review work chạy qua queue, hãy vẽ cả hai failure boundary: producer → broker và broker → consumer/effect. Không suy ra business completion từ publish success hoặc transport acknowledgement. Giữ logical identity ổn định qua retry, làm duplicate effect an toàn, giới hạn in-flight work, nêu rõ ordering scope và nối backlog evidence với một pressure-control response thật.

Khái niệm liên quan

• Background Jobs — lifecycle, retry, cancellation và progress của logical work ở tầng ứng dụng có thể được chở qua queue nhưng không đồng nhất với broker delivery state.
• Queue vs Event Stream — dùng khi quyết định giữa work ownership hướng completion và lịch sử retained cho các subscriber độc lập.
• Idempotency — bảo vệ business effect qua publish ambiguity và redelivery window.
• Retries & Backoff — retry policy phải bounded và phân loại transient/terminal failure.
• Transactional Outbox — xử lý atomicity gap giữa database write và broker publish.
• Logs, Metrics & Traces — correlation ID cùng span queue-delay/processing nối async work về request nguồn.

Tiếp tục theo Backend Systems tới rate limiting, idempotency, service resilience và delivery semantics sâu hơn.

Nguồn tham khảo

Các nguồn chính được kiểm tra ngày 2026-09-10:

• RabbitMQ — Consumer Acknowledgements and Publisher Confirms
• RabbitMQ — Dead Letter Exchanges
• Amazon SQS — Visibility Timeout
• Amazon SQS — Processing messages in a timely manner

Các nguồn trên minh họa API cụ thể của broker; mental model vẫn vendor-neutral. Queue khác có thể dùng lease, reservation, pull, push, receipt hoặc acknowledgement với chi tiết khác, vì vậy phải kiểm tra hợp đồng thật của sản phẩm trước khi dựa vào một guarantee cụ thể.

Bài này ở trạng thái evolving với chu kỳ review 180 ngày vì capability broker và guidance vận hành thay đổi, dù lập luận về publish ambiguity, acknowledgement boundary, redelivery, duplicate safety, ordering scope và backpressure vẫn bền vững.