Serverløs udvikling med AWS Lambda · Lektion

Dead Letter Queues (DLQ) til fejl

Konfigurer Dead Letter Queues (DLQ) med SQS eller SNS for at opsamle og håndtere mislykkede asynkrone Lambda-kald og dermed forbedre systemets robusthed og fejlfinding.

Lektion 2 af 411 trin

Dead Letter Queues (DLQ) til fejl er en gratis Serverløs udvikling med AWS Lambda-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i Serverløs udvikling med AWS Lambda, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Serverløs udvikling med AWS Lambda-kurset indeholder 4 lektioner i alt.

Hvorfor Dead Letter Queues?

Når du bygger serverløse applikationer, især med asynkrone Lambda-funktioner, hvad sker der så, hvis en påkaldelse mislykkes gentagne gange?

Uden en passende mekanisme kan disse mislykkede hændelser ganske enkelt blive kasseret, hvilket kan føre til datatab eller problemer, der ikke bliver håndteret. Det er her, Dead Letter Queues (DLQ'er) kommer ind i billedet.

Gennemgang af asynkron Lambda-påkaldelse

Lad os først hurtigt opsummere, hvordan asynkrone Lambda-påkaldelser fungerer. Når du påkalder en Lambda-funktion asynkront (f.eks. via S3, SNS eller et direkte API-kald med InvocationType: Event):

Lambda placerer hændelsen i en intern kø.
Derefter forsøger den at påkalde din funktion.
Hvis funktionen mislykkes, prøver Lambda automatisk påkaldelsen igen op til to gange.

Ubehandlede asynkrone fejl

Hvad sker der, hvis din Lambda-funktion stadig mislykkes efter alle automatiske gentagelsesforsøg (det første forsøg plus to gentagelser)?

Som standard kasseres hændelsen ganske enkelt, hvis der ikke er konfigureret en DLQ. Det betyder, at du mister værdifulde oplysninger om, hvad der gik galt, samt selve hændelsesdataene, hvilket gør fejlfinding og fejlhåndtering vanskelig.

Definition af Dead Letter Queue

En Dead Letter Queue (DLQ) er en destination for hændelser, som Lambda ikke kunne behandle korrekt efter at have opbrugt alle gentagelsesforsøg.

Tænk på den som en "parkeringsplads" for problematiske meddelelser. I stedet for at forsvinde sendes disse mislykkede hændelser til den valgte DLQ-destination, så du senere kan undersøge, fejlfinde og eventuelt behandle dem igen.

DLQ-destinationer: SQS eller SNS?

Du kan konfigurere to typer AWS-tjenester som DLQ-destinationer for dine Lambda-funktioner:

Amazon SQS (Simple Queue Service): En meddelelseskø. Mislykkede hændelser sendes til SQS-køen, hvor de venter på behandling. Dette er en pull-baseret model.
Amazon SNS (Simple Notification Service): Et emne. Mislykkede hændelser publiceres til et SNS-emne, som derefter kan give abonnenter besked (f.eks. via e-mail eller andre Lambda-funktioner). Dette er en push-baseret model.

SQS foretrækkes generelt til genbehandling, mens SNS er velegnet til øjeblikkelige notifikationer.

Konfiguration af en SQS-DLQ

Hvis du vil bruge en SQS-kø som DLQ, skal du først oprette en. Det er en standard-SQS-kø, men den navngives ofte, så formålet fremgår (f.eks. my-lambda-dlq).

Sådan kan du oprette en standard-SQS-kø ved hjælp af AWS CLI:

aws sqs create-queue \
  --queue-name my-lambda-dlq

Forbind Lambda med en DLQ

Når din SQS-kø er klar, konfigurerer du din Lambda-funktion til at bruge den som DLQ. Det indebærer, at funktionens konfiguration opdateres.

Du skal også sikre, at din Lambdas IAM-udførelsesrolle har tilladelse til at sende meddelelser til SQS-køen (sqs:SendMessage).

aws lambda update-function-configuration \
  --function-name MyFailingLambda \
  --dead-letter-config TargetArn=arn:aws:sqs:REGION:ACCOUNT_ID:my-lambda-dlq

Demo: Fra Lambda-fejl til DLQ

Se på denne Python Lambda-funktion. Den behandler en hændelse, men hvis hændelsen indeholder "should_fail": true, udløser den en undtagelse.

Når funktionen kaldes asynkront, vil en hændelse, der udløser denne fejl, efter gentagne forsøg blive sendt til den konfigurerede DLQ.

def lambda_handler(event, context):
    print(f"Processing event: {event}")
    # Simulate an error condition
    if event.get("should_fail", False):
        raise Exception("Simulated processing error!")
    return {
        'statusCode': 200,
        'body': 'Processed successfully!'
    }

# This part makes it runnable outside Lambda for demonstration
if __name__ == "__main__":
    print("--- Simulating a successful invocation ---")
    result_success = lambda_handler({"key": "value"}, None)
    print(f"Success Result: {result_success}\n")

    print("--- Simulating a failed invocation ---")
    try:
        result_fail = lambda_handler({"should_fail": True}, None)
        print(f"Failure Result: {result_fail}")
    except Exception as e:
        print(f"Caught expected error: {e}")
        print("This event would eventually go to a DLQ after retries.")

Håndtering af fejlslagne hændelser

Når hændelserne først er i din DLQ, kan du:

Overvåge: Brug Amazon CloudWatch til at følge antallet af meddelelser i DLQ'en.
Undersøge: Se meddelelsernes indhold for at forstå fejlen.
Behandle igen: Flyt meddelelserne tilbage til den oprindelige kø, eller udløs manuel behandling, når det underliggende problem er løst.

Det giver et vigtigt sikkerhedsnet til dine asynkrone arbejdsgange.

Hurtigtjek af DLQ

Du har lært om dead-letter-køer og deres betydning. Lad os teste din forståelse!

Besvar den i den interaktive lektion

Opsummering: DLQ'er giver robusthed

I denne lektion undersøgte vi dead-letter-køer (DLQ'er) og deres rolle i opbygningen af robuste serverløse applikationer. Du lærte:

DLQ'er forhindrer datatab ved fejlslagne asynkrone Lambda-kald.
AWS SQS og SNS kan fungere som destinationer for DLQ'er.
Hvordan du konfigurerer en Lambda-funktion med en DLQ.
Hvor vigtigt det er at overvåge og administrere hændelser i din DLQ.

DLQ'er er afgørende for robust fejlhåndtering i hændelsesdrevne arkitekturer.

Gratis at komme i gang

Lær Serverløs udvikling med AWS Lambda med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 12
Lektioner: 48

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Dead Letter Queues (DLQ) til fejl” gratis?

Ja — hele teksten til “Dead Letter Queues (DLQ) til fejl” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af Serverløs udvikling med AWS Lambda-kurset, skal du opgradere til CoddyKit PRO. Serverløs udvikling med AWS Lambda-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Dead Letter Queues (DLQ) til fejl”?

Konfigurer Dead Letter Queues (DLQ) med SQS eller SNS for at opsamle og håndtere mislykkede asynkrone Lambda-kald og dermed forbedre systemets robusthed og fejlfinding. Du øver dig i Serverløs udvikling med AWS Lambda med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Serverløs udvikling med AWS Lambda?

Der kræves ingen tidligere erfaring. Serverløs udvikling med AWS Lambda på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Dead Letter Queues (DLQ) til fejl”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Serverløs udvikling med AWS Lambda-lektion?

Ja. Alle Serverløs udvikling med AWS Lambda-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

← Tilbage til Serverløs udvikling med AWS Lambda