คำถามที่พบบ่อยเกี่ยวกับ Amazon SQS

จ่ายเฉพาะสิ่งที่คุณใช้เท่านั้นและไม่มีค่าธรรมเนียมขั้นต่ำ

ค่าใช้จ่ายของ Amazon SQS จะคำนวณตามคำขอ บวกกับค่าบริการถ่ายโอนข้อมูลสำหรับข้อมูลที่ถ่ายโอนจาก Amazon SQS (เว้นแต่จะมีการถ่ายโอนข้อมูลไปยังอินสแตนซ์ Amazon Elastic Compute Cloud (EC2) หรือฟังก์ชัน AWS Lambda ภายในรีเจี้ยนเดียวกัน) โปรดดูการแจกแจงราคาโดยละเอียดตามประเภทของคิวและรีเจี้ยนที่ราคา Amazon SQS

Amazon SQS Free Tier ให้คุณใช้ได้ 1 ล้านคำขอต่อเดือนโดยไม่มีค่าบริการ

แอปพลิเคชันขนาดเล็กจำนวนมากสามารถทำงานทั้งหมดได้ภายในขอบเขตของ Free Tier แต่อาจมีค่าบริการถ่ายโอนข้อมูล โปรดดูข้อมูลเพิ่มเติมที่ราคา Amazon SQS

Free Tier เป็นข้อเสนอรายเดือน การใช้งานฟรีไม่สามารถเก็บสะสมข้ามเดือนได้

ใช่ สำหรับคำขอที่นอกเหนือจาก Free Tier คำขอ Amazon SQS ทั้งหมดจะมีการคิดค่าบริการและเรียกเก็บเงินในอัตราเดียวกัน

ไม่ การดำเนินการเป็นชุด (SendMessageBatch, DeleteMessageBatch และ ChangeMessageVisibilityBatch) ล้วนมีค่าใช้จ่ายเช่นเดียวกับคำขอ Amazon SQS อื่นๆ โดยการจับกลุ่มข้อความเป็นชุด คุณสามารถลดค่าใช้จ่ายของ Amazon SQS ลงได้

ไม่มีค่าธรรมเนียมเริ่มต้นในการเริ่มใช้ Amazon SQS ในตอนสิ้นเดือน ระบบจะเรียกเก็บค่าบริการสำหรับการใช้งานในเดือนนั้นจากบัตรเครดิตของคุณโดยอัตโนมัติ

คุณสามารถดูค่าบริการสำหรับช่วงเวลาที่เรียกเก็บเงินปัจจุบันได้ทุกเมื่อที่เว็บไซต์ AWS:

1. เข้าสู่บัญชี AWS ของคุณ
2. ภายใต้ Your Web Services Account (บัญชี Web Services ของคุณ) เลือก Account Activity (กิจกรรมในบัญชี)

คุณสามารถแท็กและติดตามคิวสำหรับการจัดการค่าใช้จ่ายและทรัพยากรได้โดยใช้แท็กการจัดสรรต้นทุน แท็กคือป้ายเมตาดาต้าที่ประกอบด้วยคู่คีย์-ค่า ตัวอย่างเช่น คุณสามารถแท็กคิวได้โดยศูนย์ต้นทุน จากนั้นจัดหมวดหมู่แล้วติดตามค่าใช้จ่ายตามศูนย์ต้นทุนเหล่านี้

โปรดดูข้อมูลเพิ่มเติมที่การแท็กคิว Amazon SQS ของคุณในคู่มือ Amazon SQS Developer สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการแท็กการจัดสรรต้นทุนของทรัพยากร AWS ดูที่การใช้แท็กการจัดสรรต้นทุนในคู่มือผู้ใช้ AWS Billing and Cost Management

ราคาของเราไม่รวมภาษีและอากรที่เกี่ยวข้องใดๆ เช่น VAT หรือภาษีขายที่เกี่ยวข้อง เว้นแต่ระบุไว้เป็นอย่างอื่น

สำหรับลูกค้าที่มีที่อยู่เรียกเก็บเงินในประเทศญี่ปุ่น การใช้ AWS ในทุกภูมิภาคจะต้องเสียภาษีโภคภัณฑ์ของประเทศญี่ปุ่นด้วย โปรดดูข้อมูลเพิ่มเติมที่คำถามที่พบบ่อยเกี่ยวกับภาษีการบริโภคของ Amazon Web Services

ใช่ คุณสามารถทำให้แอปพลิเคชันมีความยืดหยุ่นและปรับขนาดได้มากขึ้นด้วยการใช้ Amazon SQS ที่มีบริการประมวลผล เช่น Amazon EC2, Amazon Elastic Container Service (ECS) และ AWS Lambda ตลอดจนบริการจัดเก็บข้อมูลและฐานข้อมูล เช่น Amazon Simple Storage Service (Amazon S3) และ Amazon DynamoDB

คุณสามารถเข้าถึง Amazon SQS ได้โดยใช้คอนโซลการจัดการของ AWS ซึ่งช่วยให้คุณสร้างคิว Amazon SQS และส่งข้อความได้อย่างง่ายดาย

นอกจากนี้ Amazon SQS ยังมี API สำหรับบริการเว็บ ซึ่งผสานรวมกับ AWS SDK ที่ช่วยให้สามารถทำงานในภาษาการเขียนโปรแกรมที่คุณเลือกได้ด้วยเช่นกัน

โปรดดูข้อมูลเกี่ยวกับการดำเนินการคิวข้อความที่ข้อมูลอ้างอิง Amazon SQS API

เฉพาะเจ้าของบัญชี AWS (หรือบัญชี AWS ที่เจ้าของบัญชีได้มอบสิทธิ์ให้) เท่านั้นที่สามารถดำเนินการเกี่ยวกับคิวข้อความ Amazon SQS ได้

ใช่ คุณสามารถใช้ประโยชน์จากขนาด ต้นทุนต่ำ และความพร้อมใช้งานสูงของ Amazon SQS ได้โดยไม่ต้องกังวลและไม่มีค่าใช้จ่ายสูงในการเรียกใช้คลัสเตอร์ JMS ของคุณเอง 

Amazon มีAmazon SQS Java Messaging Library ที่นำข้อกำหนด JMS 1.1 ไปใช้และใช้ Amazon SQS เป็นผู้ให้บริการ JMS โปรดดูข้อมูลเพิ่มเติมที่การใช้ JMS กับ Amazon SQS ในคู่มือนักพัฒนา Amazon SQS

Java Message Service (JMS)

ข้อความทั้งหมดมีรหัสที่ไม่ซ้ำกันทั่วโลก ซึ่ง Amazon SQS ได้ส่งกลับเมื่อระบบได้จัดส่งข้อความไปยังคิวข้อความ รหัสไม่มีความจำเป็นต่อการดำเนินการใดๆ เกี่ยวกับข้อความ แต่ก็มีประโยชน์สำหรับการติดตามการรับข้อความที่เจาะจงในคิวข้อความ

เมื่อคุณได้รับข้อความจากคิวข้อความ การตอบกลับจะรวมถึงตัวระบุการรับที่คุณต้องแจ้งเมื่อมีการลบข้อความ

โปรดดูข้อมูลเพิ่มเติมที่ตัวระบุคิวและข้อความในคู่มือนักพัฒนา Amazon SQS

ใน Amazon SQS คุณสามารถใช้ API หรือ Console เพื่อกำหนดค่าคิวที่ทำไม่สำเร็จซึ่งได้รับข้อความจากคิวแหล่งอื่น เมื่อกำหนดค่าคิวที่ทำไม่สำเร็จ คุณจะต้องตั้งค่าสิทธิ์การอนุญาตที่เหมาะสมให้เพื่อขับเคลื่อนคิวที่ทำไม่สำเร็จอีกครั้งโดยใช้ RedriveAllowPolicy

RedriveAllowPolicy มีพารามิเตอร์สำหรับสิทธิ์อนุญาตในการขับเคลื่อนคิวที่ทำไม่สำเร็จอีกครั้ง ซึ่งจะกำหนดว่าคิวต้นทางใดสามารถระบุคิวที่ทำไม่สำเร็จเป็นอ็อบเจกต์ JSON

เมื่อคุณทำคิวที่ทำไม่สำเร็จ คิวดังกล่าวจะได้รับข้อความหลังจากพยายามประมวลผลจนครบจำนวนสูงสุดแต่ทำไม่สำเร็จ คุณสามารถใช้คิวที่ทำไม่สำเร็จแยกข้อความที่ไม่สามารถประมวลผลสำหรับการวิเคราะห์ในภายหลังได้

โปรดดูข้อมูลเพิ่มเติมที่การใช้คิวที่ทำไม่สำเร็จของ Amazon SQS ในคู่มือนักพัฒนา Amazon SQS

หมดเวลาแสดงผลคือช่วงระยะเวลาที่ Amazon SQS ป้องกันไม่ให้ส่วนประกอบอื่นๆ ที่ใช้ได้รับข้อความเพื่อประมวลผล โปรดดูข้อมูลเพิ่มเติมที่หมดเวลาแสดงผลในคู่มือนักพัฒนา Amazon SQS

ใช่ ข้อความ Amazon SQS มีคุณลักษณะเมตาดาต้าได้สูงสุด 10 รายการ คุณสามารถใช้คุณลักษณะข้อความเพื่อแยกตัวข้อความออกจากเมตาดาต้าที่อธิบายข้อความดังกล่าว การทำเช่นนี้ช่วยให้ประมวลผลและจัดเก็บข้อมูลได้ด้วยความเร็วและประสิทธิภาพมากขึ้น เนื่องจากแอปพลิเคชันไม่ต้องตรวจสอบข้อความทั้งหมดก่อนที่จะทำความเข้าใจวิธีการประมวลผลนั้น

คุณลักษณะข้อความ Amazon SQS ใช้รูปแบบสามชนิดของ name-type-value ประเภทที่รองรับประกอบด้วยสตริง เลขฐานสอง และจำนวน (รวมถึงจำนวนเต็ม จุดทศนิยมลอยตัว และสองเท่า) โปรดดูข้อมูลเพิ่มเติมที่การใช้คุณลักษณะข้อความ Amazon SQS ในคู่มือนักพัฒนา Amazon SQS

หากต้องการกำหนดค่า time-in-queue คุณสามารถขอคุณลักษณะ SentTimestamp ได้เมื่อรับข้อความ การลบค่านั้นออกจากผลเวลาปัจจุบันในค่า time-in-queue

เวลาแฝงโดยทั่วไปของคำขอ API สำหรับ SendMessage, ReceiveMessage และ DeleteMessage อยู่ในหลักสิบหรือต่ำกว่าร้อยของมิลลิวินาที

เมื่อไม่มีรหัสบัญชี AWS (ตัวอย่างเช่น เมื่อผู้ใช้ที่ไม่ระบุชื่อส่งข้อความ) Amazon SQS จะให้ที่อยู่ IP

การโพลแบบยาวของ Amazon SQS เป็นวิธีหนึ่งในการเรียกใช้ข้อความจากคิว Amazon SQS ในขณะที่การโพลแบบสั้นปกติส่งคืนข้อมูลในทันทีแม้ว่าคิวข้อมูลที่ถูกโพลนั้นว่างเปล่า การโพลแบบยาวจะไม่ส่งคืนการตอบกลับจนกว่าข้อความจะมาถึงในคิวข้อความหรือโพลแบบยาวหมดเวลาลง

การโพลแบบยาวทำให้การเรียกใช้ข้อความจากคิว Amazon SQS ทันทีที่ข้อความนั้นพร้อมใช้งานมีราคาที่ย่อมเยา การใช้การโพลแบบยาวอาจลดค่าใช้จ่ายของการใช้ SQS ลง เนื่องจากคุณสามารถลดจำนวนการรับที่ว่างเปล่าได้ โปรดดูข้อมูลเพิ่มเติมที่การโพลแบบยาวของ Amazon SQS ในคู่มือนักพัฒนา Amazon SQS

ไม่ การเรียกใช้ ReceiveMessage การโพลแบบยาวจะถูกเรียกเก็บเงินเช่นเดียวกับการเรียกใช้ ReceiveMessage การโพลแบบสั้น

ในเกือบทุกกรณี การโพลแบบยาวของ Amazon SQS ได้รับความนิยมกว่าการโพลแบบสั้น คำขอโพลแบบยาวช่วยให้ผู้ใช้บริการคิวของคุณได้รับข้อความทันทีที่มีข้อความมาถึงที่คิว ในเวลาเดียวกันระบบก็ลดจำนวนอินสแตนซ์ ReceiveMessageResponse ว่างเปล่าที่ถูกส่งคืนลง

การโพลแบบยาวของ Amazon SQS ให้ผลลัพธ์ที่มีประสิทธิภาพสูงขึ้นด้วยต้นทุนที่ลดลงในกรณีใช้งานส่วนใหญ่ แต่หากแอปพลิเคชันของคุณคาดหวังการตอบสนองทันทีจากการเรียกใช้ ReceiveMessage คุณอาจไม่สามารถใช้ประโยชน์จากการโพลแบบยาวได้โดยที่ไม่ต้องมีการปรับเปลี่ยนบางอย่างแก่แอปพลิเคชันนั้น

ตัวอย่างเช่น หากแอปพลิเคชันใช้เธรดเดี่ยวในการโพลคิวหลายคิว การสลับจากการโพลแบบสั้นเป็นการโพลแบบยาวอาจจะไม่สามารถใช้งานได้ เนื่องจากเธรดเดี่ยวจะรอให้หมดเวลาการโพลแบบยาวที่คิวว่างเปล่า ซึ่งทำให้การประมวลผลของคิวที่อาจมีข้อความเกิดความล่าช้า

ในแอปพลิเคชันดังกล่าว ควรใช้เธรดเดี่ยวในการประมวลผลคิวเดียวเท่านั้นเพื่อช่วยให้แอปพลิเคชันสามารถใช้ประโยชน์จากการโพลแบบยาวที่ Amazon SQS มีให้

โดยทั่วไปแล้ว 20 วินาทีควรเป็นเวลาสูงสุดที่ใช้สำหรับหมดเวลาการโพลแบบยาว เนื่องจากค่าหมดเวลาการโพลแบบยาวที่สูงขึ้นนั้นลดจำนวนอินสแตนซ์ ReceiveMessageResponse ว่างเปล่าที่ถูกส่งคืน ให้พยายามตั้งค่าหมดเวลาการโพลแบบยาวให้สูงที่สุดเท่าที่จะทำได้

หากเวลาสูงสุด 20 วินาทีไม่สามารถใช้ได้กับแอปพลิเคชันของคุณ (ดูตัวอย่างในคำถามก่อนหน้านี้) ให้ตั้งค่าหมดเวลาการโพลแบบยาวให้สั้นลง โดยให้สั้นเท่ากับ 1 วินาที

AWS SDK ทั้งหมดสามารถใช้ได้กับการโพลแบบยาว 20 วินาทีตามค่าเริ่มต้น หากคุณไม่ได้ใช้ AWS SDK เพื่อเข้าถึง Amazon SQS หรือหากคุณกำหนดค่า AWS SDK ไว้โดยเฉพาะเพื่อให้มีการหมดเวลาที่สั้นลง คุณอาจต้องปรับไคลเอ็นต์ของ Amazon SQS ให้ส่งคำขอยาวขึ้นหรือใช้หมดเวลาการโพลแบบยาวที่สั้นลง

AmazonSQSBufferedAsyncClient for Java มีการนำอินเทอร์เฟซ AmazonSQSAsyncClient มาใช้แล้วเพิ่มคุณสมบัติสำคัญหลายรายการ:

• การสร้างชุดคำขออัตโนมัติของ SendMessage, DeleteMessage หรือ ChangeMessageVisibility หลายรายการโดยที่ไม่ต้องทำการเปลี่ยนแปลงแก่แอปพลิเคชัน
• การพรีเฟชข้อความลงในบัฟเฟอร์เฉพาะที่ช่วยให้แอปพลิเคชันสามารถประมวลผลข้อความจาก Amazon SQS ได้ทันทีโดยไม่ต้องรอข้อความที่จะถูกเรียก

ด้วยการทำงานร่วมกัน การสร้างชุดคำขออัตโนมัติและการพรีเฟชจะเพิ่มปริมาณการประมวลผลและลดเวลาแฝงของแอปพลิเคชัน ในเวลาเดียวกันก็ลดค่าใช้จ่ายโดยการส่งคำขอ Amazon SQS น้อยลง โปรดดูข้อมูลเพิ่มเติมที่การบัฟเฟอร์ฝั่งไคลเอ็นต์และการสร้างชุดคำขอในคู่มือนักพัฒนา Amazon SQS

คุณสามารถดาวน์โหลด AmazonSQSBufferedAsyncClient ให้เป็นส่วนหนึ่งของ AWS SDK for Java ได้

ไม่ คุณสามารถนำ AmazonSQSBufferedAsyncClient for Java มาใช้เป็นบริการที่สามารถใช้ทดแทน AmazonSQSAsyncClient ที่มีอยู่ได้

หากคุณอัปเดตแอปพลิเคชันเพื่อใช้ AWS SDK ล่าสุดและเปลี่ยนไคลเอ็นต์เพื่อใช้ AmazonSQSBufferedAsyncClient for Java แทน AmazonSQSAsyncClient แอปพลิเคชันของคุณจะได้รับประโยชน์ของการสร้างชุดคำขออัตโนมัติและการพรีเฟชที่เพิ่มเข้ามา

1. ใน Amazon SQS Console ให้เลือก Amazon SQS standard queue (คิวมาตรฐาน Amazon SQS)
2. ใต้ Queue Actions (การดำเนินการคิว) ให้เลือก Subscribe Queue to SNS Topic (สมัครคิวหัวข้อ SNS) จากรายการดรอปดาวน์
3. ในกล่องโต้ตอบ ให้เลือกหัวข้อจากรายการดรอปดาวน์ Choose a Topic (เลือกหัวข้อ) แล้วคลิก Subscribe (สมัคร)

โปรดดูข้อมูลเพิ่มเติมที่การสมัครคิวหัวข้อ Amazon SNS ในคู่มือนักพัฒนา Amazon SQS

ใช่ คุณสามารถลบข้อความทั้งหมดในคิวข้อความ Amazon SQS ได้โดยใช้การดำเนินการ PurgeQueue

เมื่อคุณล้างคิวข้อความ ระบบจะลบข้อความทั้งหมดที่ก่อนหน้านี้ถูกส่งไปยังคิวข้อความที่ถูกลบนั้น เนื่องจากคิวข้อความและคุณลักษณะของคิวนั้นยังคงอยู่ จึงไม่ต้องกำหนดค่าคิวข้อความดังกล่าวอีกครั้ง คุณสามารถใช้ต่อไปได้เลย

หากต้องการลบเฉพาะข้อความที่ระบุเท่านั้น ให้ใช้การดำเนินการ DeleteMessage หรือ DeleteMessageBatch

โปรดดูข้อมูลเพิ่มเติมที่บทแนะนำสอนการใช้งาน: การล้างข้อความจากคิว Amazon SQS

คิว FIFO สามารถใช้ได้ในทุกรีเจี้ยน AWS ที่มี Amazon SQS โปรดดูรายละเอียดเกี่ยวกับความพร้อมให้บริการของรีเจี้ยน Amazon SQS ได้ที่นี่

คิว FIFO ไม่ได้รับการออกแบบมาให้ทำข้อความซ้ำ แต่ตัวผลิตข้อความของคุณอาจทำซ้ำได้ในบางสถานการณ์: ตัวอย่างเช่น หากตัวผลิตส่งข้อความ ไม่ได้รับการตอบกลับ จากนั้นจึงส่งข้อความเดิมอีกครั้ง Amazon SQS API มีฟังก์ชันขจัดการทำซ้ำที่ป้องกันไม่ให้ตัวผลิตข้อความส่งข้อความซ้ำ ทั้งนี้ระบบจะลบข้อความซ้ำที่ตัวผลิตข้อความได้ทำไว้ภายใน 5 นาทีของช่วงเวลาขจัดการทำซ้ำ

สำหรับคิวมาตรฐาน บางครั้งคุณอาจได้รับสำเนาของข้อความ (อย่างน้อยหนึ่งครั้งเมื่อจัดส่ง) หากคุณใช้คิวมาตรฐาน คุณต้องออกแบบแอปพลิเคชันให้มีผลลัพธ์เป็นค่าเดิมเสมอ (นั่นคือต้องไม่มีผลกระทบในทางตรงข้ามเมื่อประมวลผลข้อความเดิมมากกว่าหนึ่งครั้ง)

โปรดดูข้อมูลเพิ่มเติมที่การประมวลผลเพียงครั้งเดียวในคู่มือนักพัฒนา Amazon SQS

ไม่ได้ คิวมาตรฐานของ Amazon SQS (ชื่อใหม่สำหรับคิวที่มีอยู่) ยังคงไม่เปลี่ยนแปลงและคุณยังสามารถสร้างคิวมาตรฐานได้ คิวเหล่านี้ยังคงมีความสามารถในการปรับขนาดและปริมาณการประมวลผลสูงสุดต่อไปแต่คุณจะไม่ได้รับการรับรองเรื่องการจัดลำดับและอาจมีการทำซ้ำ

คิวมาตรฐานเหมาะสมกับหลายสถานการณ์ เช่น การกระจายงานเกี่ยวกับผู้ใช้บริการหลายรายที่มีผลลัพธ์เป็นค่าเดิมเสมอ

ไม่ได้ คุณต้องเลือกประเภทของคิวเมื่อสร้างคิวนั้นขึ้น แต่คิวดังกล่าวสามารถย้ายไปยังคิว FIFO ได้ โปรดดูข้อมูลเพิ่มเติมที่การย้ายจากคิวมาตรฐานไปยังคิว FIFO ในคู่มือนักพัฒนา Amazon SQS

หากต้องการใช้ประโยชน์จากฟังก์ชันคิว FIFO คุณต้องใช้ AWS SDK รุ่นล่าสุด

คิว FIFO ใช้การดำเนินการ API เดียวกันกับคิวมาตรฐาน รวมทั้งกลไกในการรับและการลบข้อความตลอดจนการเปลี่ยนแปลงการหมดเวลาแสดงผลแบบเดียวกัน แต่เมื่อส่งข้อความ คุณต้องระบุรหัสกลุ่มของข้อความ โปรดดูข้อมูลเพิ่มเติมที่ ตรรกะของคิว FIFO ในคู่มือ Amazon SQS Developer

คิว FIFO รองรับตัววัดทั้งหมดที่คิวมาตรฐานรองรับ สำหรับคิว FIFO แล้ว ตัววัดโดยประมาณทั้งหมดล้วนส่งกลับจำนวนที่แม่นยำ ตัวอย่างเช่น มีการรองรับตัววัด AWS CloudWatch ต่อไปนี้:

• ApproximateNumberOfMessagesDelayed - จำนวนของข้อความที่อยู่ในคิวซึ่งล่าช้าและไม่สามารถอ่านได้ทันที
• ApproximateNumberOfMessagesVisible - จำนวนของข้อความที่สามารถเรียกดูได้จากคิว
• ApproximateNumberOfMessagesNotVisible - จำนวนของข้อความที่อยู่ระหว่างถ่ายโอน (ส่งไปยังไคลเอ็นต์แต่ยังไม่ได้ลบออกหรือยังไปไม่ถึงปลายหน้าต่างการแสดงผล)

ข้อความที่ถูกแบ่งกลุ่มเป็น "ชุด" ที่จัดลำดับแตกต่างกันไปในคิว FIFO โดยข้อความทั้งหมดจะถูกส่งและรับในลำดับที่เข้มงวดตามรหัสกลุ่มของข้อความแต่ละรหัส แต่ข้อความที่มีค่ารหัสกลุ่มของข้อความแตกต่างกันอาจถูกส่งและรับอย่างไม่เป็นลำดับ ทั้งนี้คุณต้องโยงรหัสกลุ่มของข้อความกับข้อความ หากไม่ระบุรหัสกลุ่มของข้อความ ระบบจะดำเนินการไม่สำเร็จ

หากหลายโฮสต์ (หรือมีหลายเธรดในโฮสต์เดียวกัน) ส่งข้อความที่มีรหัสกลุ่มของข้อความเดียวกันไปยังคิว FIFO ทาง Amazon SQS จะส่งข้อความตามลำดับที่ข้อความเหล่านั้นมาถึงเพื่อประมวลผล หากต้องการมั่นใจว่า Amazon SQS รักษาลำดับตามข้อความที่ถูกส่งและรับ ให้ตรวจสอบว่าผู้ส่งหลายรายได้ส่งแต่ละข้อความโดยมีรหัสกลุ่มของข้อความไม่ซ้ำกัน

โปรดดูข้อมูลเพิ่มเติมที่ ตรรกะของคิว FIFO ในคู่มือนักพัฒนา Amazon SQS

ใช่ ตัวผลิตอย่างน้อยหนึ่งตัวสามารถส่งข้อความไปยังคิว FIFO ได้ ระบบจะจัดเก็บข้อความตามลำดับที่ Amazon SQS รับเรียบร้อยแล้ว

หากตัวผลิตหลายตัวส่งข้อความพร้อมกันโดยไม่รอการดำเนินการ SendMessage หรือ SendMessageBatch ตอบกลับว่าสำเร็จ ระบบอาจไม่รักษาลำดับระหว่างตัวผลิต การตอบกลับของการดำเนินการ SendMessage หรือ SendMessageBatch จะมีลำดับการจัดขั้นสุดท้ายที่คิว FIFO ใช้ในการใส่ข้อความลงในคิว ดังนั้นรหัสตัวผลิตพร้อมกันหลายตัวจึงสามารถระบุการจัดลำดับขั้นสุดท้ายของข้อความในคิวได้

ด้วยการออกแบบ คิว FIFO ของ Amazon SQS ไม่ให้บริการข้อความจากกลุ่มข้อความเดียวกันเพื่อส่งไปยังผู้ใช้บริการมากกว่าหนึ่งรายในแต่ละครั้ง แต่หากคิว FIFO ของคุณมีกลุ่มข้อความหลายกลุ่ม คุณสามารถใช้ประโยชน์จากผู้ใช้บริการพร้อมกัน โดยช่วยให้ Amazon SQS สามารถให้บริการข้อความจากกลุ่มข้อความที่แตกต่างกันแก่ผู้ใช้บริการแต่ละรายได้

ตามค่าเริ่มต้น คิว FIFO รองรับข้อความได้สูงสุด 3,000 ข้อความต่อวินาทีพร้อมการสร้างชุด หรือสูงสุด 300 ข้อความต่อวินาที (การดำเนินการส่ง รับ หรือลบ 300 ข้อความต่อวินาที) โดยไม่มีการสร้างชุด หากคุณต้องการอัตราการโอนถ่ายข้อมูลมากกว่านี้ คุณสามารถเปิดใช้โหมดอัตราการโอนถ่ายข้อมูลจำนวนมากสำหรับ FIFO บน Amazon SQS Console ซึ่งจะรองรับข้อความได้สูงสุด 70,000 ข้อความต่อวินาทีโดยไม่มีการสร้างชุด หรือมากกว่านั้นพร้อมการสร้างชุด สำหรับข้อมูลโดยละเอียดเกี่ยวกับโควต้าโหมดอัตราการโอนถ่ายข้อมูลจำนวนมากของ FIFO โปรดดูเอกสารประกอบของ AWS

ชื่อของคิว FIFO ต้องลงท้ายด้วยคำต่อท้าย .fifo คำต่อท้ายเป็นส่วนหนึ่งของขีดจำกัดชื่อคิวที่ยาว 80 ตัวอักขระ หากต้องการดูว่าเป็นคิว FIFO หรือไม่ คุณสามารถตรวจสอบได้ที่คำต่อท้ายชื่อของคิวนั้น

Amazon SQS จัดเก็บคิวข้อความและข้อความทั้งหมดไว้ภายในภูมิภาค AWS เดี่ยวพร้อมใช้งานสูงที่มี Availability Zone (AZ) มากมายจนเหลือเฟือกระทั่งเป็นไปไม่ได้เลยที่คอมพิวเตอร์ เครือข่าย หรือข้อบกพร่อง AZ จะทำให้เข้าถึงข้อความไม่ได้ โปรดดูข้อมูลเพิ่มเติมที่รีเจี้ยนและ Availability Zone ในคู่มือผู้ใช้ Amazon Relational Database Service

กลไกการตรวจสอบความถูกต้องช่วยให้มั่นใจได้ว่าข้อความที่จัดเก็บไว้ในคิวข้อความ Amazon SQS จะปลอดภัยจากการเข้าถึงโดยไม่ได้รับอนุญาต คุณสามารถควบคุมผู้ที่จะส่งข้อความไปยังคิวข้อความและผู้ที่จะรับข้อความจากคิวข้อความนั้นได้ หากต้องการเพิ่มความปลอดภัย คุณสามารถสร้างแอปพลิเคชันเพื่อเข้ารหัสข้อความก่อนที่จะใส่ข้อความดังกล่าวลงในคิวข้อความ

Amazon SQS มีระบบสิทธิ์ตามทรัพยากรของตนซึ่งใช้นโยบายที่เขียนขึ้นในภาษาเดียวกันกับนโยบาย AWS Identity and Access Management (IAM): ตัวอย่างเช่น คุณสามารถใช้ตัวแปรได้เหมือนกับในนโยบาย IAM โปรดดูข้อมูลเพิ่มเติมที่ตัวอย่างนโยบายของ Amazon SQS ในคู่มือนักพัฒนา Amazon SQS

Amazon SQS รองรับโปรโตคอล HTTP over SSL (HTTPS) และ Transport Layer Security (TLS) ไคลเอ็นต์ส่วนใหญ่สามารถโยกย้ายไปใช้ TLS เวอร์ชันที่ใหม่กว่าได้อย่างอัตโนมัติโดยไม่ต้องเปลี่ยนแปลงโค้ดหรือการกำหนดค่า Amazon SQS รองรับโปรโตคอล Transport Layer Security (TLS) เวอร์ชัน 1.0, 1.1 และ 1.2 ในภูมิภาคทั้งหมด

เมื่อ Amazon SQS ส่งกลับข้อความให้คุณ ข้อความดังกล่าวจะอยู่ในคิวข้อความไม่ว่าคุณจะได้รับข้อความนั้นจริงหรือไม่ก็ตาม คุณมีหน้าที่รับผิดชอบในการลบข้อความ และคำขอให้ลบรับทราบว่าคุณดำเนินการกับข้อความดังกล่าวแล้ว

หากคุณไม่ลบข้อความดังกล่าว Amazon SQS จะส่งข้อความอีกครั้งเมื่อได้รับคำขอรับอีกคำขอ โปรดดูข้อมูลเพิ่มเติมที่หมดเวลาแสดงผลในคู่มือนักพัฒนา Amazon SQS

ไม่ได้ คิว FIFO ไม่ทำข้อความซ้ำ

สำหรับคิวมาตรฐาน คุณอาจได้รับข้อความที่ก่อนหน้านี้ลบออกไปแล้วเป็นครั้งที่สอง แต่ก็เกิดขึ้นได้ยาก 

เมื่อคุณออกคำขอ DeleteMessage ด้วยข้อความที่ก่อนหน้านี้ลบออกไปแล้ว Amazon SQS จะส่งการตอบกลับว่าสำเร็จ

SSE ช่วยให้คุณส่งข้อมูลสำคัญในคิวที่เข้ารหัส SSE ปกป้องเนื้อหาของข้อความในคิว Amazon SQS โดยใช้คีย์ที่มีการจัดการใน AWS Key Management Service (AWS KMS) SSE เข้ารหัสข้อความทันทีที่ Amazon SQS ได้รับข้อความดังกล่าว ระบบจะจัดเก็บข้อความไว้ในรูปแบบที่เข้ารหัสและ Amazon SQS จะถอดรหัสข้อความเมื่อส่งให้ผู้ใช้บริการที่ได้รับอนุญาตเท่านั้น

โปรดดูข้อมูลเพิ่มเติมที่การปกป้องข้อมูลโดยใช้การเข้ารหัสฝั่งเซิร์ฟเวอร์ (SSE) และ AWS KMS ในคู่มือ Amazon SQS Developer

ใช่ หากต้องการทำเช่นนี้ คุณต้องเปิดการใช้งานร่วมกันระหว่างบริการของ AWS (เช่น Amazon CloudWatch Events, Amazon S3 และ Amazon SNS) และคิวที่มี SSE โปรดดูคำแนะนำโดยละเอียดที่ส่วนการใช้งานร่วมกันของคู่มือนักพัฒนา SQS  

การเข้ารหัสฝั่งเซิร์ฟเวอร์ (SSE) สำหรับ Amazon SQS มีให้บริการในทุกรีเจี้ยนของ AWS ที่มี Amazon SQS ให้บริการ โปรดดูรายละเอียดเกี่ยวกับความพร้อมให้บริการของรีเจี้ยน Amazon SQS ได้ที่นี่

หากต้องการเปิดใช้งาน SSE สำหรับคิวใหม่หรือคิวที่มีอยู่แล้วโดยใช้ Amazon SQS API ให้ระบุรหัสคีย์หลักของลูกค้า (CMK): นามแฝง, ARN นามแฝง, รหัสคีย์ หรือ ARN คีย์ของ CMK ที่มีการจัดการของ AWS หรือ CMK แบบกำหนดเองโดยการตั้งค่าคุณลักษณะ KmsMasterKeyId ของการดำเนินการ CreateQueue หรือ SetQueueAttributes

โปรดดูคำแนะนำโดยละเอียดที่การสร้างคิว Amazon SQS ที่มีการเข้ารหัสฝั่งเซิร์ฟเวอร์และการกำหนดค่าการเข้ารหัสฝั่งเซิร์ฟเวอร์ (SSE) สำหรับคิว Amazon SQS ที่มีอยู่ในคู่มือนักพัฒนา Amazon SQS

ทั้งคิวมาตรฐานและคิว FIFO ต่างก็รองรับ SSE

ก่อนที่จะใช้ SSE ได้ คุณต้องกำหนดค่านโยบายของคีย์ AWS KMS เพื่ออนุญาตการเข้ารหัสของคิว รวมทั้งการเข้ารหัสและการถอดรหัสของข้อความ

หากต้องการเปิดใช้งาน SSE สำหรับคิว คุณสามารถใช้คีย์หลักของลูกค้า (CMK) ที่มีการจัดการของ AWS สำหรับ Amazon SQS หรือ CMK แบบกำหนดเอง โปรดดูข้อมูลเพิ่มเติมที่คีย์หลักของลูกค้าในคู่มือนักพัฒนา AWS KMS

หากต้องการส่งข้อความไปยังคิวที่เข้ารหัส ตัวผลิตต้องมีสิทธิ์ kms:GenerateDataKey และ kms:Decrypt สำหรับ CMK

หากต้องการรับข้อความจากคิวที่เข้ารหัส ผู้ใช้บริการต้องมีสิทธิ์ kms:Decrypt สำหรับ CMK ที่ใช้เพื่อเข้ารหัสข้อความในคิวที่ระบุ หากคิวนั้นทำหน้าที่เป็นคิวที่ทำไม่สำเร็จ ผู้ใช้บริการยังต้องมีสิทธิ์ kms:Decrypt สำหรับ CMK ที่ใช้เพื่อเข้ารหัสข้อความในคิวต้นทางด้วยเช่นกัน

โปรดดูข้อมูลเพิ่มเติมที่ต้องมีสิทธิ์ใดจึงจะใช้ SSE ได้ในคู่มือนักพัฒนา Amazon SQS

ไม่มีค่าบริการเพิ่มเติมของ Amazon SQS แต่มีค่าบริการเพิ่มเติมสำหรับการเรียกใช้จาก Amazon SQS ไปยัง AWS KMS โปรดดูข้อมูลเพิ่มเติมที่ราคา AWS Key Management Service

ค่าบริการสำหรับการใช้ AWS KMS ขึ้นอยู่กับการกำหนดค่าระยะเวลาการนำคีย์ข้อมูลมาใช้ใหม่สำหรับคิวของคุณ โปรดดูข้อมูลเพิ่มเติมที่ฉันจะประเมินค่าใช้จ่ายการใช้งาน AWS KMS ของฉันได้อย่างไรในคู่มือนักพัฒนา Amazon SQS

SSE เข้ารหัสตัวข้อความในคิว Amazon SQS

SSE ไม่เข้ารหัสองค์ประกอบต่อไปนี้:

• เมตาดาต้าคิว (ชื่อคิวและคุณลักษณะ)
• เมตาดาต้าข้อความ (รหัสข้อความ การประทับเวลา และคุณลักษณะ)
• ตัววัดต่อคิว

Amazon SQS สร้างคีย์ข้อมูลตามคีย์หลักของลูกค้า (CMK) ที่มีการจัดการของ AWS สำหรับ Amazon SQS หรือ CMK แบบกำหนดเองเพื่อให้การเข้ารหัสแบบ Envelope และการถอดรหัสของข้อความสำหรับระยะเวลาที่กำหนด (ตั้งแต่ 1 นาทีจนถึง 24 ชั่วโมง)

โปรดดูข้อมูลเพิ่มเติมที่ SSE สำหรับ Amazon SQS เข้ารหัสอย่างไรในคู่มือนักพัฒนา Amazon SQS

SSE ใช้อัลกอริทึม AES-GCM 256

SSE ไม่จำกัดปริมาณการประมวลผล (TPS) ของ Amazon SQS จำนวนของคิว SSE ที่คุณสร้างจะถูกจำกัดด้วยรายการต่อไปนี้:

• ระยะเวลาการนำคีย์ข้อมูลกลับมาใช้ใหม่ (1 นาทีจนถึง 24 ชั่วโมง)
• โควตา AWS KMS ต่อบัญชี (100 TPS ตามค่าเริ่มต้น)
• จำนวนของผู้ใช้หรือบัญชี IAM ที่เข้าถึงคิว
• งานที่ยังทำไม่เสร็จจำนวนมาก (ยิ่งมีงานที่ยังทำไม่เสร็จจำนวนมาก ก็ยิ่งต้องเรียกใช้ AWS KMS จำนวนมาก)

ตัวอย่างเช่น ลองสมมติสถานการณ์ดังต่อไปนี้:

• คุณตั้งค่าระยะเวลาการนำคีย์ข้อมูลกลับมาใช้ใหม่ให้อยู่ที่ 5 นาที (300 วินาที)
• บัญชี KMS ของคุณมีโควตา AWS KMS TPS ตามค่าเริ่มต้นอยู่ที่ 100 TPS
• คุณใช้คิว Amazon SQS โดยไม่มีรายการงานค้าง และมีผู้ใช้ IAM 1 รายสำหรับการดำเนินการ SendMessage หรือ ReceiveMessage กับคิวทั้งหมด

ในกรณีนี้ คุณสามารถคำนวณจำนวนคิวสูงสุดทางทฤษฎีของ Amazon SQS กับ SSE ดังนี้:

300 วินาที × 100 TPS/ผู้ใช้ 1 IAM = 30,000 คิว

หากต้องการคาดการณ์ค่าใช้จ่ายและเข้าใจใบแจ้งค่าบริการ AWS ให้ดียิ่งขึ้น คุณอาจต้องทราบว่า Amazon SQS ใช้ CMK ของคุณบ่อยเพียงใด

หมายเหตุ: แม้ว่าสูตรต่อไปนี้จะให้แนวคิดเกี่ยวกับค่าใช้จ่ายที่คาดไว้ได้ดีมาก ค่าใช้จ่ายจริงก็อาจสูงกว่าได้เนื่องจากลักษณะการทำงานแบบกระจายของ Amazon SQS

หากต้องการคำนวณจำนวนคำขอ API ต่อคิว (R) ให้ใช้สูตรต่อไปนี้:

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

B คือช่วงเวลาที่เรียกเก็บเงิน (เป็นวินาที)

D คือระยะเวลาการนำคีย์ข้อมูลมาใช้ใหม่ (เป็นวินาที)

P คือจำนวนการผลิตหลักที่ส่งไปยังคิว Amazon SQS

C คือจำนวนการใช้หลักที่ได้รับจากคิว Amazon SQS

สิ่งสำคัญ: โดยทั่วไปการผลิตหลักจะก่อให้เกิดค่าใช้จ่ายเป็นสองเท่าของการใช้หลัก โปรดดูข้อมูลเพิ่มเติมที่ระยะเวลาการนำคีย์ข้อมูลมาใช้ใหม่ทำงานอย่างไรในคู่มือนักพัฒนา Amazon SQS

หากผู้ผลิตและผู้ใช้บริการมีผู้ใช้ IAM ที่แตกต่างกัน ค่าใช้จ่ายจะเพิ่มขึ้น

โปรดดูข้อมูลเพิ่มเติมที่ฉันจะประเมินค่าใช้จ่ายการใช้งาน AWS KMS ของฉันได้อย่างไรในคู่มือนักพัฒนา Amazon SQS

ใช่ Amazon SQS ได้รับการรับรอง PCI DSS Level 1 โปรดดูข้อมูลเพิ่มเติมที่การปฏิบัติตามกฎข้อบังคับ PCI

ใช่ AWS ได้ขยายโปรแกรมการปฏิบัติตามกฎข้อบังคับ HIPAA ให้รวม Amazon SQS เป็นบริการที่เข้าเกณฑ์ HIPAA หากคุณทำสัญญาข้อตกลงทางธุรกิจ (BAA) กับ AWS คุณสามารถใช้ Amazon SQS เพื่อสร้างแอปพลิเคชันที่สอดคล้องกับมาตรฐาน HIPAA จัดเก็บข้อความระหว่างจัดส่ง และส่งข้อความ ซึ่งรวมถึงข้อความที่มีข้อมูลสุขภาพที่ได้รับการคุ้มครอง (PHI)

หากคุณทำสัญญาข้อตกลงทางธุรกิจ BAA กับ AWS แล้ว คุณสามารถเริ่มใช้ Amazon SQS ได้ทันที หากคุณไม่มี BAA หรือมีคำถามเกี่ยวกับการใช้ AWS สำหรับแอปพลิเคชันที่สอดคล้องกับมาตรฐาน HIPAA โปรดติดต่อเราเพื่อสอบถามข้อมูลเพิ่มเติม

หมายเหตุ: หากคุณไม่ต้องการถ่ายโอน PHI ผ่าน Amazon SQS (หรือหากคุณมีข้อความขนาดใหญ่กว่า 256 KB) คุณสามารถเลือกส่งเพย์โหลดข้อความ Amazon SQS ผ่าน Amazon S3 โดยใช้ Amazon SQS Extended Client Library for Java (Amazon S3 คือบริการที่เข้าเกณฑ์ HIPAA ซึ่งไม่รวมการใช้งาน Amazon S3 Transfer Acceleration) โปรดดูข้อมูลเพิ่มเติมที่การใช้ Amazon SQS Extended Client Library for Java ในคู่มือนักพัฒนา Amazon SQS

การรักษาข้อความที่ยาวนานขึ้นให้ความยืดหยุ่นแก่ช่วงเวลาระหว่างการผลิตและการใช้ข้อความที่นานกว่าเดิมได้มากยิ่งขึ้น

คุณสามารถกำหนดค่าระยะเวลาการรักษาข้อความของ Amazon SQS ให้มีค่าตั้งแต่ 1 นาทีจนถึง 14 วัน ทั้งนี้มีค่าเริ่มต้นอยู่ที่ 4 วัน เมื่อถึงโควตาของการรักษาข้อความ ระบบจะลบข้อความโดยอัตโนมัติ

หากต้องการกำหนดค่าช่วงเวลาการรักษาข้อความ ให้ตั้งค่าคุณลักษณะ MessageRetentionPeriod โดยใช้ Console หรือใช้วิธีการ Distributiveness ใช้คุณลักษณะนี้เพื่อระบุจำนวนวินาทีที่จะรักษาข้อความไว้ใน Amazon SQS

คุณสามารถใช้คุณลักษณะ MessageRetentionPeriod เพื่อตั้งค่าช่วงเวลาการรักษาข้อความได้ตั้งแต่ 60 วินาที (1 นาที) จนถึง 1,209,600 วินาที (14 วัน) โปรดดูข้อมูลเพิ่มเติมเรื่องการทำงานกับคุณลักษณะข้อความนี้ที่ข้อมูลอ้างอิง Amazon SQS API

หากต้องการกำหนดค่าขนาดข้อความสูงสุด ให้ใช้ Console หรือวิธีการ SetQueueAttributes เพื่อตั้งค่าคุณลักษณะ MaximumMessageSize คุณลักษณะนี้ระบุขีดจำกัดของไบต์ที่ข้อความ Amazon SQS มีได้ ตั้งค่าขีดจำกัดนี้ให้มีค่าระหว่าง 1,024 ไบต์ (1 KB) และ 262,144 ไบต์ (256 KB) โปรดดูข้อมูลเพิ่มเติมที่การใช้คุณลักษณะข้อความ Amazon SQS ในคู่มือนักพัฒนา Amazon SQS

หากต้องการส่งข้อความขนาดใหญ่กว่า 256 KB ให้ใช้ Amazon SQS Extended Client Library for Java ไลบรารีนี้ให้คุณส่งข้อความ Amazon SQS ที่มีข้อมูลอ้างอิงไปยังเพย์โหลดข้อความใน Amazon S3 ซึ่งสามารถมีขนาดใหญ่ได้ 2 GB

ข้อความ Amazon SQS มีข้อมูลที่เป็นข้อความซึ่งรวมถึง XML, JSON และข้อความที่ไม่จัดรูปแบบได้สูงสุด 256 KB ระบบยอมรับตัวอักขระยูนิโค้ดต่อไปนี้:

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

โปรดดูข้อมูลเพิ่มเติมที่ข้อกำหนด XML 1.0

คิวข้อความ Amazon SQS เดียวสามารถจุข้อความได้ไม่จำกัดจำนวน แต่มีโควตาของจำนวนข้อความที่อยู่ระหว่างถ่ายโอนคือ 120,000 ข้อความสำหรับคิวมาตรฐานและ 20,000 ข้อความสำหรับคิว FIFO ข้อความจะอยู่ระหว่างถ่ายโอนเมื่อองค์ประกอบที่ใช้ได้รับข้อความดังกล่าวจากคิวแล้ว แต่ยังไม่ได้มีการลบข้อความออกจากคิวนั้น

คุณจะสร้างคิวข้อความกี่คิวก็ได้

ชื่อคิวมีขีดจำกัดอยู่ที่ 80 ตัวอักขระ

คุณสามารถใช้อักขระอักษรเลข, ยัติภังค์ (-) และสัญประกาศ (_) ได้

ชื่อของคิวข้อความต้องไม่ซ้ำกันภายในภูมิภาคและบัญชี AWS คุณสามารถนำชื่อของคิวข้อความมาใช้ใหม่ได้หลังจากที่ลบคิวข้อความนั้นแล้ว

คุณสามารถโยงคำสั่งนโยบายการเข้าถึง (และระบุสิทธิ์ที่ได้รับ) กับคิวข้อความที่จะแชร์ได้ Amazon SQS มี API สำหรับการสร้างและการจัดการคำสั่งนโยบายการเข้าถึง:

• AddPermission
• RemovePermission
• SetQueueAttributes
• GetQueueAttributes

โปรดดูข้อมูลเพิ่มเติมที่ข้อมูลอ้างอิง Amazon SQS API

เจ้าของคิวข้อความจ่ายเงินสำหรับการเข้าถึงคิวข้อความที่แชร์

Amazon SQS API ใช้หมายเลขบัญชี AWS เพื่อระบุผู้ใช้ AWS

หากต้องการแชร์คิวข้อความกับผู้ใช้ AWS ให้มอบ URL เต็มจากคิวข้อความที่คุณต้องการแชร์ การดำเนินการ CreateQueue และ ListQueues จะส่งกลับ URL นี้ในการตอบกลับ

ใช่ คุณสามารถกำหนดค่านโยบายการเข้าถึงซึ่งให้ผู้ใช้ที่ไม่ระบุชื่อสามารถเข้าถึงคิวข้อความได้

API สิทธิ์มีอินเทอร์เฟซสำหรับการแชร์การเข้าถึงคิวข้อความให้แก่ Developer แต่ API นี้ไม่สามารถให้การเข้าถึงแบบมีเงื่อนไขหรือกรณีการใช้งานในขั้นสูงขึ้นได้

การดำเนินการ SetQueueAttributes รองรับภาษาสำหรับนโยบายการเข้าถึงอย่างเต็มรูปแบบ ตัวอย่างเช่น คุณสามารถใช้ภาษาสำหรับนโยบายเพื่อจำกัดการเข้าถึงคิวข้อความตามที่อยู่ IP และช่วงเวลาในแต่ละวัน โปรดดูข้อมูลเพิ่มเติมที่ตัวอย่างนโยบายของ Amazon SQS ในคู่มือนักพัฒนา Amazon SQS

โปรดดูความพร้อมใช้งานของรีเจี้ยนที่ให้บริการที่ตารางรีเจี้ยนสำหรับโครงสร้างพื้นฐานส่วนกลางของ AWS

ไม่ได้ คิวข้อความ Amazon SQS แต่ละคิวในแต่ละภูมิภาคไม่มีความข้องเกี่ยวกัน

ราคา Amazon SQS เหมือนกันในทุกภูมิภาค ยกเว้นจีน (ปักกิ่ง) โปรดดูข้อมูลเพิ่มเติมที่ราคา Amazon SQS

คุณสามารถถ่ายโอนข้อมูลระหว่าง Amazon SQS และ Amazon EC2 หรือ AWS Lambda ภายในภูมิภาคเดียวได้โดยไม่มีค่าใช้จ่าย

เมื่อคุณถ่ายโอนข้อมูลระหว่าง Amazon SQS และ Amazon EC2 หรือ AWS Lambda ในภูมิภาคที่ต่างกัน คุณจะเสียค่าบริการตามอัตราการถ่ายโอนข้อมูลปกติ โปรดดูข้อมูลเพิ่มเติมที่ราคา Amazon SQS

คิวที่ทำไม่สำเร็จคือคิว Amazon SQS ซึ่งคิวต้นทางสามารถส่งข้อความได้ หากแอปพลิเคชันของผู้ใช้บริการของคิวต้นทางไม่สามารถใช้ข้อความได้สำเร็จ คิวที่ทำไม่สำเร็จช่วยให้คุณจัดการกับความล้มเหลวของการใช้ข้อความและจัดการวงจรอายุของข้อความที่ไม่ได้ใช้ได้ง่ายขึ้น คุณสามารถกำหนดค่าการแจ้งเตือนสำหรับข้อความที่ส่งไปยังคิวที่ทำไม่สำเร็จ ตรวจสอบบันทึกสำหรับข้อยกเว้นที่อาจทำให้มีการส่งข้อความไปยังคิว และวิเคราะห์เนื้อหาข้อความเพื่อวินิจฉัยปัญหาในแอปพลิเคชันของผู้ใช้บริการ เมื่อคุณกู้คืนแอปพลิเคชันของผู้ใช้บริการแล้ว คุณสามารถขับเคลื่อนข้อความจากคิวที่ทำไม่สำเร็จไปยังคิวต้นทางอีกครั้งได้

เมื่อคุณสร้างคิวต้นทาง Amazon SQS จะอนุญาตให้คุณระบุคิวที่ทำไม่สำเร็จ (DLQ) และเงื่อนไขที่ SQS ควรย้ายข้อความไปยัง DLQ เงื่อนไขคือจำนวนครั้งที่ผู้ใช้บริการสามารถรับข้อความจากคิว ซึ่งกำหนดเป็น maxReceiveCount การกำหนดค่านี้ของคิวที่ทำไม่สำเร็จที่มีคิวต้นทางและ maxReceiveCount เรียกว่านโยบายการขับเคลื่อนอีกครั้ง เมื่อ ReceiveCount สำหรับข้อความเกิน maxReceiveCount สำหรับคิว Amazon SQS ได้รับการออกแบบมาเพื่อย้ายข้อความไปยังคิวที่ทำไม่สำเร็จ (พร้อมรหัสข้อความดั้งเดิม) ตัวอย่างเช่น หากคิวต้นทางมีนโยบายการขับเคลื่อนอีกครั้งโดยตั้งค่า maxReceiveCount เป็นห้า และผู้ใช้บริการของคิวต้นทางได้รับข้อความหกครั้งโดยใช้ข้อความเหล่านั้นไม่สำเร็จ SQS จะย้ายข้อความไปยังคิวที่ทำไม่สำเร็จ

นโยบายการขับเคลื่อนอีกครั้งจะจัดการครึ่งแรกของวงจรอายุของข้อความที่ไม่ได้ใช้โดยการย้ายข้อความจากคิวต้นทางไปยังคิวที่ทำไม่สำเร็จ ในตอนนี้ การขับเคลื่อนคิวที่ทำไม่สำเร็จอีกครั้งไปยังคิวต้นทางจะทำให้วงจรสมบูรณ์ได้อย่างมีประสิทธิภาพ โดยการย้ายข้อความเหล่านั้นกลับไปยังคิวต้นทาง ดังที่แสดงไว้ด้านล่าง

อันดับแรก วิธีการนี้อนุญาตให้คุณตรวจสอบตัวอย่างข้อความที่มีอยู่ในคิวที่ทำไม่สำเร็จโดยแสดงคุณลักษณะของข้อความและข้อมูลเมตาที่เกี่ยวข้อง จากนั้น เมื่อคุณตรวจสอบข้อความแล้ว คุณสามารถย้ายข้อความเหล่านั้นกลับไปยังคิวต้นทางได้ คุณยังสามารถเลือกความเร็วของในการขับเคลื่อนอีกครั้งเพื่อกำหนดค่าอัตราที่ Amazon SQS จะย้ายข้อความจากคิวที่ทำไม่สำเร็จไปยังคิวต้นทางได้อีกด้วย

ใช่ แต่คุณต้องใช้คิวที่ทำไม่สำเร็จของ FIFO กับคิว FIFO (ในทำนองเดียวกัน คุณสามารถใช้คิวที่ทำไม่สำเร็จแบบมาตรฐานกับคิวมาตรฐานเท่านั้น)