Feilhåndtering og nye forsøk
Implementer robuste mekanismer for feilhåndtering, konfigurer automatiske nye forsøk og forstå feil ved oppkalling for å bygge mer motstandsdyktige serverless-systemer
Feilhåndtering og nye forsøk er en gratis leksjon i Serverløs utvikling med AWS Lambda på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Serverløs utvikling med AWS Lambda, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Serverløs utvikling med AWS Lambda inneholder totalt 4 leksjoner.
Hvorfor feilhåndtering er viktig
I serverløse applikasjoner kan ting gå galt. Funksjonen din kan mislykkes, en avhengighet kan være utilgjengelig, eller en hendelse kan ha feil format.
Robust feilhåndtering er avgjørende for å bygge motstandsdyktige systemer som kan gjenopprette seg på en kontrollert måte og varsle deg når problemer oppstår. I denne leksjonen ser vi på hvordan AWS Lambda hjelper deg med dette.
Typer Lambda-feil
Når du arbeider med Lambda, er det nyttig å forstå ulike typer feil:
- Påkallingsfeil: Problemer som oppstår før koden din kjører, for eksempel feil IAM-tillatelser som gjør at Lambda ikke kan lese fra en hendelseskilde.
- Funksjonsfeil: Unntak som utløses av funksjonskoden din, tidsavbrudd eller feil på grunn av for lite minne. Dette er feilene du først og fremst håndterer i koden din.
- Tjenestefeil: Sjeldne problemer i selve den underliggende AWS Lambda-tjenesten.
Synkrone kontra asynkrone feilforløp
Hvordan Lambda håndterer feil, avhenger av typen påkalling:
- Synkron: (for eksempel via API Gateway eller ALB) Lambda returnerer feilen direkte til den som foretar påkallingen. Denne er ansvarlig for nye forsøk.
- Asynkron: (for eksempel via S3, SNS eller SQS) Lambda legger hendelsen i en intern kø og prøver automatisk funksjonen på nytt hvis den mislykkes. Du får ingen umiddelbar tilbakemelding.
I denne leksjonen fokuserer vi hovedsakelig på asynkron feilhåndtering og nye forsøk.
Lambdas asynkrone nye forsøk
Ved asynkrone påkallinger prøver Lambda automatisk funksjonen din på nytt hvis den mislykkes på grunn av et uhåndtert unntak eller får tidsavbrudd.
- Som standard prøver Lambda to ganger på nytt, altså totalt 3 forsøk.
- Disse nye forsøkene skjer automatisk etter en forsinkelse, ofte med eksponentiell tilbakekobling.
- Denne innebygde mekanismen bidrar til å sikre at midlertidige problemer ikke fører til tapte hendelser.
Konfigurere asynkrone nye forsøk
Du kan tilpasse innstillingene for asynkrone påkallinger av Lambda-funksjonen din:
- Maksimalt antall nye forsøk: Angi en verdi fra 0 til 2. Hvis du angir 0, gjøres ingen nye forsøk.
- Maksimal hendelsesalder: Angi hvor lenge Lambda skal beholde en hendelse i køen for nye forsøk, fra 60 sekunder til 6 timer.
Disse innstillingene gir deg kontroll over hvor lenge og hvor ofte Lambda prøver å behandle en hendelse som har mislyktes.
Fange opp mislykkede hendelser med DLQ-er
Selv med nye forsøk kan enkelte hendelser fortsette å mislykkes, for eksempel på grunn av data med feil format. Disse kalles ofte «poison pill»-meldinger.
En Dead Letter Queue (DLQ) er et angitt mål (en SQS-kø eller et SNS-emne) som Lambda sender hendelser til når alle nye forsøk er brukt opp.
DLQ-er er viktige for feilsøking, for å forhindre datatap og for å analysere hvorfor enkelte hendelser ikke kunne behandles.
Konfigurere DLQ-en
Slik bruker du en DLQ:
- Opprett en Amazon SQS-kø eller et SNS-emne.
- Konfigurer innstillingene for asynkrone påkallinger av Lambda-funksjonen slik at denne SQS-køen eller dette SNS-emnet angis som DLQ.
- Kontroller at kjørerollen til Lambda-funksjonen har tillatelse til å sende meldinger til den valgte DLQ-en (for eksempel
sqs:SendMessageellersns:Publish).
Dette sikrer at ingen hendelser faktisk går «tapt», selv etter flere mislykkede forsøk.
Håndtere feil i koden din
Selv om Lambda håndterer nye forsøk, bør du fortsatt implementere feilhåndtering i funksjonskoden din ved hjelp av try-catch-blokker. Dette lar deg:
- Håndtere forventede feil på en kontrollert måte.
- Logge detaljert kontekst for feilsøking.
- Utføre opprydding eller delvise tilbakeføringer før du utløser et unntak på nytt for å starte Lambdas mekanisme for nye forsøk.
Prøv å kjøre dette enkle Java-eksempelet:
public class Main {
public static void main(String[] args) {
processData("valid data");
System.out.println("------------------");
processData("data with error");
}
public static void processData(String data) {
try {
System.out.println("Attempting to process: " + data);
if (data.contains("error")) {
throw new RuntimeException("Critical processing error!");
}
System.out.println("Successfully processed: " + data.toUpperCase());
} catch (Exception e) {
System.err.println("Caught an error: " + e.getMessage());
System.err.println("Further action (e.g., logging, retry logic) would go here.");
// In a real Lambda, re-throwing would trigger a retry for async invocations
}
}
}Forstå påkallingsfeil
Noen ganger klarer ikke Lambda engang å starte funksjonen din. Dette er påkallingsfeil.
- Eksempler: Feil IAM-tillatelser som hindrer Lambda i å få tilgang til en S3-bøtte som utløser funksjonen, en feilkonfigurert VPC eller overskridelse av tjenestekvoter før kjøringen starter.
- Oppdagelse: Disse feilene vises ofte i CloudWatch Logs for funksjonen din eller som `Invocation errors`-målinger i Lambda-konsollen. De håndteres vanligvis ikke av
try-catch-blokkene i funksjonen din.
Rask sjekk av nye forsøk
La oss teste forståelsen din av feilhåndtering og nye forsøk i AWS Lambda.
Oppsummering: Bygge motstandsdyktige Lambda-funksjoner
Du har lært hvordan du gjør serverløse applikasjoner mer robuste:
- Du har skilt mellom ulike typer Lambda-feil.
- Du har forstått hvordan synkrone og asynkrone påkallinger håndterer feil på forskjellige måter.
- Du har utforsket Lambdas automatiske mekanisme for nye forsøk ved asynkrone kall.
- Du har oppdaget hvor viktige Dead Letter Queue-er (DLQ-er) er for mislykkede hendelser.
- Du har sett hvordan du implementerer grunnleggende feilhåndtering i koden din ved hjelp av
try-catch.
Ved å bruke disse teknikkene kan du bygge mer motstandsdyktige og pålitelige serverløse systemer.
Lær deg Serverløs utvikling med AWS Lambda med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 12
- Leksjoner
- 48
Ofte stilte spørsmål
Er leksjonen «Feilhåndtering og nye forsøk» gratis?
Ja – hele teksten i «Feilhåndtering og nye forsøk» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Serverløs utvikling med AWS Lambda-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Serverløs utvikling med AWS Lambda inneholder totalt 4 leksjoner.
Hva lærer jeg i «Feilhåndtering og nye forsøk»?
Implementer robuste mekanismer for feilhåndtering, konfigurer automatiske nye forsøk og forstå feil ved oppkalling for å bygge mer motstandsdyktige serverless-systemer Du øver på Serverløs utvikling med AWS Lambda med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med Serverløs utvikling med AWS Lambda?
Ingen tidligere erfaring er nødvendig. Serverløs utvikling med AWS Lambda på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.
Hvor lang tid tar leksjonen «Feilhåndtering og nye forsøk»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne Serverløs utvikling med AWS Lambda-leksjonen?
Ja. Alle Serverløs utvikling med AWS Lambda-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- CloudWatch-logger og -måltall
- Feilhåndtering og nye forsøk
- Feilsøking av serverless-applikasjoner
- Egendefinerte måltall og CloudWatch-alarmer