Serverlös utveckling med AWS Lambda · Lektion

Dead Letter Queues (DLQ) för fel

Konfigurera Dead Letter Queues (DLQ) med SQS eller SNS för att fånga upp och hantera misslyckade asynkrona Lambda-anrop och förbättra systemets motståndskraft och felsökning

Lektion 2 av 411 steg

Dead Letter Queues (DLQ) för fel är en gratis lektion i Serverlös utveckling med AWS Lambda på CoddyKit. Detta är lektion 2 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Serverlös utveckling med AWS Lambda, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Serverlös utveckling med AWS Lambda innehåller totalt 4 lektioner.

Varför Dead Letter Queues?

När ni bygger serverlösa applikationer, särskilt med asynkrona Lambda-funktioner, vad händer om ett anrop misslyckas upprepade gånger?

Utan en lämplig mekanism kan dessa misslyckade händelser helt enkelt kastas bort, vilket leder till dataförlust eller ouppmärksammade problem. Det är här Dead Letter Queues (DLQ) kommer in i bilden.

Repetition av asynkrona Lambda-anrop

Låt oss först snabbt repetera hur asynkrona Lambda-anrop fungerar. När ni anropar en Lambda-funktion asynkront (till exempel via S3, SNS eller ett direkt API-anrop med InvocationType: Event):

Lambda placerar händelsen i en intern kö.
Därefter försöker Lambda anropa funktionen.
Om funktionen misslyckas försöker Lambda automatiskt anropa den igen upp till två gånger.

Obehandlade asynkrona fel

Vad händer om Lambda-funktionen fortfarande misslyckas efter alla automatiska återförsök (det ursprungliga försöket plus två återförsök)?

Som standard kastas händelsen helt enkelt bort om ingen DLQ har konfigurerats. Det innebär att ni förlorar värdefull information om vad som gick fel samt själva händelsedatan, vilket gör felsökning och felåterställning svårare.

Definition av Dead Letter Queue

En Dead Letter Queue (DLQ) är en destination för händelser som Lambda inte kunde behandla korrekt efter att alla återförsök har förbrukats.

Tänk på den som en ”parkeringsplats” för problematiska meddelanden. I stället för att försvinna skickas dessa misslyckade händelser till den DLQ-destination ni har valt, så att ni kan granska, felsöka och eventuellt behandla dem igen senare.

DLQ-destinationer: SQS eller SNS?

Ni kan konfigurera två typer av AWS-tjänster som DLQ-destinationer för era Lambda-funktioner:

Amazon SQS (Simple Queue Service): En meddelandekö. Misslyckade händelser skickas till SQS-kön, där de väntar på att behandlas. Detta är en pull-baserad modell.
Amazon SNS (Simple Notification Service): Ett ämne. Misslyckade händelser publiceras i ett SNS-ämne, som sedan kan avisera prenumeranter (till exempel via e-post eller andra Lambda-funktioner). Detta är en push-baserad modell.

SQS föredras vanligtvis för ombearbetning, medan SNS passar bra för omedelbara aviseringar.

Konfigurera en SQS-DLQ

För att använda en SQS-kö som DLQ behöver ni först skapa en. Det är en vanlig SQS-kö, men den namnges ofta så att syftet framgår (till exempel my-lambda-dlq).

Så här kan ni skapa en vanlig SQS-kö med AWS CLI:

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

Anslut Lambda till en DLQ

När SQS-kön är klar konfigurerar ni Lambda-funktionen så att den använder kön som DLQ. Detta innebär att funktionens konfiguration uppdateras.

Ni måste också säkerställa att Lambdas IAM-körningsroll har behörighet att skicka meddelanden till SQS-kön (sqs:SendMessage).

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

Demo: från Lambda-fel till DLQ

Betrakta den här Python Lambda-funktionen. Den bearbetar en händelse, men om händelsen innehåller "should_fail": true utlöser den ett undantag.

När funktionen anropas asynkront skickas en händelse som orsakar detta fel, efter att återförsöken har gjorts, till den konfigurerade DLQ:n.

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.")

Hantera misslyckade händelser

När händelserna finns i DLQ:n kan ni:

Övervaka: Använd Amazon CloudWatch för att följa antalet meddelanden i DLQ:n.
Inspektera: Visa meddelandenas innehåll för att förstå felet.
Bearbeta igen: Flytta tillbaka meddelanden till den ursprungliga kön eller starta manuell bearbetning när det underliggande problemet har åtgärdats.

Detta ger ett viktigt skyddsnät för era asynkrona arbetsflöden.

Snabbkontroll av DLQ

Ni har lärt er om Dead Letter Queues och varför de är viktiga. Nu testar vi era kunskaper!

Besvara frågan i den interaktiva lektionen

Sammanfattning: DLQ:er för motståndskraft

I den här lektionen utforskade vi Dead Letter Queues (DLQ:er) och deras roll när man bygger motståndskraftiga serverlösa applikationer. Ni har lärt er:

DLQ:er förhindrar dataförlust vid misslyckade asynkrona Lambda-anrop.
AWS SQS och SNS kan fungera som DLQ-destinationer.
Hur man konfigurerar en Lambda-funktion med en DLQ.
Vikten av att övervaka och hantera händelser i DLQ:n.

DLQ:er är avgörande för robust felhantering i händelsestyrda arkitekturer.

Gratis att börja

Lär dig Serverlös utveckling med AWS Lambda med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser: 12
Lektioner: 48

Börja lära dig gratis Visa hela kursen

Vanliga frågor

Är lektionen ”Dead Letter Queues (DLQ) för fel” gratis?

Ja – hela texten till ”Dead Letter Queues (DLQ) för fel” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Serverlös utveckling med AWS Lambda, kan Ni uppgradera till CoddyKit PRO. Kursen i Serverlös utveckling med AWS Lambda innehåller totalt 4 lektioner.

Vad lär jag mig i ”Dead Letter Queues (DLQ) för fel”?

Konfigurera Dead Letter Queues (DLQ) med SQS eller SNS för att fånga upp och hantera misslyckade asynkrona Lambda-anrop och förbättra systemets motståndskraft och felsökning Ni övar på Serverlös utveckling med AWS Lambda med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Serverlös utveckling med AWS Lambda?

Du behöver inga förkunskaper. Utbildningen i Serverlös utveckling med AWS Lambda på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Dead Letter Queues (DLQ) för fel”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Serverlös utveckling med AWS Lambda-lektionen?

Ja. Varje Serverlös utveckling med AWS Lambda-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

← Tillbaka till Serverlös utveckling med AWS Lambda