0Pricing
Serverless Backend with AWS Lambda & API Gateway · บทเรียน

คิวจดหมายตายและการจัดการความล้มเหลว

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

คิวจดหมายตายและการจัดการความล้มเหลว เป็นบทเรียน Serverless Backend with AWS Lambda & API Gateway ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Serverless Backend with AWS Lambda & API Gateway และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Serverless Backend with AWS Lambda & API Gateway มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

The Problem of Failing Messages

In an event-driven system a message may fail repeatedly — bad data, a downstream outage, or a bug. Without a safety net, it can block the queue or be lost forever.

What is a Dead-Letter Queue?

A dead-letter queue (DLQ) is a separate queue that captures messages that could not be processed after a set number of attempts. This isolates poison messages without losing them.

Redrive Policy

An SQS queue routes to a DLQ via a redrive policy that names the DLQ and a maxReceiveCount. After that many failed receives, the message moves to the DLQ.

{
  "deadLetterTargetArn": "arn:aws:sqs:us-east-1:123:orders-dlq",
  "maxReceiveCount": 5
}

Configuring a DLQ for Lambda

Async Lambda invocations (S3, SNS) can send failures to a DLQ or to an on-failure destination via the event invoke config.

aws lambda put-function-event-invoke-config \
  --function-name processOrder \
  --destination-config '{"OnFailure":{"Destination":"arn:aws:sqs:...:orders-dlq"}}'

Setting maxReceiveCount Wisely

Too low and transient blips dead-letter good messages; too high and a poison message wastes many retries. A value of 3 to 5 is a common starting point.

Inspecting Dead-Lettered Messages

Messages in the DLQ keep the original body plus attributes showing why they failed. Read them to diagnose the root cause before reprocessing.

aws sqs receive-message \
  --queue-url https://sqs.../orders-dlq \
  --attribute-names All

Redriving Messages Back

Once the bug is fixed, SQS can redrive messages from the DLQ back to the source queue for reprocessing — no manual copying needed.

Idempotency Matters

Because retries and redrives can deliver the same message more than once, your handler must be idempotent: processing the same message twice should not double-charge or duplicate records.

Alerting on the DLQ

A growing DLQ is a signal something is broken. Set a CloudWatch alarm on the DLQ ApproximateNumberOfMessagesVisible metric to get notified.

Partial Batch Failures

When Lambda reads a batch from SQS, reporting batchItemFailures lets only the failed messages return to the queue, instead of reprocessing the whole batch.

{
  "batchItemFailures": [
    { "itemIdentifier": "msg-id-3" }
  ]
}

Designing for Resilience

A resilient pipeline combines:

  • Retries for transient errors
  • A DLQ for poison messages
  • Idempotent handlers
  • Alarms and a redrive plan

Quick Check

Test your failure-handling knowledge.

Recap

You learned to handle failing messages:

  • A DLQ isolates poison messages after maxReceiveCount
  • Configure redrive policies and Lambda on-failure destinations
  • Inspect, fix, then redrive messages back
  • Make handlers idempotent and alarm on DLQ depth
  • Use batchItemFailures for partial batch retries

คำถามที่พบบ่อย

บทเรียน “คิวจดหมายตายและการจัดการความล้มเหลว” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “คิวจดหมายตายและการจัดการความล้มเหลว” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Serverless Backend with AWS Lambda & API Gateway ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Serverless Backend with AWS Lambda & API Gateway มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “คิวจดหมายตายและการจัดการความล้มเหลว”

ข้อความอาจประมวลผลไม่สำเร็จ เรียนรู้ว่าคิวจดหมายตายเก็บข้อความที่เป็นปัญหาไว้อย่างไร และวิธีออกแบบการลองใหม่กับการประมวลผลซ้ำสำหรับระบบที่ขับเคลื่อนด้วยเหตุการณ์และทนทาน คุณปฏิบัติ Serverless Backend with AWS Lambda & API Gateway ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Serverless Backend with AWS Lambda & API Gateway หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Serverless Backend with AWS Lambda & API Gateway บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “คิวจดหมายตายและการจัดการความล้มเหลว” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Serverless Backend with AWS Lambda & API Gateway นี้ได้ไหม

ได้ บทเรียน Serverless Backend with AWS Lambda & API Gateway ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การใช้ SQS เพื่อแยกบริการออกจากกัน
  2. การรับส่งข้อความแบบเผยแพร่และสมัครรับข้อมูลด้วย SNS
  3. ทริกเกอร์ Lambda ด้วย SQS/SNS
  4. คิวจดหมายตายและการจัดการความล้มเหลว
← กลับไปที่ Serverless Backend with AWS Lambda & API Gateway