SQS (Simple Queue Service) P2

Sau khi một message được consumer poll, nó sẽ trở nên invisible (không hiển thị) đối với các consumer khác.
Theo mặc định, message visibility timeout là 30 giây.
Nghĩa là message có 30 giây để được xử lý.
Sau khi message visibility timeout kết thúc, message sẽ trở lại trạng thái visible (hiển thị) trong SQS và có thể được truy xuất lại.
Nếu một message không được xử lý trong thời gian visibility timeout, nó sẽ bị xử lý lặp lại (twice).
Consumer có thể gọi API ChangeMessageVisibility để gia hạn thời gian xử lý.
Nếu visibility timeout được đặt quá dài (ví dụ: hàng giờ) và consumer bị crash, quá trình xử lý lại sẽ bị trì hoãn.
Nếu visibility timeout được đặt quá ngắn (chỉ vài giây) thì có thể xảy ra tình trạng duplicate message (xử lý trùng).

Biểu đồ thể hiện quy trình xử lý một message trong hàng đợi SQS qua các giai đoạn truy xuất và visibility timeout:

ReceiveMessage Request: Mỗi mũi tên xuống thể hiện một lần gọi API ReceiveMessage.
Lần đầu tiên message được nhận về (Message returned) → message trở nên invisible trong khoảng thời gian timeout.
Các lần gọi tiếp theo trong thời gian timeout → message không được trả về (Not returned), do nó đang ở trạng thái invisible.
Sau khi hết timeout → message trở lại hàng đợi và lại có thể được truy xuất (Message returned again).

Khi một consumer gửi yêu cầu nhận message từ hàng đợi (queue), nó có thể tuỳ chọn "chờ" (wait) để đợi có message mới nếu queue hiện tại đang rỗng.
Cơ chế này gọi là Long Polling.
Long Polling giúp giảm số lượng API call gửi tới SQS, đồng thời tăng hiệu suất và giảm độ trễ (latency) cho ứng dụng.
Thời gian chờ (wait time) có thể cấu hình từ 1 giây đến 20 giây (khuyến nghị: 20 giây).
Long Polling nên được ưu tiên hơn Short Polling (gọi liên tục để kiểm tra có message hay không).
Có thể kích hoạt Long Polling ở mức hàng đợi (queue level) hoặc ở mức API call bằng cách cấu hình tham số WaitTimeSeconds.

Message được gửi đến SQS Queue.
Consumer thực hiện thao tác poll (gọi API nhận message).
Nếu sử dụng Long Polling:
→ Consumer sẽ "chờ" cho tới khi có message xuất hiện trong giới hạn thời gian đã cấu hình (ví dụ: 20 giây).
→ Nếu có message, nó được trả về cho Consumer.

FIFO = First In First Out (thứ tự xử lý theo thứ tự gửi vào hàng đợi)
FIFO (First-In-First-Out) trong SQS FIFO áp dụng cho thứ tự mà messages được consume bởi consumer.
Thông lượng giới hạn:
- 300 message/giây nếu không dùng batching (tức là gửi từng message riêng lẻ).
- 3000 message/giây khi dùng batching (gửi theo một tập các message)
Exactly-once send capability:
- Đảm bảo gửi đúng một lần, bằng cách loại bỏ các message bị trùng lặp.
- Message sẽ bị xử lý lại nếu consumer không gọi DeleteMessageAPI
Message được xử lý đúng thứ tự bởi consumer:
- FIFO Queue duy trì thứ tự gốc của các message khi được consumer lấy ra xử lý.

Giải thích sơ đồ:

Producer: thành phần tạo và gửi message.
- Gửi các message có thứ tự: 4, 3, 2, 1.
- Các message này được đưa vào FIFO Queue (hàng đợi kiểu FIFO của Amazon SQS).
- Khi consumer gọi poll để lấy message, hệ thống sẽ đảm bảo trả ra các message đúng thứ tự như đã gửi: 4, 3, 2, 1.
Consumer: thành phần nhận và xử lý message theo thứ tự.

Với SQS Standard, không có sự sắp xếp thứ tự
Với SQS FIFO, nếu bạn không sử dụng Group ID, các message sẽ được consume theo thứ tự chúng được gửi, chỉ bởi một consumer duy nhất.

Nếu bạn muốn scale số lượng consumer, nhưng vẫn muốn các message liên quan được xử lý cùng nhau,
→ bạn cần sử dụng Group ID
(giống như Partition Key trong Kinesis).