Fejlhåndtering og retries
Implementér robust fejlhåndtering, dead-letter-køer og mekanismer til gentagne forsøg i modstandsdygtige serverless-applikationer.
Fejlhåndtering og retries er en gratis Serverløs backend med AWS Lambda og API Gateway-lektion på CoddyKit. Dette er lektion 3 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 backend med AWS Lambda og API Gateway, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Serverløs backend med AWS Lambda og API Gateway-kurset indeholder 4 lektioner i alt.
Byg robuste serverløse applikationer
I serverløse arkitekturer kan ting gå galt. Netværksproblemer, tjenesteudfald eller fejl i din kode kan alle føre til fejl.
At bygge robuste applikationer betyder, at de kan komme sig på en kontrolleret måde efter disse problemer, så påvirkningen af brugerne minimeres, og datatab forhindres. Fejlhåndtering og gentagne forsøg er afgørende for dette.
Typer af Lambda-kald
Hvordan Lambda håndterer fejl og gentagne forsøg, afhænger af, hvordan din funktion kaldes. Der er to hovedtyper:
- Synkront: Den kaldende part venter på et svar (f.eks. API Gateway, ALB).
- Asynkront: Den kaldende part venter ikke; Lambda placerer hændelsen i en kø (f.eks. S3, SNS, SQS, EventBridge).
Hver type har som standard sin egen adfærd for gentagne forsøg.
Gentagne forsøg ved synkrone Lambda-kald
Når en Lambda-funktion kaldes synkront og returnerer en fejl (eller løber ind i en timeout), prøver Lambda IKKE automatisk funktionen igen.
Det er op til den tjeneste eller klient, der kaldte Lambda (f.eks. API Gateway eller din mobilapp), at implementere sin egen logik for gentagne forsøg. Lambda sender blot fejlen tilbage til den kaldende part.
Gentagne forsøg ved asynkrone Lambda-kald
Ved asynkrone kald har Lambda indbyggede mekanismer til gentagne forsøg. Hvis din funktion mislykkes på grund af en uhåndteret fejl eller løber ind i en timeout, prøver Lambda automatisk kaldet igen to gange.
Det betyder, at der foretages i alt tre forsøg (det oprindelige forsøg plus to nye forsøg) med eksponentiel ventetid mellem forsøgene. Det hjælper med at overvinde midlertidige problemer.
Håndtering af fejl i kode
Ud over Lambdas automatiske gentagne forsøg bør du altid implementere fejlhåndtering *i* din funktionskode. Det giver dig mulighed for at:
- Håndtere forventede fejl på en kontrolleret måde (f.eks. manglende input).
- Logge specifikke oplysninger til fejlfinding.
- Returnere tilpassede fejlmeddelelser til kaldende parter.
I Python er blokken try-except din bedste ven til dette.
Eksempel på fejlhåndtering i Python
Denne Python Lambda-funktion bruger try-except til at håndtere en mulig KeyError, hvis en forventet nøgle mangler, eller en ZeroDivisionError, hvis en værdi er nul. Prøv at køre den med forskellige inputværdier!
import json
def lambda_handler(event, context):
try:
# Expecting 'value' key in the event
num = event['value']
result = 100 / num
return {
'statusCode': 200,
'body': json.dumps(f'Result: {result}')
}
except KeyError:
print("Error: 'value' key missing in event.")
return {
'statusCode': 400,
'body': json.dumps('Input Error: Missing \'value\' in event.')
}
except ZeroDivisionError:
print("Error: Cannot divide by zero.")
return {
'statusCode': 400,
'body': json.dumps('Input Error: Cannot divide by zero.')
}
except Exception as e:
print(f"An unexpected error occurred: {e}")
return {
'statusCode': 500,
'body': json.dumps(f'Server Error: {str(e)}')
}
# Example of how to run locally for testing
if __name__ == "__main__":
# Test case 1: Missing key
print("\n--- Test Case 1 (Missing Key) ---")
print(lambda_handler({}, None))
# Test case 2: Zero division
print("\n--- Test Case 2 (Zero Division) ---")
print(lambda_handler({'value': 0}, None))
# Test case 3: Success
print("\n--- Test Case 3 (Success) ---")
print(lambda_handler({'value': 25}, None))
# Test case 4: Non-numeric value (unhandled, falls to generic exception)
print("\n--- Test Case 4 (Type Error) ---")
print(lambda_handler({'value': 'abc'}, None))Køer med ikke-leverede meddelelser (DLQ'er)
Hvad sker der, hvis et asynkront Lambda-kald mislykkes, selv efter alle gentagne forsøg? Det er her, køer med ikke-leverede meddelelser (DLQ'er) kommer ind i billedet!
En DLQ er en Amazon SQS-kø eller et SNS-emne, hvortil Lambda sender hændelser, som den ikke kunne behandle korrekt efter alle forsøgene. Det er en vigtig mekanisme til:
- At forhindre datatab.
- At fejlsøge vedvarende problemer.
- Manuel behandling af mislykkede hændelser igen.
Konfiguration af en DLQ
Sådan konfigurerer du en DLQ til din Lambda-funktion:
- Opret en SQS-kø eller et SNS-emne: Dette bliver din DLQ.
- Tildel tilladelser: Sørg for, at din Lambda-funktion har tilladelse til at publicere meddelelser til den valgte SQS-kø eller det valgte SNS-emne.
- Konfigurer Lambda: Angiv ARN'en for din SQS-kø eller dit SNS-emne som DLQ i konfigurationen af din Lambda-funktion (under 'Asynchronous invocation').
Det sikrer, at mislykkede hændelser har et sikkert sted at lande.
DLQ-adfærd i praksis
Det er vigtigt at forstå, *hvornår* en hændelse sendes til en DLQ:
- Kun ved asynkrone kald.
- Efter alle automatiske forsøg (det oprindelige forsøg plus to nye forsøg) er mislykkedes.
- Hvis hændelsens maksimale alder overskrides, eller det maksimale antal forsøg er opbrugt.
Den oprindelige hændelses nyttedata sendes sammen med nogle metadata til DLQ'en.
Forstå DLQ'er
Lad os teste din forståelse af køer med ikke-leverede meddelelser!
Opsummering: Fejlhåndtering og gentagne forsøg
Du har lært, hvordan du gør dine serverløse applikationer mere robuste!
- Synkront og asynkront: Forskellige typer af kald har forskellig standardadfærd for gentagne forsøg.
- Fejlhåndtering i kode: Brug
try-excepttil at opfange og håndtere fejl i din Lambda-kode. - Køer med ikke-leverede meddelelser (DLQ'er): En vigtig mekanisme til at opfange og undersøge hændelser, der mislykkes efter alle automatiske forsøg, så datatab ved asynkrone kald forhindres.
Disse metoder er afgørende for at bygge pålidelige serverløse systemer!
Lær Serverløs backend med AWS Lambda og API Gateway 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
Ofte stillede spørgsmål
Er lektionen “Fejlhåndtering og retries” gratis?
Ja — hele teksten til “Fejlhåndtering og retries” 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 backend med AWS Lambda og API Gateway-kurset, skal du opgradere til CoddyKit PRO. Serverløs backend med AWS Lambda og API Gateway-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Fejlhåndtering og retries”?
Implementér robust fejlhåndtering, dead-letter-køer og mekanismer til gentagne forsøg i modstandsdygtige serverless-applikationer. Du øver dig i Serverløs backend med AWS Lambda og API Gateway 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 backend med AWS Lambda og API Gateway?
Der kræves ingen tidligere erfaring. Serverløs backend med AWS Lambda og API Gateway 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 3 af 4.
Hvor lang tid tager lektionen “Fejlhåndtering og retries”?
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 backend med AWS Lambda og API Gateway-lektion?
Ja. Alle Serverløs backend med AWS Lambda og API Gateway-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
- Cold starts og warm-up-strategier
- Teknikker til omkostningsoptimering
- Fejlhåndtering og retries
- Observability med struktureret logging og tracing