Gør langsomme app-opgaver sikre med baggrundsjob og jobkøer

Flyt kun arbejdet i baggrunden, når problemet kræver det

En kø er ekstra infrastruktur, ikke et mål i sig selv. Microsoft anbefaler købaseret behandling ved ujævne belastninger og behov for at adskille modtagelse fra behandling, men peger også på, at den kan være unødvendig ved lav, stabil belastning eller når brugeren behøver et øjeblikkeligt svar.

Et modtaget job er ikke et færdigt job

HTTP-status 202 betyder, at en request er accepteret til behandling; den siger ikke, at behandlingen er begyndt eller vil lykkes. Hvis appen viser “færdig” med det samme, skjuler den derfor den vigtigste del af forløbet.

1. Validér og godkend requesten: Kontrollér bruger, tenant, input og rettighed, før arbejdet accepteres.
2. Opret en stabil jobreference: Gem type, ejer, tidspunkt og status uden at kopiere unødige følsomme data.
3. Læg arbejdet holdbart i kø: Brug samme job-id som reference mellem database, kø, logs og brugerflade.
4. Svar med modtagelse og statusvej: Brugeren skal kunne se, om jobbet venter, kører, er gennemført eller kræver handling.
5. Lad en worker udføre opgaven: Workerens succes skal afspejle det forretningsresultat, I lovede — ikke kun at koden nåede sidste linje.

Regn med, at samme opgave kan blive leveret igen

Både Microsoft og Google beskriver køer med mindst én levering. En worker kan nå at ændre data og derefter gå ned, før køen får kvitteringen. Beskeden bliver så synlig igen. Koden skal derfor være idempotent: samme job-id eller hændelses-id må kunne behandles igen uden en ny faktura, booking, mail eller anden skadelig sideeffekt.

En unik opgavenøgle i køen kan mindske dobbelte beskeder, men den erstatter ikke idempotens i workeren. Gentagelsen kan opstå efter, at opgaven er taget fra køen.

Retry kun fejl, der kan blive raske af at vente

En timeout, midlertidig netværksfejl eller begrænsning hos en leverandør kan lykkes ved et senere forsøg. Et manglende obligatorisk felt, slettet kunde-id eller afvist rettighed bliver ikke rettet af at køre samme kode igen. Uendelige retries skaber støj, udgift og risiko for gentagne sideeffekter.

• Klassificér fejlen: Aftal hvilke fejlkoder der er midlertidige, permanente eller kræver manuel vurdering.
• Vent mellem forsøg: Brug stigende forsinkelse og respekter leverandørens svar om throttling, hvor det findes.
• Sæt en grænse: Vælg antal forsøg og samlet tidsrum efter opgavens betydning og risiko — ikke ét tilfældigt standardtal til alle jobs.
• Parkér permanente fejl: Flyt dem til en fejlstatus eller dead-letter-kø med årsag og ansvarlig modtager.
• Genkør kontrolleret: Ret årsagen, kontrollér idempotensen, og genstart kun de afgrænsede jobs.

Giv workeren mindre adgang end administratoren

Baggrundsjob får ofte adgang til databaser, filer og eksterne API'er. Microsoft anbefaler mindst mulige rettigheder og advarer mod følsomme data direkte i købeskeder, fordi payloads kan blive logget, parkeret som fejl eller inspiceret under fejlsøgning.

• Send referencer, ikke hele dokumenter: Lad beskeden indeholde job-id og nødvendige nøglefelter; hent beskyttede data fra deres normale lager.
• Hold secrets ude af payloaden: Workeren skal hente dem gennem platformens sikre konfiguration med sin egen identitet.
• Beskyt worker-endpointet: Det må ikke kunne kaldes frit fra browseren eller internettet uden platformsgodkendelse.
• Håndhæv tenant ved status: En bruger må kun kunne se og genstarte jobs, som rollen og virksomhedstilknytningen giver adgang til.
• Begræns genkørsel: Manuel retry er en privilegeret driftshandling og bør logges med aktør og job-id.

Vis en status, som brugeren kan handle på

Brugeren behøver ikke kende køteknologien. Personen skal vide, om opgaven er modtaget, om det er sikkert at lukke siden, og hvad der sker ved en fejl.

Modtaget

Opgaven er gemt holdbart og har et job-id. Den er endnu ikke gennemført.

Behandles

Vis starttid og eventuelt meningsfuldt fremskridt, hvis workeren kan gemme det pålideligt.

Gennemført

Link til resultatet, og vis hvornår det blev skabt eller sendt.

Kræver handling

Forklar problemet i almindeligt sprog og den sikre næste handling uden at vise stack trace eller secrets.

Overvåg resultatet — ikke kun at jobbet startede

Et job kan starte, hænge og aldrig skrive en almindelig fejl. Microsoft anbefaler at registrere start, afslutning og fejl samt at overvåge manglende planlagte kørsler, dead-letter-køer og tiden fra oprettelse til færdigt resultat.

• Køens ældste opgave og ventetid: Viser om arbejdet sakker bagud, selv om hver worker er hurtig.
• Antal retries og permanente fejl: Afslører en ustabil integration eller ugyldige data, før køen fyldes.
• Seneste forventede kørsel: Opdager et planlagt job, der slet ikke startede.
• Færdige forretningsresultater: Tæl gennemførte imports, rapporter eller synkroniseringer — ikke kun HTTP-svar.
• Korrelations-id: Brug samme job-id gennem kø, worker, database og eksternt kald, så forløbet kan findes igen.

Alarmen skal have en navngiven modtager og en kort runbook: sådan pauser I workeren, finder berørte jobs, retter årsagen og genkører uden dubletter.

Vælg kø efter appens eksisterende miljø

Arkitekturen er den samme, men produktet afhænger af jeres stack. Vælg ikke Azure eller Firebase alene for at få en kø, hvis appen allerede har en anden driftssikker platform med et officielt job- eller køsystem.

Firebase dokumenterer konfiguration af retry og rate limits i task queue functions. Azure dokumenterer både Queue Storage og Service Bus som køkilder til Functions. Tallene skal vælges ud fra jeres opgave, leverandørgrænser og ønskede behandlingstid.

Typiske fejl

• Fire-and-forget i et webrequest: Koden starter arbejde efter svaret, men processen kan blive lukket uden at opgaven gemmes.
• “202” vises som succes: Brugeren får grønt flueben, selv om jobbet kun er modtaget og senere kan fejle.
• Retry uden idempotens: En timeout bliver til dobbelte mails, bookinger, poster eller betalinger.
• Alle fejl genforsøges: Ugyldige data kører i ring og blokerer opgaver, der kunne gennemføres.
• Payloaden er en datakopi: Persondata og secrets ender i logs, køværktøj og dead-letter-visning.
• Kun kølængden måles: En tom kø ser sund ud, selv om en scheduler aldrig oprettede dagens jobs.
• Ubegrænset parallelitet: Flere workers overbelaster databasen eller den eksterne tjeneste, som køen skulle beskytte.

Tjekliste før baggrundsjob får rigtige data

• ☐ Hvert job har en konkret forretningsejer, et forventet resultat og en acceptabel forsinkelse.
• ☐ Det er besluttet, hvilke opgaver der skal være synkrone, købaserede eller planlagte.
• ☐ Jobbet gemmes holdbart og får et stabilt id, før brugeren får besked om modtagelse.
• ☐ Workeren kan behandle samme job mere end én gang uden skadelige dubletter.
• ☐ Midlertidige og permanente fejl håndteres forskelligt med begrænsede retries.
• ☐ Permanente fejl parkeres synligt og har en ansvarlig modtager.
• ☐ Payloads indeholder ingen secrets og kun nødvendige data eller beskyttede referencer.
• ☐ Worker-identitet og statusvisning følger mindst mulige rettigheder og tenantgrænser.
• ☐ Brugeren kan se modtaget, behandling, gennemført og en sikker fejlhandling.
• ☐ Ventetid, færdiggørelse, retries, fejlende jobs og manglende planlagte kørsler overvåges.
• ☐ En kontrolleret test har simuleret timeout, worker-genstart, dubletlevering og permanent fejl.
• ☐ Runbooken forklarer pause, afgrænsning, rettelse og sikker genkørsel.

Officielle kilder

Platforme ændrer funktioner og grænser. Kontrollér derfor altid den aktuelle dokumentation for den konkrete region, runtime og tjeneste, I bruger.

• Microsoft Azure Architecture Center: Best practices for background jobs
• Microsoft Azure Architecture Center: Queue-Based Load Leveling pattern
• Microsoft Azure Architecture Center: Web-Queue-Worker architecture
• Microsoft Azure Architecture Center: Retry pattern
• Firebase: Enqueue functions with Cloud Tasks
• Google Cloud: Understand Cloud Tasks
• MDN Web Docs: HTTP 202 Accepted

Relaterede guides