Visibility timeout, DLQ og long polling

Når en forbruger modtager en meddelelse fra SQS, skjules meddelelsen for alle andre forbrugere i en periode, der kaldes synlighedstimeout. I dette tidsrum behandler forbrugeren meddelelsen og sletter den derefter. Hvis forbrugeren går ned eller ikke bliver færdig i tide, udløber synlighedstimeoutet, og meddelelsen bliver synlig igen, så en anden forbruger kan hente den. Dette er den centrale mekanisme bag SQS's garanti om levering mindst én gang.

Standardværdien for synlighedstimeout er 30 sekunder. Den kan indstilles fra 0 sekunder til 12 timer. Indstil den, så den med god margin overstiger den maksimale forventede behandlingstid—hvis behandlingen tager op til 2 minutter, skal timeoutet indstilles til mindst 3-4 minutter. Du kan også ændre timeoutet pr. kvittering ved hjælp af change-message-visibility, hvilket er nyttigt, når en forbruger registrerer, at den har brug for mere tid til at færdigbehandle en bestemt meddelelse.

Hvis timeoutet indstilles for kort, bliver meddelelser synlige igen, før forbrugeren er færdig, hvilket fører til dubletbehandling. Hvis det indstilles for langt, forsinkes en anden forbrugers hentning af en meddelelse, hvis den oprindelige forbruger fejler uden at det opdages (f.eks. ved et EC2-instansnedbrud uden kontrolleret oprydning). Det optimale timeout er lidt længere end din behandlingstid ved 99-percentilen, men kort nok til hurtigt at kunne komme sig efter fejl hos forbrugere. Overvåg CloudWatch-metrikken ApproximateNumberOfMessagesNotVisible for at opdage problemer med timeout.

En kø til fejlslagne meddelelser (DLQ) er en separat SQS-kø, hvortil meddelelser sendes, efter at de er mislykkedes under behandlingen et konfigurerbart antal gange (maxReceiveCount). Når en meddelelses modtagelsesantal overstiger maxReceiveCount, flytter SQS den automatisk til DLQ'en. DLQ'er forhindrer giftige meddelelser (meddelelser, der altid mislykkes) i at blokere køen på ubestemt tid. Meddelelser i DLQ'en kan undersøges, fejlsøges og afspilles igen, når behandlingsfejlen er rettet.

En DLQ er blot en almindelig SQS-kø (Standard for en Standard-kilde, FIFO for en FIFO-kilde). Du konfigurerer Redrive Policy på kildekøen for at angive, hvilken kø der er DLQ'en, samt grænsen for maxReceiveCount. Sørg for, at DLQ'ens opbevaringsperiode er længere end kildekøens opbevaringsperiode—meddelelser ankommer sent til DLQ'en, og du har brug for tid til at undersøge dem, før de udløber.

Indstil en CloudWatch-alarm på DLQ'ens metrik ApproximateNumberOfMessagesVisible. Enhver meddelelse, der ankommer til DLQ'en, angiver en behandlingsfejl, som kræver opmærksomhed. Konfigurer alarmen til at udløse en SNS-notifikation, der straks tilkalder den vagthavende udvikler. Betragt enhver DLQ-meddelelse som en fejl, der skal undersøges—DLQ-meddelelser bør ikke ophobes ubemærket. Når fejlen er rettet, kan du bruge DLQ Redrive til at sende meddelelser tilbage til kildekøen til genbehandling.

Når du har rettet den fejl, der forårsagede behandlingsfejlene, kan du bruge SQS DLQ Redrive til at flytte meddelelser fra DLQ'en tilbage til kildekøen til genbehandling. Konsollen har indbygget funktionalitet til dette. Du kan filtrere efter meddelelsesattributter for kun at afspille bestemte meddelelser. Alternativt kan du skrive en Lambda-funktion, der spørger DLQ'en og videresender meddelelser tilbage til kildekøen, hvis du har brug for brugerdefineret filtreringslogik.

Som standard bruger SQS kort polling: Et receive-message-kald udvælger et tilfældigt udsnit af serverne og returnerer straks—selv hvis der ikke er nogen tilgængelige meddelelser. Det resulterer i mange tomme svar og spilder API-kald. Long polling venter i op til 20 sekunder på, at en meddelelse ankommer, før der returneres et tomt svar. Long polling reducerer omkostningerne betydeligt (færre API-kald) og mindsker latenstiden (meddelelsen modtages, så snart den ankommer, op til 20 sekunder tidligere end i den næste pollingcyklus).

Aktivér long polling på køniveau (gælder for alle modtagelseskald) eller pr. anmodning. Konfiguration på køniveau med ReceiveMessageWaitTimeSeconds sat til 20 er den anbefalede indstilling for de fleste applikationer. Når Lambda bruger SQS som hændelseskilde, bruger den automatisk long polling. For forbrugere baseret på EC2 skal du angive WaitTimeSeconds i receive-message-kaldet.

SQS-meddelelser kan indeholde meddelelsesattributter—metadata i form af nøgle-værdi-par, der er adskilt fra meddelelsens brødtekst. Attributter har en type (String, Number, Binary) og en værdi. Når SQS abonnerer på et SNS-emne, kan du bruge filtreringspolitikker for SNS-abonnementer på meddelelsesattributterne til kun at dirigere relevante meddelelser til hver kø. Uden filtrering modtager alle SQS-abonnenter alle SNS-publiceringer uanset indholdet.

En forsinkelseskø gør alle nye meddelelser usynlige i en forsinkelsesperiode (0 til 15 minutter), efter at de er sendt. Det er nyttigt i arbejdsgange, hvor en forbruger ikke skal behandle en meddelelse med det samme—for eksempel mens den venter på, at en afhængig proces bliver færdig. Du kan også angive en forsinkelse pr. meddelelse ved hjælp af DelaySeconds i sendekaldet, hvilket tilsidesætter forsinkelsen på køniveau. Bemærk: Forsinkelseskøer er ikke tilgængelige for FIFO-køer.

I denne lektion lærte du: Visibility Timeout skjuler en meddelelse for andre forbrugere under behandlingen og muliggør levering mindst én gang med automatisk genlevering, hvis forbrugeren fejler. Dead-Letter Queues opfanger meddelelser, der gentagne gange fejler, så de kan fejlfindes og afspilles igen, når fejlen er rettet, og Long Polling (op til 20 sekunders ventetid) reducerer API-omkostninger og forsinkelse sammenlignet med kort polling. Nu skal vi se nærmere på SNS-emner og fan-out-arkitektur.