Bài 24 — Message Queue — SQS, Pub/Sub, Service Bus

Đã đọc 0/14 mục · còn khoảng 12 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Mở đầu — vì sao bài này quan trọng

Hãy tưởng tượng bạn đang xây một sàn thương mại điện tử như Tiki hay Shopee. Một khách hàng bấm nút "Đặt hàng". Ngay lúc đó, hệ thống phải làm cả một chuỗi việc: trừ tồn kho, tạo đơn, gửi email xác nhận, gửi thông báo cho nhà bán, cập nhật điểm thưởng, đẩy dữ liệu sang hệ thống phân tích. Nếu bạn bắt khách phải đợi toàn bộ chuỗi này chạy xong mới thấy màn hình "Đặt hàng thành công", họ có thể phải chờ 5–10 giây — và nếu chỉ một bước (ví dụ dịch vụ gửi email) bị treo, cả đơn hàng thất bại.

Đây chính là bài toán mà Message Queue (hàng đợi tin nhắn) và asynchronous messaging (nhắn tin bất đồng bộ) sinh ra để giải quyết. Thay vì làm mọi thứ ngay lập tức và đồng bộ, hệ thống chỉ cần ghi nhận "có một đơn hàng mới" vào một hàng đợi trung gian, trả về ngay cho khách "Đặt hàng thành công", rồi các bước còn lại được xử lý dần ở phía sau.

Trong thế giới cloud, đây là một trong những "viên gạch" nền tảng nhất của kiến trúc hiện đại. Ba nền tảng lớn đều có dịch vụ managed (được quản lý sẵn) cho việc này: Amazon SQS, Google Cloud Pub/Sub, và Azure Service Bus. Hiểu rõ chúng, bạn sẽ biết cách xây hệ thống chịu tải tốt, không sập dây chuyền, và dễ mở rộng. Đây là kỹ năng mà hầu như mọi vị trí DevOps hay Backend đều được hỏi khi phỏng vấn.

Khái niệm cốt lõi

Decoupling — tách rời producer khỏi consumer

Ý tưởng trung tâm của async messaging là decouple (tách rời) bên gửi ra khỏi bên nhận. Ta có hai vai trò:

Producer (bên sản xuất): tạo ra message và gửi vào hàng đợi. Trong ví dụ trên, service xử lý đơn hàng chính là producer.
Consumer (bên tiêu thụ): lấy message ra khỏi hàng đợi và xử lý. Ví dụ: service gửi email, service cập nhật kho.

Điểm mấu chốt: producer và consumer không cần biết nhau, không cần chạy cùng lúc. Producer cứ đẩy message vào queue rồi làm việc khác. Consumer khi nào rảnh thì lấy ra xử lý. Nếu consumer đang quá tải hay đang bảo trì, message vẫn nằm yên trong queue chờ, không mất đi. Đây gọi là buffering — hàng đợi đóng vai trò "bể chứa" hấp thụ những cú tăng tải đột ngột.

Hai mô hình gửi tin: Queue và Pub/Sub

Có hai pattern (mẫu hình) cơ bản, và bạn cần phân biệt rõ:

1. Queue (point-to-point) — một message, một người nhận

Message được đặt vào hàng đợi. Có thể có nhiều consumer cùng "rình" hàng đợi đó, nhưng mỗi message chỉ được giao cho đúng một consumer xử lý. Đây là mô hình phân phối công việc (work distribution). Ví dụ: bạn có 100 ảnh cần resize, đẩy 100 message vào queue, chạy 5 consumer song song, mỗi consumer bốc một ảnh xử lý — công việc được chia đều. Amazon SQS là đại diện tiêu biểu cho mô hình này.

2. Pub/Sub (publish-subscribe) — một message, nhiều người nhận

Producer (giờ gọi là publisher) đăng message lên một topic (chủ đề). Mọi subscriber (bên đăng ký) của topic đó đều nhận được một bản sao của message. Đây là mô hình phát tán (fan-out). Ví dụ: khi có đơn hàng mới, publish một event "OrderCreated" lên topic; service kho, service email, service phân tích — mỗi cái đều nhận được và tự xử lý phần của mình. Google Cloud Pub/Sub được thiết kế xoay quanh mô hình này.

Nhiều hệ thống thực tế kết hợp cả hai: một topic Pub/Sub fan-out ra nhiều queue, mỗi queue phục vụ một nhóm consumer.

Những khái niệm kỹ thuật bạn phải nắm

Visibility timeout (SQS): khi một consumer lấy message ra, message không bị xóa ngay mà bị "ẩn" trong một khoảng thời gian. Nếu consumer xử lý xong và gửi lệnh xóa, message biến mất. Nếu consumer chết giữa chừng (không kịp xóa), sau khi hết timeout message hiện lại để consumer khác xử lý. Đây là cơ chế đảm bảo không mất việc.

At-least-once delivery (giao ít nhất một lần): phần lớn các hệ thống này đảm bảo message được giao ít nhất một lần, nghĩa là có thể bị giao trùng. Vì vậy consumer phải viết code idempotent — xử lý cùng một message hai lần vẫn cho kết quả đúng (ví dụ: kiểm tra "đơn này đã trừ kho chưa" trước khi trừ). SQS có loại FIFO queue hỗ trợ exactly-once trong một cửa sổ thời gian, nhưng throughput thấp hơn.

Ordering (thứ tự): queue thường thì không đảm bảo thứ tự tuyệt đối. Nếu bạn cần message ra đúng thứ tự gửi (ví dụ các thao tác trên cùng một tài khoản), cần dùng FIFO queue (SQS), ordering key (Pub/Sub), hoặc session (Service Bus).

Dead Letter Queue (DLQ) — hàng đợi thư chết: khi một message bị xử lý lỗi quá nhiều lần (ví dụ 5 lần), thay vì thử mãi làm nghẽn hệ thống, nó bị chuyển sang một queue riêng để bạn điều tra sau. Đây là "tấm lưới an toàn" cực kỳ quan trọng.

Push vs Pull: Consumer có thể pull (chủ động hỏi queue "có gì không") như SQS, hoặc hệ thống push message tới một endpoint HTTP của consumer như Pub/Sub push subscription. Pull dễ kiểm soát tốc độ hơn; push tiện cho serverless.

So sánh nhanh ba dịch vụ cloud

Amazon SQS: hàng đợi thuần point-to-point, đơn giản, rẻ, cực bền. Muốn fan-out thì ghép với SNS (Simple Notification Service). Có Standard (throughput gần như vô hạn, không đảm bảo thứ tự) và FIFO.
Google Cloud Pub/Sub: thiên về pub/sub, throughput rất lớn, hỗ trợ cả pull lẫn push, phù hợp streaming và fan-out quy mô toàn cầu.
Azure Service Bus: "cao cấp" nhất về tính năng doanh nghiệp — có queue, có topic/subscription, hỗ trợ transaction, session (giữ thứ tự), dead-lettering, message scheduling. Phù hợp hệ thống enterprise cần logic phức tạp.

Tình huống thực tế

Ví dụ 1 — Sàn TMĐT xử lý cao điểm sale 12.12

Một sàn thương mại điện tử tại Việt Nam (giả định tên ChợViệt) gặp vấn đề mỗi mùa sale lớn. Ngày thường họ xử lý khoảng 5.000 đơn/giờ. Nhưng khung 0h ngày 12.12, lượng đơn vọt lên 60.000 đơn trong 10 phút đầu. Trước đây, kiến trúc của họ xử lý đơn đồng bộ: bấm đặt hàng là gọi thẳng service kho, service thanh toán, service email. Kết quả là database kho bị nghẽn, request xếp hàng, timeout dây chuyền, và cả trang web sập trong 8 phút — mất doanh thu và mất uy tín.

Họ tái kiến trúc bằng SQS. Giờ đây khi khách đặt hàng, service chính chỉ ghi đơn vào DB và đẩy một message vào SQS queue rồi trả về ngay. Consumer (chạy trên một Auto Scaling Group) rút message xử lý dần với tốc độ mà database kho chịu được — ví dụ 2.000 message/giây. Queue hấp thụ 60.000 đơn như một cái phễu: đỉnh tải dồn vào queue, hệ thống phía sau xử lý đều đặn trong vài phút thay vì sập.

Bài học rút ra: Message queue biến một cú "sốc tải" thành một dòng chảy đều. Bạn không cần chuẩn bị hạ tầng cho đỉnh tức thời; bạn chỉ cần đủ để "tiêu hóa" hết queue trong thời gian chấp nhận được. Đây gọi là load leveling.

Ví dụ 2 — Fintech gửi thông báo giao dịch qua nhiều kênh

Một ví điện tử (giả định PayNhanh) cần: mỗi khi có giao dịch, gửi thông báo push lên app, gửi SMS, ghi log chống gian lận, và cập nhật dashboard thời gian thực cho đội vận hành. Bốn việc, bốn đội khác nhau phụ trách.

Nếu dùng queue point-to-point, service giao dịch phải gọi bốn nơi — coupling chặt, thêm kênh thứ năm lại phải sửa code service giao dịch. Họ chuyển sang Google Cloud Pub/Sub: service giao dịch chỉ publish một event TransactionCompleted lên topic. Bốn service kia mỗi cái là một subscription, tự nhận bản sao và xử lý độc lập. Khi đội Marketing muốn thêm kênh "gửi email tổng kết cuối ngày", họ chỉ cần tạo một subscription mới — không đụng một dòng code nào của service giao dịch.

Một chi tiết quan trọng: đội chống gian lận từng lo message bị giao trùng khiến một giao dịch bị đánh dấu đáng ngờ hai lần. Họ giải quyết bằng cách lưu transaction_id đã xử lý vào Redis; nếu thấy id trùng thì bỏ qua — tức là idempotent consumer.

Bài học rút ra: Pub/Sub cho phép hệ thống mở rộng theo chiều "thêm người nghe" mà không phá vỡ bên gửi. Và luôn phải thiết kế consumer chịu được message trùng.

Ví dụ 3 — Startup logistics và bài học Dead Letter Queue

Một startup giao vận (giả định GiaoTốc) dùng Azure Service Bus để điều phối đơn giao hàng tới tài xế. Một hôm, một lô đơn có dữ liệu địa chỉ sai định dạng khiến consumer parse lỗi và ném exception. Vì Service Bus tự động giao lại message lỗi, consumer cứ nhận — lỗi — nhả — nhận lại, tạo thành vòng lặp vô hạn. CPU consumer tăng vọt, các đơn hợp lệ khác bị nghẽn phía sau, và cả đội giao hàng đứng hình 40 phút.

Nguyên nhân: họ chưa cấu hình Max Delivery Count và Dead Letter Queue. Sau sự cố, họ đặt MaxDeliveryCount = 5: một message lỗi quá 5 lần sẽ tự động bị đẩy vào DLQ. Đội trực chỉ cần theo dõi số lượng message trong DLQ, khi thấy tăng thì vào xem message hỏng, sửa dữ liệu và xử lý lại. Hệ thống chính không còn bị "poison message" (tin nhắn độc) làm tê liệt.

Bài học rút ra: DLQ không phải tính năng "nâng cao có cũng được" — nó là bắt buộc trong hệ thống nghiêm túc. Một message hỏng không được phép kéo sập cả hàng đợi.

Hướng dẫn từng bước

Giả sử bạn muốn dựng một luồng xử lý đơn hàng bất đồng bộ bằng Amazon SQS. Đây là các bước tư duy và thực thi:

Xác định ranh giới bất đồng bộ: Tách rõ đâu là phần khách cần thấy ngay (tạo đơn, trả về mã đơn) và đâu là phần chạy nền được (email, cập nhật kho, phân tích). Chỉ phần chạy nền mới đưa vào queue.

Tạo queue: Trên AWS Console hoặc bằng IaC (Terraform), tạo một Standard Queue tên order-processing. Cấu hình visibility timeout lớn hơn thời gian xử lý tối đa của consumer (ví dụ consumer chạy ~20 giây thì đặt timeout 60 giây để tránh giao lại nhầm).

Tạo Dead Letter Queue: Tạo thêm queue order-processing-dlq. Gắn nó vào queue chính với maxReceiveCount = 5. Đây là bước không được bỏ qua.

Viết producer: Trong service đơn hàng, sau khi lưu đơn vào DB, gọi SDK gửi message (chứa order_id và dữ liệu tối thiểu) vào queue. Trả kết quả về cho khách ngay sau khi gửi thành công.

Viết consumer idempotent: Consumer long-poll queue, nhận message, kiểm tra order_id đã xử lý chưa (dùng một bảng hoặc Redis), nếu chưa thì xử lý, rồi xóa message khỏi queue. Nếu lỗi, KHÔNG xóa — để message tự hiện lại và thử lại.

Cho consumer tự co giãn: Đặt consumer trên Auto Scaling dựa trên metric ApproximateNumberOfMessagesVisible — queue dài thì thêm consumer, queue ngắn thì bớt.

Giám sát: Đặt CloudWatch Alarm cho độ sâu queue (queue depth) và cho số message trong DLQ. DLQ có message tức là "có việc cần con người xem".

Lỗi thường gặp & mẹo

Quên xử lý message trùng (không idempotent): Đây là lỗi phổ biến nhất. Vì hệ thống là at-least-once, message sẽ bị giao trùng vào lúc nào đó. Luôn kiểm tra id đã xử lý trước khi thực hiện thao tác có tác dụng phụ (trừ tiền, gửi email).

Đặt visibility timeout quá ngắn: Nếu consumer xử lý 30 giây mà timeout chỉ 10 giây, message hiện lại và một consumer khác xử lý song song cùng message đó — sinh trùng lặp không cần thiết. Timeout phải lớn hơn thời gian xử lý tối đa.

Không cấu hình DLQ: Một poison message có thể làm nghẽn cả hệ thống. Luôn có DLQ và giám sát nó.

Nhồi payload quá lớn vào message: Message queue không phải nơi truyền file. SQS giới hạn 256 KB/message. Với dữ liệu lớn (ảnh, PDF), hãy lưu vào object storage (S3) rồi chỉ gửi đường dẫn qua queue. Mẹo này gọi là claim-check pattern.

Nhầm giữa queue và pub/sub: Nếu bạn cần nhiều service cùng phản ứng với một event, đừng dùng một queue point-to-point rồi tự viết logic sao chép — hãy dùng pub/sub (SNS+SQS, Pub/Sub topic, hoặc Service Bus topic).

Mẹo — dùng long polling: Với SQS, bật long polling (WaitTimeSeconds = 20) thay vì short polling để giảm số request rỗng và tiết kiệm chi phí đáng kể.

Mẹo — batch để tiết kiệm: Gửi và nhận message theo lô (batch) giúp giảm số lần gọi API, giảm cả chi phí lẫn độ trễ tổng.

Bài tập thực hành

Thiết kế trên giấy: Vẽ sơ đồ luồng "đăng ký tài khoản mới" cho một app, trong đó có 3 việc nền: gửi email chào mừng, tạo hồ sơ mặc định, cộng điểm giới thiệu. Quyết định bạn dùng queue hay pub/sub, và giải thích lý do.

Phân biệt mô hình: Cho ba tình huống, hãy nói dùng point-to-point queue hay pub/sub: (a) chia 10.000 ảnh cho nhiều worker resize; (b) một event "sản phẩm đổi giá" cần cập nhật cache, search index và trang chi tiết; (c) xử lý hàng đợi in hóa đơn theo đúng thứ tự.

Thực hành cloud (nếu có tài khoản AWS free tier): Tạo một Standard SQS queue và một DLQ gắn với nó. Dùng AWS CLI gửi 5 message vào queue, rồi viết một script nhỏ (Python + boto3) đọc và in ra từng message, xóa message sau khi in. Thử cố tình không xóa một message và quan sát nó hiện lại sau visibility timeout.

Tư duy idempotent: Viết bằng lời (pseudo-code) một consumer xử lý message "trừ 50.000đ từ ví" sao cho nếu nhận cùng message hai lần thì chỉ trừ tiền đúng một lần.

Tóm tắt

Message Queue và async messaging là công cụ nền tảng để tách rời producer khỏi consumer, giúp hệ thống hấp thụ tải đỉnh (load leveling), không sập dây chuyền, và dễ mở rộng. Có hai mô hình chính: queue point-to-point (một message, một consumer — hợp với chia việc, đại diện là SQS) và pub/sub (một message, nhiều subscriber — hợp với fan-out event, đại diện là Google Pub/Sub). Azure Service Bus cung cấp bộ tính năng doanh nghiệp đầy đủ nhất với queue, topic, session và transaction.

Những nguyên tắc sống còn khi làm việc với chúng: đảm bảo consumer idempotent vì hệ thống giao ít nhất một lần; đặt visibility timeout hợp lý; luôn có Dead Letter Queue để chặn poison message; và giữ payload nhỏ (dùng claim-check pattern cho dữ liệu lớn). Nắm chắc những điều này, bạn đã có nền tảng vững để bước sang các chủ đề nâng cao hơn như streaming và event-driven architecture ở các bài sau.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi