Serverless Backend with AWS Lambda & API Gateway · Lekcja

Kolejki dead-letter i obsługa awarii

Wiadomości mogą nie zostać przetworzone. Poznaj sposób, w jaki kolejki dead-letter przechwytują wadliwe wiadomości, oraz dowiedz się, jak projektować ponowienia i ponowne przetwarzanie w odpornych systemach sterowanych zdarzeniami.

Lekcja 4 z 413 kroki

Kolejki dead-letter i obsługa awarii to bezpłatna lekcja Serverless Backend with AWS Lambda & API Gateway na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Serverless Backend with AWS Lambda & API Gateway, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Serverless Backend with AWS Lambda & API Gateway zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

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
Bezpłatny start

Ucz się Serverless Backend with AWS Lambda & API Gateway dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy
12
Lekcje
48

Często zadawane pytania

Czy lekcja „Kolejki dead-letter i obsługa awarii” jest bezpłatna?

Tak — pełny tekst „Kolejki dead-letter i obsługa awarii” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Serverless Backend with AWS Lambda & API Gateway, przejdź na CoddyKit PRO. Kurs Serverless Backend with AWS Lambda & API Gateway zawiera 4 lekcji w sumie.

Co nauczysz się w „Kolejki dead-letter i obsługa awarii”?

Wiadomości mogą nie zostać przetworzone. Poznaj sposób, w jaki kolejki dead-letter przechwytują wadliwe wiadomości, oraz dowiedz się, jak projektować ponowienia i ponowne przetwarzanie w odpornych sy… Ćwiczysz Serverless Backend with AWS Lambda & API Gateway z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Serverless Backend with AWS Lambda & API Gateway?

Nie wymagamy żadnego doświadczenia. Serverless Backend with AWS Lambda & API Gateway w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Kolejki dead-letter i obsługa awarii”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Serverless Backend with AWS Lambda & API Gateway?

Tak. Każda lekcja Serverless Backend with AWS Lambda & API Gateway zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. SQS do rozdzielania usług
  2. SNS do komunikacji Pub/Sub
  3. Wyzwalacze Lambda dla SQS/SNS
  4. Kolejki dead-letter i obsługa awarii
← Powrót do Serverless Backend with AWS Lambda & API Gateway