Câu hỏi thường gặp về Amazon SQS

Bạn chỉ phải trả cho những gì bạn sử dụng và không có mức phí tối thiểu.

Chi phí cho Amazon SQS được tính theo yêu cầu, cộng thêm phí di chuyển dữ liệu dành cho dữ liệu được di chuyển ra khỏi Amazon SQS (trừ khi dữ liệu được di chuyển sang các phiên bản Amazon Elastic Compute Cloud (EC2) hoặc sang các chức năng AWS Lambda trong cùng một khu vực). Để xem thống kê giá chi tiết với mỗi loại hàng đợi và khu vực, hãy xem Giá Amazon SQS.

Bậc miễn phí của Amazon SQS cung cấp cho bạn 1 triệu yêu cầu mỗi tháng không tính phí.

Có nhiều ứng dụng quy mô nhỏ có thể hoạt động hoàn toàn chỉ trong giới hạn của Bậc miễn phí. Tuy nhiên, các loại phí di chuyển dữ liệu vẫn có thể áp dụng. Để biết thêm thông tin, tham khảo Định giá Amazon SQS.

Bậc miễn phí là ưu đãi theo tháng. Quyền sử dụng miễn phí sẽ không được tích trữ qua nhiều tháng.

Có, cho bất kỳ yêu cầu nào vượt quá bậc miễn phí. Tất cả các yêu cầu Amazon SQS đều có thể tính phí và chúng được tính cùng một giá.

Không. Các hoạt động hàng loạt (SendMessageBatch, DeleteMessageBatch và ChangeMessageVisibilityBatch) đều có phí tương đương các yêu cầu Amazon SQS khác. Bằng cách nhóm tin nhắn thành các lô, bạn có thể giảm được chi phí Amazon SQS.

Không có bất kỳ chi phí khởi điểm nào để bắt đầu sử dụng Amazon SQS. Vào cuối tháng, thẻ tín dụng của bạn sẽ được tự động tính phí cho lượng sử dụng trong tháng đó.

Bạn có thể xem các lượt tính phí trong giai đoạn tính phí hiện tại bất cứ lúc nào tại trang web của AWS:

1. Đăng nhập vào tài khoản AWS của bạn.
2. Trong Tài khoản dịch vụ web của bạn, hãy chọn Hoạt động tài khoản.

Bạn có thể dán thẻ và theo dõi các hàng đợi để phục vụ quản lý tài nguyên và chi phí bằng cách sử dụng các thẻ phân bổ. Mỗi thẻ là một nhãn siêu dữ liệu bao gồm một cặp từ khóa-giá trị. Ví dụ: bạn có thể dán thẻ cho các hàng đợi của mình bằng trung tâm chi phí và sau đó phân loại và theo dõi các chi phí của mình dựa trên các trung tâm chi phí này.

Để biết thêm thông tin, tham khảo Dán thẻ các hàng đợi Amazon SQS trong Hướng dẫn nhà phát triển Amazon SQS. Để biết thêm thông tin về việc dán thẻ phân bổ chi phí cho các tài nguyên AWS, tham khảo Sử dụng các Thẻ phân bổ chi phí trong Hướng dẫn người dùng về Quản lý hóa đơn và chi phí AWS.

Trừ khi có thông báo khác, các mức giá của chúng tôi không bao gồm bất cứ khoản thuế hay thuế hải quan áp dụng nào như thuế GTGT hay thuế doanh thu.

Đối với khách hàng có địa chỉ ghi hóa đơn ở Nhật Bản, việc sử dụng dịch vụ AWS tại bất kỳ khu vực nào cũng phải tuân thủ Thuế tiêu thụ của Nhật Bản. Để biết thêm thông tin, hãy tham khảo Câu hỏi thường gặp về Thuế tiêu thụ Amazon Web Services.

Có. Bạn có thể giúp ứng dụng của mình trở nên linh hoạt và dễ thay đổi quy mô hơn bằng cách sử dụng Amazon SQS với các dịch vụ điện toán như Amazon EC2, Amazon Elastic Container Service (ECS) và AWS Lambda, cũng như với các dịch vụ lưu trữ và cơ sở dữ liệu như Amazon Simple Storage Service (Amazon S3) và Amazon DynamoDB.

Bạn có thể truy cập vào Amazon SQS thông qua Bảng điều khiển quản lý AWS, bảng này giúp bạn tạo hàng đợi Amazon SQS và gửi các tin nhắn một cách dễ dàng.

Amazon SQS cũng cung cấp API dịch vụ web. Amazon SQS còn được tích hợp với các SDK AWS, cho phép bạn làm việc với ngôn ngữ lập trình mà bạn lựa chọn.

Để biết thêm thông tin về các thao tác đối với hàng đợi tin nhắn, hãy xem Tài liệu tham khảo về API Amazon SQS.

Chỉ có chủ sở hữu tài khoản AWS (hoặc một tài khoản AWS mà chủ sở hữu tài khoản đã ủy quyền) mới có thể thực hiện các hoạt động lên một hàng đợi tin nhắn Amazon SQS.

Có. Bạn có thể tận dụng quy mô, chi phí thấp và tính khả dụng cao của Amazon SQS mà không phải lo lắng về chi phí cố định cao của việc chạy cụm JMS của riêng mình. 

Amazon cung cấp Thư viện tin nhắn Java Amazon SQS áp dụng đặc điểm kỹ thuật JMS 1.1 và sử dụng Amazon SQS dưới dạng nhà cung cấp JMS. Để biết thêm thông tin, hãy tham khảo phần Sử dụng JMS với Amazon SQS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Dịch vụ thông báo Java (JMS)

Tất cả các tin nhắn đều có một ID toàn cục riêng biệt mà Amazon SQS sẽ trả lại khi tin nhắn được được chuyển tới hàng đợi tin nhắn. ID này là không bắt buộc để thực hiện bất cứ hành động nào khác lên tin nhắn, nhưng ID sẽ hữu ích cho việc theo dõi biên lai của một tin nhắn nhất định trong hàng đợi tin nhắn.

Khi bạn nhận một tin nhắn từ hàng đợi tin nhắn, phản hồi sẽ bao gồm một tên biên lai mà bạn bắt buộc phải cung cấp khi xóa tin nhắn.

Để biết thêm thông tin, hãy xem phần Mã định danh hàng đợi và tin nhắn trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Trong Amazon SQS, bạn có thể sử dụng API hoặc bảng điều khiển để cấu hình các hàng đợi thư không thể gửi đến người nhận, những hàng đợi này nhận tin nhắn từ các hàng đợi có nguồn khác. Khi cấu hình hàng đợi thư không thể gửi đến người nhận, bạn cần phải đặt quyền thích hợp để chuyển tiếp hàng đợi thư không thể gửi đến người nhận bằng cách sử dụng RedriveAllowPolicy.

RedriveAllowPolicy bao gồm các tham số để cấp quyền chuyển tiếp hàng đợi thư không thể gửi đến người nhận. Chuỗi này xác định hàng đợi từ nguồn nào có thể chỉ định hàng đợi thư không thể gửi đến người nhận làm đối tượng JSON.

Sau khi bạn tạo hàng đợi thư không thể gửi đến người nhận, hàng đợi này sẽ nhận các tin nhắn sau khi số lần thử xử lý không thành công đạt mức tối đa. Bạn có thể sử dụng các hàng đợi thư không thể gửi để cô lập các tin nhắn không xử lý được để sau này phân tích.

Để biết thêm thông tin, hãy xem Sử dụng hàng đợi thư không gửi được với Amazon SQS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Thời gian ngắt hiển thị là một khoảng thời gian mà ở đó Amazon SQS ngăn không cho các thành phần tiêu thụ khác tiếp nhận và xử lý một tin nhắn. Để biết thêm thông tin, hãy tham khảo Thời gian chờ hiển thị trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Có. Một tin nhắn Amazon SQS có thể chứa tới 10 thuộc tính siêu dữ liệu. Bạn có thể sử dụng các thuộc tính tin nhắn để tách rời nội dung một tin nhắn ra khỏi siêu dữ liệu mô tả tin nhắn đó. Việc này giúp bạn xử lý và lưu trữ thông tin với tốc độ và hiệu quả cao hơn bởi ứng dụng của bạn sẽ không phải xem xét qua toàn bộ tin nhắn trước khi có thể hiểu được cách xử lý nó.

Các thuộc tính tin nhắn Amazon SQS có hình thức là các nhóm tên-loại-giá trị. Các loại dữ liệu được hỗ trợ bao gồm chuỗi, nhị phân và số (bao gồm số nguyên, dấu phẩy động và double). Để biết thêm thông tin, hãy tham khảo phần Sử dụng các thuộc tính tin nhắn Amazon SQS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Để xác định giá trị thời gian trong hàng đợi, bạn có thể yêu cầu thuộc tính SentTimestamp khi nhận được một tin nhắn. Loại trừ giá trị đó khỏi các kết quả thời gian hiện tại trong giá trị thời gian trong hàng đợi.

Độ trễ thường thấy đối với các yêu cầu API SendMessage, ReceiveMessage và DeleteMessage thường nằm ở khoảng vài chục đến hơn một trăm mili giây.

Khi ID tài khoản AWS không khả dụng (ví dụ: khi một người dùng ẩn danh gửi một tin nhắn), Amazon SQS sẽ cung cấp địa chỉ IP.

Kiểm soát vòng dài của Amazon SQS là một phương án để thu hồi các tin nhắn từ các hàng đợi Amazon SQS của bạn. Mặc dù phương án kiểm soát vòng ngắn thông thường sẽ trả về ngay lập tức, kể cả nếu hàng đợi tin nhắn đang kiểm soát là rỗng, kiểm soát vòng dài sẽ không trả về một phản hồi cho đến khi một tin nhắn được chuyển đến hàng đợi tin nhắn, hoặc kiểm soát vòng dài hết thời gian khả dụng.

Kiểm soát vòng dài là một phương pháp không tốn kém để bạn thu hồi các tin nhắn từ hàng đợi Amazon SQS của mình ngay khi các tin nhắn trở nên khả dụng. Việc sử dụng kiểm soát vòng dài có thể giúp giảm chi phí sử dụng SQS, bởi vì bạn có thể giảm số lượng các phiên rỗng thu về. Để biết thêm thông tin, hãy tham khảo Kiểm soát vòng dài của Amazon SQS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Không. Các lượt gọi ReceiveMessage trong kiểm soát vòng dài được tính phí hoàn toàn tương tự với các lượt gọi kiểm soát vòng ngắn ReceiveMessage.

Trong gần như mọi trường hợp, kiểm soát vòng dài của Amazon SQS là phương án phù hợp hơn kiểm soát vòng ngắn. Các yêu cầu kiểm soát vòng dài cho phép các người tiêu dùng hàng đợi của bạn nhận các tin nhắn ngay khi tin nhắn đến hàng đợi trong khi giảm số lượng các phiên ReceiveMessageResponse rỗng trả về.

Kiểm soát vòng dài Amazon SQS cho phép hiệu năng cao hơn với chi phí thấp hơn trong phần lớn các trường hợp sử dụng. Tuy nhiên, nếu ứng dụng của bạn yêu cầu một phản hồi ngay lập tức từ mỗi lượt gọi ReceiveMessage, bạn có thể sẽ không tận dụng được kiểm soát vòng dài nếu không có một số sự điều chỉnh trong ứng dụng của mình.

Ví dụ: nếu ứng dụng của bạn sử dụng một luồng đơn để kiểm soát vòng nhiều hàng đợi, việc chuyển đổi từ kiểm soát vòng ngắn sang kiểm soát vòng dài có thể sẽ không khả thi, bởi luồng đơn sẽ phải chờ cho đến thời gian ngắt kiểm soát vòng dài trên bất kỳ hàng đợi rỗng nào, làm trì hoãn quá trình xử lý của bất kỳ hàng đợi nào mà có thể chứa các tin nhắn.

Trong một ứng dụng như vậy, có một phương án hợp lý là sử dụng một luồng đơn để xử lý duy nhất một hàng đợi, cho phép ứng dụng tận dụng các lợi ích mà kiểm soát vòng dài Amazon SQS mang lại.

Nhìn chung, bạn nên sử dụng tối đa là 20 giây cho thời gian ngắt kiểm soát vòng dài. Bởi nếu giá trị thời gian ngắt kiểm soát vòng dài càng cao thì số lượng các phiên bản ReceiveMessageResponse rỗng được trả về sẽ càng giảm, nên hãy cố gắng đặt thời gian ngắt kiểm soát vòng dài càng cao càng tốt.

Nếu thời gian tối đa 20 giây không phù hợp với ứng dụng của bạn (xem ví dụ trong câu hỏi trước), hãy đặt một thời gian ngắt kiểm soát vòng dài ngắn hơn, thậm chí đến 1 giây.

Tất cả các AWS SDK đều mặc định có thể hoạt động được với các kiểm soát vòng dài 20 giây. Nếu bạn không sử dụng một AWS SDK nào để truy cập vào Amazon SQS, hoặc nếu bạn cố tình cấu hình AWS SDK của mình để có thời gian ngắt ngắn hơn, bạn có thể sẽ cần phải điều chỉnh ứng dụng khách Amazon SQS của mình để cho phép các yêu cầu dài hơn hoặc để sử dụng một thời gian ngắt kiểm soát vòng ngắn hơn.

AmazonSQSBufferedAsyncClient cho Java giúp triển khai một giao diện AmazonSQSAsyncClient và bổ sung một số chức năng quan trọng:

• Xếp loạt tự động nhiều yêu cầu SendMessage, DeleteMessage, hoặc ChangeMessageVisibility mà không yêu cầu bất kỳ thay đổi nào từ phía ứng dụng
• Tìm nạp trước các tin nhắn vào một đệm cục bộ cho phép ứng dụng của bạn có thể xử lý ngay lập tức các tin nhắn từ Amazon SQS mà không phải đợi trong khi các tin nhắn được thu hồi

Khi làm việc cùng nhau, chức năng xếp loạt tự động và tìm nạp trước sẽ tăng thông lượng và giảm độ trễ của ứng dụng của bạn trong khi làm giảm các chi phí bằng cách đưa ra ít yêu cầu Amazon SQS hơn. Để biết thêm thông tin, hãy tham khảo Phân nhóm yêu cầu và tạo bộ đệm phía máy khách trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Bạn có thể tải về AmazonSQSBufferedAsyncClient thông qua SDK AWS dành cho Java.

Không. AmazonSQSBufferedAsyncClient cho Java đã được áp dụng dưới dạng thay thế tạm thời cho AmazonSQSAsyncClient hiện tại.

Nếu bạn cập nhật ứng dụng của mình để sử dụng AWS SDK và thay đổi máy khách để sử dụng AmazonSQSBufferedAsyncClient cho Java thay vì AmazonSQSAsyncClient, ứng dụng của bạn sẽ nhận được các lợi ích bổ sung của chức năng xếp loạt tự động và tìm nạp trước.

1. Trong bảng điều khiển Amazon SQS, chọn một hàng đợi tiêu chuẩn Amazon SQS.
2. Bên dưới Hành động hàng đợi, chọn Đăng ký hàng đợi vào Chủ đề SNS từ danh sách thả xuống.
3. Trong hộp thoại, chọn chủ đề từ danh sách thả xuống Chọn một chủ đề, sau đó nhấp vào Đăng ký.

Để biết thêm thông tin, hãy tham khảo Đăng ký hàng đợi vào một Chủ đề Amazon SNS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Có. Bạn có thể xóa toàn bộ tin nhắn trong một hàng đợi tin nhắn Amazon SQS bằng cách sử dụng hành động PurgeQueue.

Khi bạn tẩy sạch một hàng đợi tin nhắn, tất cả các tin nhắn được gửi tới hàng đợi trước đó sẽ bị xóa. Bởi vì hàng đợi tin nhắn của bạn và các thuộc tính của nó vẫn còn đó, bạn sẽ không cần phải cấu hình lại hàng đợi; bạn có thể tiếp tục sử dụng hàng đợi này.

Để yêu cầu xóa một số tin nhắn cụ thể, hãy sử dụng các hành động DeleteMessage hoặc DeleteMessageBatch.

Để biết thêm thông tin, tham khảo Hướng dẫn sau: Xóa sạch tin nhắn khỏi một hàng đợi Amazon SQS.

Hàng đợi FIFO khả dụng tại tất cả các khu vực AWS có Amazon SQS. Xem tại đây để biết thông tin chi tiết về tình trạng sẵn có tại khu vực của Amazon SQS.

Hàng đợi FIFO được thiết kế để không bao giờ đưa ra tin nhắn lặp. Tuy nhiên, ứng dụng tạo tin nhắn của bạn có thể tạo tin nhắn lặp trong những trường hợp sau: chẳng hạn, nếu ứng dụng gửi tin nhắn, không nhận được phản hồi và thực hiện gửi lại chính những tin nhắn đó. Amazon SQS cung cấp chức năng chống lặp để ngăn ứng dụng tạo tin nhắn của bạn gửi những bản lặp. Tất cả những bản lặp tạo ra bởi ứng dụng tạo tin nhắn sẽ bị xóa trong mỗi khoảng chống lặp là 5 phút.

Đối với những hàng đợi tiêu chuẩn, bạn có thể thỉnh thoảng vẫn nhận được một bản lặp cho một tin nhắn (chuyển ít nhất một lần). Nếu bạn sử dụng hàng đợi tiêu chuẩn, bạn phải thiết kế để các ứng dụng không thay đổi giá trị (nghĩa là, những ứng dụng này không bị thay đổi tiêu cực khi xử lý cùng một tin nhắn nhiều hơn một lần).

Để biết thêm thông tin, hãy tham khảo phần Xử lý đúng một lần trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Không. Hàng đợi Amazon SQS tiêu chuẩn (tên mới cho những hàng đợi đang tồn tại) sẽ không đổi và bạn vẫn có thể tạo những hàng đợi tiêu chuẩn. Những hàng đợi này sẽ tiếp tục cung cấp khả năng mở rộng và lưu lượng cao nhất; tuy nhiên, bạn sẽ không được đảm bảo về thứ tự và các bản lặp sẽ xuất hiện.

Những hàng đợi tiêu chuẩn phù hợp với nhiều tình huống, chẳng hạn như phân phối công việc với nhiều người dùng không đổi.

Không. Bạn phải chọn loại hàng đợi khi khởi tạo. Tuy nhiên, bạn có thể duy chuyển sang hàng đợi FIFO. Để biết thêm thông tin, hãy tham khảo phần Di chuyển từ hàng đợi tiêu chuẩn sang hàng đợi FIFO trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Để tận dụng chức năng hàng đợi FIFO, bạn phai sử dụng AWS SDK mới nhất.

Hàng đợi FIFO sử dụng những thao tác API tương tự hàng đợi tiêu chuẩn và có cùng cơ chế nhận, xóa tin nhắn và thay đổi thời gian hiển thị tạm thời. Tuy nhiên, khi gửi tin nhắn, bạn phải nêu rõ ID nhóm tin nhắn. Để biết thêm chi tiết, hãy tham khảo Logic hàng đợi FIFO trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Một vài AWS và dịch vụ ngoài gửi thông báo tới Amazon SQS có thể không tương thích với hàng đợi FIFO dù cho phép bạn đặt hàng đợi FIFO làm mục tiêu.

Những chức năng sau của Dịch vụ AWS hiện đang không tương thích với hàng đợi FIFO:

• Tự động điều chỉnh quy mô hook vòng đời
• Hành động đối với quy tắc AWS IoT
• Hàng đợi thư không gửi được của AWS Lambda

Để biết thêm thông tin về khả năng tương thích với những dịch vụ khác của hàng đợi FIFO, tham khảo tài liệu về dịch vụ của bạn.

Hàng đợi FIFO hiện không tương thích với Amazon SQS Buffered Asynchronous Client.

Hàng đợi FIFO tương thích với Amazon SQS Extended Client Library cho Java và Amazon SQS Java Message Service (JMS) Client.

Hàng đợi FIFO hỗ trợ tất cả những chỉ số mà hàng đợi tiêu chuẩn hỗ trợ. Với hàng đợi FIFO, tất cả những chỉ số tương đối sẽ cho ra những số đếm chính xác. Chẳng hạn, những thông số sau của AWS CloudWatch sẽ được hỗ trợ:

• ApproximateNumberOfMessagesDelayed - Số lượng tin nhắn trong hàng đợi bị hoãn và không thể đọc ngay lập tức.
• ApproximateNumberOfMessagesVisible - Số lượng tin nhắn có thể thu lại được từ hàng đợi.
• ApproximateNumberOfMessagesNotVisible - Số lượng tin nhắn đang chuyển (đã được gửi cho máy khách nhưng chưa bị xóa hoặc chưa đến điểm cuối của cửa sổ hiển thị).

Các tin nhắn được nhóm thành các “bó” khác biệt và theo thứ tự trong mỗi hàng đợi FIFO. Cho mỗi ID nhóm tin nhắn, tất cả các tin nhắn được gửi và nhận theo thứ tự chặt chẽ. Tuy nhiên, các tin nhắn với những giá trị ID nhóm tin nhắn khác nhau có thể được gửi và nhận không theo thứ tự. Bạn phải gắn ID nhóm tin nhắn vào tin nhắn. Nếu bạn không cung cấp ID nhóm tin nhắn thì tác vụ sẽ thất bại.

Nếu nhiều lưu trữ (hoặc _ của cùng một lưu trữ) gửi tin nhắn có cùng ID nhóm tin nhắm được gửi tới hàng đợi FIFO, Amazon SQS sẽ gửi những tin nhắn này theo thứ tự thời gian những tin nhắn này đến nơi để xử lý. Để đảm bảo Amazon SQS bảo quản thứ tự những tin nhắn này được gửi và nhận, đảm bảo rằng những người gửi gửi những tin nhắn này với những ID nhóm tin nhắn riêng biệt.

Để biết thêm chi tiết, hãy tham khảo Logic hàng đợi FIFO trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Có. Một hoặc nhiều ứng dụng có thể gửi tin nhắn vào hàng đợi FIFO. Những tin nhắn này được lưu trữ theo thứ tự khi Amazon SQS nhận thành công.

Nếu nhiều ứng dụng gửi tin nhắn song song mà không đợi phản hồi thành công từ những thao tác SendMessage hoặc SendMessageBatch, thứ tự mỗi ứng dụng này sẽ không được bảo quản. Phản hồi của những thao tác SendMessage hoặc SendMessageBatch bao gồm thứ tự cuối cùng mà hàng đợi FIFO sử dụng để đưa tin nhắn vào hàng đợi để những mã ứng dụng song song từ nhiều ứng dụng có thể xác định thứ tự cuối cùng của các tin nhắn trong hàng đợi.

Theo thiết kế, hàng đợi FIFO của Amazon SQS không hỗ trợ tin nhắn từ cùng một nhóm tin nhắn tới hơn một người dùng trong cùng một lúc. Tuy nhiên, nếu hàng đợi FIFO của bạn có nhiều nhóm tin nhắn, bạn có thể tận dụng những người sử dụng song song cho phép Amazon SQS phục vụ những tin nhắn từ nhiều nhóm tin nhắn đến những người sử dụng khác nhau.

Theo mặc định, hàng đợi FIFO hỗ trợ lên tới 3.000 tin nhắn mỗi giây theo phương thức phân nhóm hoặc lên tới 300 tin nhắn mỗi giây (300 thao tác gửi, nhận hoặc xóa mỗi giây) khi không sử dụng phương thức phân nhóm. Nếu cần thông lượng cao hơn, bạn có thể bật chế độ thông lượng cao cho FIFO trên bảng điều khiển Amazon SQS. Bảng này sẽ hỗ trợ tới 70.000 tin nhắn mỗi giây mà không cần phương thức phân nhóm hoặc thậm chí nhiều hơn với phương thức phân nhóm. Để xem bảng phân tích chi tiết về hạn mức chế độ thông lượng cao FIFO cho mỗi khu vực, vui lòng xem Tài liệu AWS.

Tên của hàng đợi FIFO phải kết thúc bằng hậu tố .fifo. Hậu tố sẽ được tính vào giới hạn 80 ký tự của tên hàng đợi. Để xác định hàng đợi có phải FIFO hay không, bạn có thể kiểm tra xem tên hàng đợi có kết thúc với hậu tố đó không.

Amazon SQS lưu trữ tất cả những hàng đợi và tin nhắn vào một khu vực AWS khả dụng cao với nhiều Vùng Khả dụng (Availability Zones - AZs) thừa để không sự cố nào về máy tính, mạng và AZ có thể dẫn đến việc không thể truy cập tin nhắn. Để biết thêm thông tin, hãy tham khảo phần Khu vực và vùng sẵn sàng trong Hướng dẫn sử dụng Dịch vụ cơ sở dữ liệu quan hệ của Amazon.

Cơ chế xác thực cũng đảm bảo rằng các tin nhắn được lưu trữ trên hàng đợi tin nhắn Amazon SQS sẽ được bảo mật an toàn khỏi những truy cập trái phép. Bạn có thể kiểm soát ai là người gửi tin nhắn vào hàng đợi và người có thể nhận được tin nhắn từ hàng đợi tin nhắn. Để tăng độ bảo mật, bạn có thể xây dựng ứng dụng để mã hóa tin nhắn trước khi đưa chúng vào hàng đợi.

Amazon SQS có hệ thống cấp quyền dựa trên nguồn sử dụng những chính sách được viết ở cùng một ngôn ngữ với những chính sách trong Quản lý danh tính và truy cập trong AWS (IAM): chẳng hạn như bạn có thể sử dụng các biến như trong chính sách của IAM. Để biết thêm thông tin, hãy tham khảo Minh họa chính sách của Amazon SQS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Amazon SQS hỗ trợ các giao thức HTTP trên SSL (HTTPS) và Bảo mật lớp vận chuyển (Transport Layer Security - TLS). Hầu hết các khách hàng có thể đàm phán tự động để sử dụng những phiên bản mới hơn của TLS mà không cần thay đổi mã hoặc cấu hình. Amazon SQS hỗ trợ các phiên bản 1.0, 1.1 và 1.2 của giao thức Bảo mật lớp vận chuyển (Transport Layer Security - TLS) ở tất cả các khu vực.

Khi Amazon SQS gửi lại tin nhắn cho bạn, tin nhắn sẽ nằm trong hàng đợi tin nhắn dù bạn có nhận được tin nhắn thật sự hay không. Bạn có trách nhiệm xóa tin nhắn và yêu cầu xóa xác nhận rằng bạn đã xử lý xong tin nhắn.

Nếu bạn không xóa tin nhắn, Amazon SQS sẽ gửi lại chúng khi nhận được yêu cầu nhận khác. Để biết thêm thông tin, hãy tham khảo Thời gian chờ hiển thị trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Không. Hàng đợi FIFO được thiết kế để không bao giờ đưa ra tin nhắn lặp.

Đối với những hàng đợi tiêu chuẩn, trong những trường hợp hy hữu, bạn có thể nhận được những tin nhắn vừa được xóa lần thứ hai. 

Khi bạn đưa ra yêu cầu DeleteMessage đối với tin nhắn đã xóa từ trước, Amazon SQS sẽ đưa ra thông báo phản hồi thành công.

SSE cho phép bạn truyền những dữ liệu nhạy cảm vào hàng đợi được mã hóa. Mã hóa phía máy chủ bảo vệ nội dung tin nhắn trong hàng đợi Amazon SQS bằng cách sử dụng những khóa được quản lý trong Dịch vụ quản lý khóa của AWS (AWS KMS). SSE mã hóa tin nhắn ngay khi Amazon SQS nhận được chúng. Các tin nhắn được lưu trữ ở dạng mã hóa và Amazon SQS sẽ giải mã những tin nhắn này chỉ khi chúng được gửi đến người sử dụng được cấp phép.

Để biết thêm thông tin, xem Bảo vệ dữ liệu sử dụng Mã hóa phía máy chủ (SSE) và AWS KMS trong Hướng dẫn cho nhà phát triển Amazon SQS.

Có. Để làm được việc này bạn cần cho phép sự tương thích giữa các dịch vụ AWS (vd. Amazon CloudWatch Events, Amazon S3 và Amazon SNS) và các Hàng đợi với SSE. Để có thêm hướng dẫn chi tiết, hãy xem phần Khả năng tương thích trong Hướng dẫn dành cho nhà phát triển SQS.  

Mã hóa phía máy chủ (SSE) cho Amazon SQS có sẵn tại tất cả khu vực AWS có Amazon SQS. Xem tại đây để biết thông tin chi tiết về tình trạng sẵn có tại khu vực của Amazon SQS.

Để bật SSE cho hàng đợi mới và hiện tại bằng API của Amazon SQS, ghi rõ ID của khóa chính khách hàng (CMK): bí danh, ARN của bí danh, ID khóa hoặc ARN khóa của CMK được quản lý bởi AWS hoặc CMK tùy chỉnh bằng cách đặt thuộc tính KmsMasterKeyId của thao tác CreateQueue hoặc SetQueueAttributes.

Để có hướng dẫn chi tiết, hãy xem phần Tạo hàng đợi Amazon SQS với Mã hóa phía máy chủ và Định cấu hình Mã hóa phía máy chủ (SSE) cho hàng đợi Amazon SQS hiện có trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Cả hàng đợi tiêu chuẩn và hàng đợi FIFO đều hỗ trợ SSE.

Trước khi bạn có thể sử dụng SSE, bạn phải cấu hình những chính sách khóa KMS của AWS để cho phép mã hóa hàng đợi và mã hóa và giải mã tin nhắn.

Để bật SSE cho một hàng đợi, bạn có thể sử dụng khóa chính khách hàng (CMK) quản lý bởi AWS cho Amazon SQS hoặc CMK tùy chỉnh. Để biết thêm thông tin, hãy xem Khóa chính của khách hàng trong Hướng dẫn dành cho nhà phát triển KMS của AWS.

Để gửi tin nhắn tới hàng đợi được mã hóa, ứng dụng phải có sự cho phép kms:GenerateDataKey và kms:Decrypt permissions cho CMK.

Để nhận tin nhắn từ hàng đợi được mã hóa, người dùng phải có sự cho phép kms:Decrypt cho bất kỳ CMK nào được sử dụng để mã hóa tin nhắn trong hàng đợi cụ thể. Nếu hàng đợi là một hàng đợi thư không gửi được, người dùng phải có quyền kms:Decrypt cho bất kỳ CMK nào được sử dụng để mã hóa tin nhắn trong hàng đợi nguồn.

Để biết thêm thông tin, hãy tham khảo Tôi cần có quyền nào để sử dụng SSE trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Amazon SQS không thu thêm phí. Tuy nhiên, có tính phí đối với các truy vấn từ Amazon SQS tới AWS KMS. Để biết thêm thông tin, hãy xem phần Giá dịch vụ quản lý khóa của AWS.

Mức phí sử dụng AWS KMS phụ thuộc vào khoảng thời gian tái sử dụng khóa dữ liệu được cấu hình cho các hàng đợi của bạn. Để biết thêm thông tin, hãy xem phần Làm thế nào để tôi ước lượng chi phí sử dụng AWS KMS của mình? trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

SSE mã hoá nội dung tin nhắn trong một hàng đợi Amazon SQS.

SSE không mã hoá những thành phần sau:

• Siêu dữ liệu hàng đợi (tên và thuộc tính hàng đợi)
• Siêu dữ liệu tin nhắn (ID tin nhắn, nhãn thời gian và các thuộc tính)
• Chỉ số theo hàng đợi

Amazon SQS tạo khóa dữ liệu dựa trên khóa chính của khách hàng (CMK) do AWS quản lý cho Amazon SQS hoặc một CMK tùy chỉnh để đem lại khả năng mã hóa phong bì và giải mã tin nhắn trong một khoảng thời gian có thể định cấu hình (từ 1 phút cho tới 24 giờ).

Để biết thêm thông tin, hãy tham khảo SSE cho Amazon SQS mã hóa gì? trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

SSE sử dụng thuật toán AES-GCM 256.

SSE không hạn chế thông lượng (TPS) của Amazon SQS. Số hàng đợi SSE mà bạn có thể tạo sẽ bị giới hạn theo:

• Khoảng thời gian tái sử dụng khóa dữ liệu (1 phút tới 24 giờ).
• Hạn mức AWS KMS cho mỗi tài khoản (mặc định là 100 TPS).
• Số người dùng hoặc tài khoản IAM có thể truy cập hàng đợi.
• Sự tồn tại của một danh sách công việc lớn (danh sách công việc lớn hơn sẽ cần thêm lệnh gọi AWS KMS).

Chẳng hạn hãy giả định các giới hạn sau đây:

• Bạn đặt khoảng thời gian tái sử dụng khóa dữ liệu là 5 phút (300 giây).
• Tài khoản KMS của bạn có một hạn mức TPS AWS KMS mặc định là 100 TPS.
• Bạn sử dụng hàng đợi Amazon SQS không có tồn đọng với 1 người dùng IAM cho thao tác SendMessage hoặc ReceiveMessage tới tất cả các hàng đợi.

Trong trường hợp này, bạn có thể tính số hàng đợi với Amazon SQS tối đa giả định như sau:

300 giây x 100 TPS / 1 người dùng IAM = 30.000 hàng đợi

Để ước lượng chi phí và hiểu rõ hoá đơn AWS của bạn, bạn có thể muốn biết tần suất Amazon SQS sử dụng CMK của bạn.

Lưu ý: Mặc dù công thức sau sẽ giúp bạn hình dung rõ về chi phí dự kiến, chi phí thực có thể sẽ cao hơn vì tính chất phân tán của Amazon SQS.

Để tính số yêu cầu API mỗi hàng đợi (R), hãy sử dụng công thức sau:

R = B / D * (2 * P + C)

B là khoảng thời gian tính phí (tính bằng giây)

D là khoảng thời gian tái sử dụng khoá dữ liệu (tính bằng giây)

P là số thực thể chính được tạo mà gửi đến hàng đợi Amazon SQS.

C là số thực thể chính đã dùng mà nhận từ hàng đợi Amazon SQS.

Quan trọng: Nhìn chung, việc tạo các thực thể chính sẽ gấp đôi chi phí so với sử dụng các thực thể chính. Để biết thêm thông tin, hãy tham khảo Khoảng thời gian tái sử dụng khoá dữ liệu hoạt động như thế nào? trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Nếu bên tạo và bên sử dụng có các tài khoản người dùng khác nhau, chi phí sẽ tăng lên.

Để biết thêm thông tin, hãy xem Làm thế nào để tôi ước lượng chi phí sử dụng AWS KMS của mình? trong Hướng dẫn dành cho nhà phát triển Amazon SQS

Có. Amazon SQS được cấp chứng nhận PCI DSS Cấp 1. Để biết thêm thông tin, hãy tham khảo mục Tuân thủ PCI.

Có, AWS đã mở rộng chương trình tuân thủ HIPAA để thêm Amazon SQS vào trong các Dịch vụ đủ điều kiện với HIPAA. Nếu bạn có một Thoả thuận hợp tác kinh doanh (BAA) với AWS, bạn có thể sử dụng Amazon SQS để xây dựng các ứng dụng đáp ứng với HIPAA của bạn, lưu trữ các tin nhắn đang được gửi và truyền các tin nhắn – bao gồm các tin nhắn có chứa thông tin về sức khoẻ được bảo vệ (PHI).

Nếu bạn đã có một BAA với AWS có hiệu lực, bạn có thể bắt đầu sử dụng Amazon SQS ngay lập tức. Nếu bạn chưa có BAA hay còn có câu hỏi về việc sử dụng AWS cho các ứng dụng phù hợp với HIPAA, hãy liên hệ với chúng tôi để biết thêm thông tin.

Lưu ý: Nếu bạn không muốn truyền PHI thông qua Amazon SQS (hoặc có tin nhắn lớn hơn 256 KB), thay vào đó bạn có thể gửi tải trọng tin nhắn Amazon SQS qua Amazon S3 bằng Thư viện máy khách mở rộng Amazon SQS cho Java (Amazon S3 là một Dịch vụ đáp ứng đủ điều kiện của HIPAA, trừ việc sử dụng Tính năng tăng tốc truyền của Amazon S3). Để biết thêm thông tin, hãy tham khảo phần Sử dụng Thư viện máy khách mở rộng Amazon SQS cho Java trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Việc lưu giữ tin nhắn lâu hơn sẽ đem lại sự linh động cao, cho phép kéo dài khoảng thời gian giữa việc tạo và sử dụng tin nhắn.

Bạn có thể cấu hình khoảng thời gian lưu giữ tin nhắn Amazon SQS từ 1 phút cho tới 14 ngày. Giá trị mặc định là 4 ngày. Khi đã đạt hạn mức lưu giữ tin nhắn, các tin nhắn của bạn sẽ được tự động xóa.

Để cấu hình khoảng thời gian lưu trữ tin nhắn, đặt thuộc tính MessageRetentionPeriod bằng bảng điều khiển hoặc bằng phương thức Distributiveness. Sử dụng thuộc tính này để chỉ định số giây tin nhắn này được lưu giữ trong Amazon SQS.

Bạn có thể dùng thuộc tính MessageRetentionPeriod để đặt khoảng thời gian lưu giữ tin nhắn từ 60 giây (1 phút) cho tới 1.209.600 giây (14 ngày). Để biết thêm thông tin về thao tác đối với thuộc tính tin nhắn này, hãy xem Tài liệu tham khảo về API Amazon SQS.

Để đặt cấu hình kích cỡ tin nhắn tối đa, hãy sử dụng bảng điều khiển hoặc phương thức SetQueueAttributes để đặt thuộc tính MaximumMessageSize. Thuộc tính này chỉ định số byte mà một tin nhắn Amazon SQS có thể chứa. Đặt thuộc tính này trong khoảng giá trị giữa 1.024 byte (1 KB) và 262.144 bye (256 KB). Để biết thêm thông tin, hãy tham khảo phần Sử dụng các thuộc tính tin nhắn Amazon SQS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Để gửi tin nhắn lớn hơn 256 KB, hãy dùng Thư viện máy khách mở rộng Amazon SQS cho Java. Thư viện này cho bạn gửi một tin nhắn Amazon SQS có chứa một tham chiếu cho một tải trọng tin nhắn trong Amazon S3 có dung lượng có thể lên đến 2 GB.

Tin nhắn Amazon SQS có thể chứa tới 256 KB dữ liệu văn bản, bao gồm XML, JSON và văn bản chưa định dạng. Các ký tự Unicode sau được chấp nhận:

#x9 | #xA | #xD | [#x20 to #xD7FF] | [#xE000 to #xFFFD] | [#x10000 to #x10FFFF]

Để biết thêm thông tin, hãy xem Thông số kỹ thuật của XML 1.0.

Một hàng đợi tin nhắn Amazon SQS đơn có thể chứa số lượng tin nhắn không giới hạn. Tuy nhiên, hạn mức số tin nhắn đang di chuyển của một hàng đợi tiêu chuẩn là 120.000 và 20.000 đối với một hàng đợi FIFO. Các tin nhắn ở trạng thái đang di chuyển sau khi đã được nhận từ hàng đợi của một thành phần sử dụng, nhưng chưa bị xóa khỏi hàng đợi.

Bạn có thể tạo bao nhiêu hàng đợi tin nhắn tùy thích.

Tên hàng đợi giới hạn ở 80 ký tự.

Bạn có thể sử dụng các chữ và số, dấu gạch ngang (-) và dấu gạch dưới (_).

Tên của một hàng đợi tin nhắn phải độc nhất trong một tài khoản AWS và trong một khu vực. Bạn có thể tái sử dụng tên của một hàng đợi tin nhắn sau khi bạn xóa hàng đợi tin nhắn ấy.

Bạn có thể liên kết một lệnh chính sách truy nhập (và chỉ định các quyền được cấp) với hàng đợi tin nhắn được chia sẻ. Amazon SQS cung cấp các API để tạo và quản lý các lệnh chính sách truy nhập:

• AddPermission
• RemovePermission
• SetQueueAttributes
• GetQueueAttributes

Để biết thêm thông tin, hãy xem Tài liệu tham khảo về API Amazon SQS.

Chủ của hàng đợi tin nhắn sẽ phải trả cho việc truy nhập hàng đợi tin nhắn được chia sẻ.

API Amazon SQS sử dụng một số tài khoản AWS để xác định người dùng AWS.

Để chia sẻ một hàng đợi tin nhắn tới một người dùng AWS, hãy cung cấp đường dẫn URL đầy đủ từ hàng đợi tin nhắn mà bạn muốn chia sẻ. Các tác vụ CreateQueue và ListQueues sẽ trả lại địa chỉ URL này trong phản hồi của các tác vụ ấy.

Có. Bạn có thể cấu hình một chính sách truy nhập cho phép các người dùng ẩn danh truy cập vào một hàng đợi tin nhắn.

API cấp quyền đem lại một giao diện để chia sẻ truy nhập tới một hàng đợi tin nhắn cho các nhà phát triển. Tuy nhiên, API này không thể cho phép truy nhập có điều kiện hoặc các trường hợp sử dụng phức tạp hơn.

Tác vụ SetQueueAttributes hỗ trợ đầy đủ ngôn ngữ trong chính sách truy nhập. Ví dụ: bạn có thể sử dụng ngôn ngữ trong chính sách để giới hạn truy nhập vào một hàng đợi tin nhắn theo địa chỉ IP và thời gian trong ngày. Để biết thêm thông tin, hãy tham khảo Minh họa chính sách của Amazon SQS trong Hướng dẫn dành cho nhà phát triển Amazon SQS.

Để biết về tính khả dụng của khu vực dịch vụ, hãy xem Bảng khu vực cơ sở hạ tầng toàn cầu AWS.

Không. Mỗi hàng đợi tin nhắn Amazon SQS độc lập với nhau trong mỗi khu vực.

Giá cả của Amazon SQS vẫn như nhau tại các khu vực, ngoại trừ tại Trung Quốc (Bắc Kinh). Để biết thêm thông tin, hãy xem phần Định giá Amazon SQS.

Bạn có thể chuyển dữ liệu giữa Amazon SQS và Amazon EC2 hoặc AWS Lambda miễn phí trong cùng một khu vực.

Khi bạn chuyển dữ liệu giữa Amazon SQS và Amazon EC2 hoặc AWS Lambda tại các khu vực khác nhau, bạn sẽ bị tính theo mức phí chuyển dữ liệu thông thường. Để biết thêm thông tin, hãy xem phần Định giá Amazon SQS.

Hàng đợi thư chết là một hàng đợi trong Amazon SQS có thể nhận tin nhắn do một hàng đợi nguồn gửi tới, nếu ứng dụng sử dụng sử dụng của hàng đợi nguồn không sử dụng được tin nhắn. Hàng đợi thư chết giúp bạn xử lý thất bại khi sử dụng tin nhắn và quản lý vòng đời của tin nhắn chưa được sử dụng dễ dàng hơn. Bạn có thể cấu hình thông báo cho bất kỳ tin nhắn nào được gửi tới hàng đợi thư chết, kiểm tra nhật ký để tìm ra những ngoại lệ có thể đã khiến chúng bị gửi tới hàng đợi và phân tích nội dung tin nhắn để chẩn đoán vấn đề của ứng dụng sử dụng. Sau khi khôi phục ứng dụng sử dụng, bạn có thể chuyển tiếp tin nhắn từ hàng đợi thư chết sang hàng đợi nguồn.

Khi bạn tạo hàng đợi nguồn, Amazon SQS cho phép bạn chỉ định một hàng đợi thư chết (DLQ) và điều kiện để SQS chuyển tin nhắn sang DLQ. Điều kiện chính là số lần một người sử dụng có thể nhận tin nhắn từ hàng đợi, được định nghĩa là maxReceiveCount. Cấu hình hàng đợi thư chết gắn với hàng đợi nguồn và maxReceiveCount được gọi là thiết lập chuyển tiếp. Khi ReceiveCount của một tin nhắn vượt quá maxReceiveCount của một hàng đợi, Amazon SQS được thiết kế để chuyển tin nhắn sang hàng đợi thư chết (với ID tin nhắn gốc). Ví dụ: nếu hàng đợi nguồn có thiết lập chuyển tiếp với maxReceiveCount là năm và người sử dụng của hàng đợi nguồn nhận một tin nhắn sáu lần mà không sử dụng thành công, SQS sẽ chuyển tin nhắn sang hàng đợi thư chết.

Thiết lập chuyển tiếp quản lý nửa đầu của vòng đời tin nhắn không được sử dụng bằng cách chuyển chúng từ hàng đợi nguồn sang hàng đợi thư chết. Lúc này, hàng đợi thư chết chuyển tiếp sang hàng đợi nguồn sẽ hoàn thành vòng đời hiệu quả bằng cách chuyển những tin nhắn này về lại hàng đợi nguồn của chúng như minh họa dưới đây.

Đầu tiên, hàng đợi thư chết cho phép bạn điều tra một mẫu các tin nhắn có sẵn trong hàng đợi thư chết bằng cách hiển thị thuộc tính tin nhắn và siêu dữ liệu liên quan. Sau đó, khi bạn đã hoàn thành điều tra, bạn có thể chuyển chúng trở lại (các) hàng đợi nguồn. Bạn cũng có thể chọn tốc độ chuyển tiếp để đặt hình tốc độ chuyển tin nhắn từ hàng đợi thư chết sang hàng đợi nguồn cho Amazon SQS.

Có. Tuy nhiên, bạn phải sử dụng hàng đợi thư chết FIFO với hàng đợi FIFO. (Tương tự, bạn chỉ có thể sử dụng hàng đợi thư chết tiêu chuẩn với hàng đợi tiêu chuẩn.)