Amazon Simple Queue Service (SQS) là một dịch vụ hàng đợi tin nhắn giúp tách biệt (decouple) các thành phần trong hệ thống phân tán. Đây là một trong những dịch vụ đầu tiên của AWS và đã được sử dụng rộng rãi trong hơn một thập kỷ qua.
Xem thêm:
1. Cấu trúc cơ bản của SQS
SQS hoạt động dựa trên mô hình hàng đợi (queue), nơi các tin nhắn được gửi vào và lấy ra theo trình tự nhất định.
- Producer: Là thành phần gửi tin nhắn vào hàng đợi.
- Queue: Là nơi lưu trữ tạm thời các tin nhắn cho đến khi được xử lý.
- Consumer : Là thành phần nhận và xử lý tin nhắn từ hàng đợi.
2. Tính năng nổi bật của SQS Standard Queue
- Throughput không giới hạn: Hỗ trợ gửi và nhận số lượng lớn tin nhắn mỗi giây.
- Thời gian lưu trữ: Mặc định 4 ngày, tối đa 14 ngày cho mỗi tin nhắn.
- Độ trễ thấp: Thời gian phản hồi gửi/nhận dưới 10 mili-giây.
- Kích thước tin nhắn: Tối đa 256KB mỗi tin nhắn.
- At-least-once delivery: Có thể xảy ra trùng lặp.
- Sắp xếp không đảm bảo: Tin nhắn có thể được nhận không theo thứ tự đã gửi.
3. Quy trình gửi và xử lý tin nhắn
3.1 Producer gửi tin nhắn
Các Producer sử dụng SDK và API SendMessage để gửi tin nhắn vào hàng đợi. Tin nhắn sẽ được lưu trữ cho đến khi có Consumer xử lý.
3.2 Consumer nhận và xử lý
Consumer sẽ liên tục poll hàng đợi để kiểm tra xem có tin nhắn mới không. Một lượt poll có thể nhận tối đa 10 tin nhắn. Sau khi xử lý, Consumer sử dụng API DeleteMessage để xoá tin nhắn khỏi hàng đợi, đảm bảo không bị xử lý lặp lại.
4. Mở rộng quy mô và tích hợp với Auto Scaling
SQS có thể được tích hợp với Auto Scaling Group (ASG) để tăng số lượng EC2 Consumer tùy theo độ dài hàng đợi (metric ApproximateNumberOfMessages trong CloudWatch).
Ví dụ kiến trúc mở rộng:
- Hàng đợi SQS nhận tin nhắn về yêu cầu xử lý video.
- Ứng dụng back-end (Consumer) đặt trong Auto Scaling Group xử lý các yêu cầu này.
- CloudWatch Alarm giám sát độ dài hàng đợi và tăng số lượng EC2 khi cần thiết.
5. Kiến trúc ứng dụng tách rời (Decoupled Architecture)
Thay vì xử lý toàn bộ trong một ứng dụng đơn lẻ (monolith), bạn có thể chia làm nhiều lớp như sau:
- Frontend nhận yêu cầu và gửi tin nhắn vào SQS.
- Backend (Auto Scaling group) đọc tin nhắn, xử lý và lưu kết quả vào S3 hoặc RDS.
Kiến trúc này tăng khả năng mở rộng độc lập cho từng lớp và tối ưu hiệu suất dựa theo loại tác vụ.
6. Visibility Timeout trong Amazon SQS
6.1. Cơ chế hoạt động của Visibility Timeout
Khi một consumer thực hiện lệnh ReceiveMessage để lấy tin nhắn từ hàng đợi (queue), tin nhắn đó sẽ không còn hiển thị cho các consumer khác trong một khoảng thời gian nhất định gọi là visibility timeout. Mặc định, giá trị này là 30 giây.
Trong thời gian này, nếu một consumer khác tiếp tục thực hiện nhận tin nhắn, thì tin nhắn đó sẽ không được trả về vì nó đang được xử lý. Nếu consumer ban đầu không xóa tin nhắn trong thời gian timeout này (nghĩa là không gọi lệnh DeleteMessage), sau khi timeout kết thúc, tin nhắn sẽ được đưa trở lại hàng đợi và trở nên hiển thị với các consumer khác.
6.2. Rủi ro và cách xử lý
Một điểm cần lưu ý là nếu consumer không xử lý xong tin nhắn trong thời gian visibility timeout, tin nhắn có thể sẽ được nhận lại và xử lý nhiều lần bởi cùng một consumer hoặc nhiều consumer khác nhau. Điều này gây ra hiện tượng xử lý trùng lặp.
Để tránh điều này, AWS cung cấp API ChangeMessageVisibility cho phép consumer gia hạn thời gian timeout nếu biết rằng cần thêm thời gian để xử lý tin nhắn. Điều này giúp đảm bảo rằng tin nhắn sẽ không xuất hiện lại trong queue một cách sớm hơn cần thiết.
6.3. Cấu hình Visibility Timeout
Giá trị visibility timeout có thể được cấu hình trong khoảng từ 0 giây đến 12 giờ. Việc chọn giá trị phù hợp phụ thuộc vào yêu cầu xử lý thực tế của ứng dụng:
- Nếu đặt quá cao: Khi consumer bị lỗi, tin nhắn sẽ mất thời gian rất lâu để hiển thị lại.
- Nếu đặt quá thấp: Có nguy cơ tin nhắn được xử lý lặp lại do không đủ thời gian để xử lý hoàn chỉnh.
Vì vậy, bạn nên thiết lập giá trị mặc định hợp lý (ví dụ: 30 giây) và sử dụng API ChangeMessageVisibility để mở rộng thời gian cho từng tin nhắn cụ thể khi cần thiết.
6.4. Minh họa thực tế
Giả sử bạn mở hai cửa sổ để quan sát quá trình nhận và xử lý tin nhắn:
- Gửi tin nhắn “Hello World” vào hàng đợi.
- Consumer A (cửa sổ 1) poll và nhận tin nhắn đầu tiên. Tin nhắn ngay lập tức trở nên vô hình đối với các consumer khác trong 30 giây.
- Consumer B (cửa sổ 2) poll trong thời gian này sẽ không thấy tin nhắn.
- Nếu Consumer A không xóa tin nhắn, sau 30 giây, tin nhắn được đưa trở lại hàng đợi.
- Lúc này, Consumer B có thể nhận được tin nhắn đó. Nếu Consumer B xóa nó, thì tin nhắn được xử lý hoàn tất.
7. Long Polling trong Amazon SQS
7.1. Khái niệm Long Polling
Long Polling là cơ chế cho phép consumer (ứng dụng hoặc dịch vụ nhận tin nhắn) chờ đợi một khoảng thời gian nếu hàng đợi SQS hiện tại chưa có tin nhắn nào. Thay vì kiểm tra liên tục (short polling) gây tốn kém tài nguyên và API call, long polling giúp tiết kiệm chi phí và tối ưu hiệu suất.
7.2. Cách hoạt động
- Khi consumer gửi yêu cầu nhận tin nhắn từ hàng đợi, nó có thể chỉ định thời gian chờ đợi (ví dụ: 10 giây).
- Nếu trong thời gian đó có tin nhắn mới đến hàng đợi, tin nhắn sẽ được gửi ngay lập tức đến consumer.
- Nếu hết thời gian chờ mà không có tin nhắn mới, kết quả trả về sẽ là rỗng.
7.3. Lợi ích của Long Polling
- Giảm số lượng API call: Vì mỗi lần polling có thể kéo dài đến 20 giây, số lần gọi API giảm đi đáng kể so với short polling vốn phải gọi lặp liên tục.
- Giảm độ trễ khi xử lý tin nhắn: Tin nhắn sẽ được trả về ngay lập tức khi có trong hàng đợi, giảm thiểu độ trễ giữa thời điểm gửi và xử lý.
- Tiết kiệm chi phí: Ít API call hơn đồng nghĩa với chi phí thấp hơn trong mô hình tính phí theo số lượng yêu cầu.
7.4. Cấu hình Long Polling
Bạn có thể kích hoạt Long Polling thông qua hai cách:
- Tại mức hàng đợi (Queue level): Thiết lập mặc định thời gian chờ thông qua SQS Console hoặc CLI.
- Tại thời điểm gọi API: Truyền tham số
WaitTimeSecondstrong lệnhReceiveMessageđể chỉ định thời gian chờ cho mỗi yêu cầu cụ thể.
Thời gian chờ tối đa được Amazon SQS hỗ trợ cho long polling là 20 giây. Đặt giá trị càng cao giúp tiết kiệm API call hơn, đặc biệt hữu ích với hệ thống có lưu lượng tin nhắn thấp hoặc không ổn định.
8. Amazon SQS FIFO Queue
Amazon SQS FIFO Queue (First-In, First-Out) là loại hàng đợi được thiết kế để đảm bảo rằng các tin nhắn được xử lý theo đúng thứ tự mà chúng được gửi đi. Điều này đặc biệt quan trọng với các ứng dụng cần tính nhất quán cao về dữ liệu và quy trình xử lý.
8.1. FIFO là gì?
FIFO (First-In, First-Out) nghĩa là ai đến trước được xử lý trước. Khi một producer gửi các tin nhắn theo thứ tự cụ thể, chẳng hạn: 1 → 2 → 3 → 4, thì consumer cũng sẽ nhận được các tin nhắn đúng theo thứ tự đó. Đây là điểm khác biệt so với hàng đợi SQS tiêu chuẩn (Standard Queue), nơi thứ tự tin nhắn không được đảm bảo.
8.2. Đặc điểm nổi bật của FIFO Queue
- Đảm bảo thứ tự tin nhắn: Tin nhắn được xử lý đúng trình tự mà producer đã gửi đi, dựa trên Message Group ID.
- Loại bỏ tin nhắn trùng lặp: Hỗ trợ tính năng Exactly-Once Processing thông qua Deduplication ID. Nếu hai tin nhắn có cùng Deduplication ID được gửi trong vòng 5 phút, tin nhắn sau sẽ bị loại bỏ.
- Giới hạn hiệu suất:
- Tối đa 300 messages/second nếu không dùng batch.
- Lên đến 3,000 messages/second khi sử dụng batch.
- Yêu cầu định danh tin nhắn: Mỗi tin nhắn cần có Message Group ID và Deduplication ID (trừ khi bật chế độ tự động).
8.3. Cách hoạt động của FIFO Queue
Mỗi tin nhắn gửi vào hàng đợi FIFO cần có:
- Message Group ID: Xác định nhóm tin nhắn cần giữ thứ tự. Các tin nhắn trong cùng một nhóm sẽ được xử lý tuần tự.
- Deduplication ID: Dùng để nhận diện và loại bỏ trùng lặp trong cửa sổ thời gian 5 phút.
8.4. Tạo và sử dụng FIFO Queue
- Truy cập SQS Console và chọn Create Queue.
- Chọn loại FIFO Queue và đặt tên queue kết thúc bằng
.fifo(ví dụ:DemoQueue.fifo). - Bật hoặc tắt tính năng Content-based Deduplication (loại bỏ trùng lặp dựa trên nội dung nếu không dùng thủ công Deduplication ID).
- Gửi tin nhắn với:
- Message Body: Nội dung tin nhắn (ví dụ:
Hello World 1). - Message Group ID: (ví dụ:
demo). - Deduplication ID: (ví dụ:
id-1).
- Message Body: Nội dung tin nhắn (ví dụ:
- Consumer khi nhận tin sẽ thấy tin nhắn đến đúng theo thứ tự:
Hello World 1 → 2 → 3 → 4.
9. Hướng dẫn tạo và quản lý Standard Queue
Mục Tiêu
- Tạo Standard Queue trong Amazon SQS
- Thực hành gửi và nhận tin nhắn
- Hiểu vai trò của producer và consumer
- Quản lý tin nhắn: xem, xóa, giám sát
Bước 1: Tạo Hàng Đợi SQS
Thực hiện theo các bước dưới đây để khởi tạo một hàng đợi kiểu Standard:
- Truy cập SQS Console từ AWS Management Console.
- Chọn Create queue.
- Chọn loại hàng đợi: Standard.
- Đặt tên cho hàng đợi:
DemoQueue. - Thiết lập cấu hình:
- Message retention: 4 days
- Max message size: 256 KB
- Encryption: SSE-SQS (mặc định)
- Access policy: giữ mặc định hoặc tùy chỉnh nếu cần giới hạn quyền truy cập
- Bỏ qua phần Redrive/Dead-letter Queue (sẽ học sau)
- Nhấn Create queue để hoàn tất.
Bước 2: Gửi Tin Nhắn (Producer)
Sau khi hàng đợi được tạo, bạn có thể bắt đầu gửi tin nhắn:
- Trong giao diện hàng đợi, chọn Send and receive messages.
- Nhập nội dung vào phần Message body, ví dụ:
Hello World! - Nhấn Send message.
Bước 3: Nhận Tin Nhắn (Consumer)
Consumer là thành phần lấy và xử lý tin nhắn từ hàng đợi:
- Ở phần dưới của trang, chọn Poll for messages.
- Danh sách tin nhắn sẽ hiển thị (tối đa 10 tin/lần poll):
- Xem chi tiết nội dung và metadata
- Kiểm tra trường Receive count (số lần được nhận)
- Nhấn Delete để xóa tin nhắn sau khi xử lý
- Lưu ý: Nếu không xóa, sau thời gian Visibility Timeout (mặc định 30 giây), tin nhắn sẽ xuất hiện trở lại trong hàng đợi.
Bước 4: Gửi Nhiều Tin Nhắn
Thử gửi thêm một vài tin nhắn để thấy cơ chế xử lý hàng loạt:
Hello World 2Hello World 3
Khi chọn Poll for messages, bạn có thể nhận tối đa 10 tin nhắn/lượt.
Amazon SQS là một thành phần quan trọng trong kiến trúc hệ thống phân tán hiện đại. Với khả năng mở rộng cao, độ trễ thấp, và khả năng tách biệt các tầng xử lý, SQS mang đến một nền tảng mạnh mẽ để xây dựng các hệ thống linh hoạt, chịu tải tốt và dễ bảo trì.
Bài viết cùng chủ đề:
Amazon Simple Notification Service (AWS SNS) – Bài 20
