Geef achtergrondworkers een begrensd budget

Definieer één eenheid nuttig werk

Voor een interne CSV-export creëert een verzoek een exportrecord; een worker leest een begrensde dataset, schrijft een outputobject en markeert het record als voltooid. Definieer maximale nuttige scope, tijdslimiet en annuleringsgedrag. Gebruik een geïsoleerde wachtrij, testdatabase en bestemming die echte klanten niet kan notificeren.

Scheid rekentijd van wachten op database en opslag. Eén getal voor jobduur verbergt deze verschillen. Het hele bestand in het geheugen opbouwen schaalt anders dan het streamen van begrensde batches. Houd het wachtrijbericht klein genoeg om het werk te beschrijven zonder klantgegevens of een credential in te sluiten.

Maak herhaalde levering veilig door ontwerp

Gebruik een duurzame exportidentificatie om pogingen aan één logisch resultaat te koppelen. Handhaaf uniciteit en een atomaire overgang van eigendom/voltooiing in duurzame state. Controleren of een export bestaat en vervolgens invoegen in een aparte onbeschermde stap laat gelijktijdige pogingen racen. Het publiceren van een object en het bevestigen van het wachtrijbericht vormen ook een faalgrens.

# Illustrative contract, not queue implementation
job_type: export-account-report
logical_result: EXPORT_RECORD_ID
input_scope: AUTHORIZED_ACCOUNT_AND_DATE_RANGE
attempt_limit: REVIEWED_FINITE_LIMIT
completion: ONE_PUBLISHED_RESULT_FOR_THIS_EXPORT
retry: CLASSIFIED_TRANSIENT_FAILURES_ONLY
failed_result: INSPECTABLE_WITHOUT_CUSTOMER_SECRETS

Celery verbindt late acknowledgement met idempotente tasks en documenteert gevallen waarin acknowledgement nog steeds plaatsvindt na beëindiging van een child-process. Een wachtrijoptie creëert geen exactly-once uitvoering. Beoordeel de redelivery-semantiek van uw systeem en ontwerp het applicatieresultaat zodat het herhalingen tolereert.

Technische referentie: Celery-taakgedrag.

Stel het budget in voordat u processen verhoogt

Voor een hypothetische worker die 300 MiB per actieve export gebruikt, impliceren vier gelijktijdige exports al ongeveer 1,200 MiB vóór runtime-overhead. Dit zijn planningsinputs, geen benchmarks. Voeg databaseverbindingen, querygeheugen, tijdelijke schijf en outputbandbreedte toe; een procesaantal is slechts één limiet.

Repeteer met één actieve export en een realistische backlog. Verhoog naar twee terwijl u hetzelfde API-verkeer herhaalt. Vergelijk voltooide nuttige exports, leeftijd van de oudste job, latentie, fouten en hostdruk. Als de doorvoer nauwelijks verbetert terwijl database-wachttijden groeien, stop dan met het verhogen van concurrency. Extra CPU verwijdert dat knelpunt mogelijk niet.

Voorkom dat falen meer belasting creëert

Classificeer fouten voordat u opnieuw probeert. Een tijdelijke storing in de opslag kan voorbijgaand zijn; een ongeautoriseerd account of niet-ondersteund exportformaat vereist een terminale fout of interventie. Gebruik een eindig pogingsbudget en vertraagde herhalingen met backoff en jitter waar ondersteund. Houd mislukte jobs inspecteerbaar met gevoelige velden verwijderd.

Pas time-outs toe op externe aanroepen en een algeheel taakbudget. Het opgeven van een poging bewijst niet dat het externe neveneffect niet is opgetreden. Een publicatie die een time-out krijgt, kan de uitvoer al hebben geschreven. Reconcilieer op export-ID in plaats van blindelings een ander resultaat te publiceren.

Neem workers op in deployment en herstel

Stop nieuw werk op de oude worker met behulp van het gedocumenteerde afsluitgedrag. Laat lopend werk afronden of onderbreek het veilig binnen een bekende deadline. Test een crash nadat de uitvoer is geschreven maar voordat de voltooiing is vastgelegd; de vervangende poging moet een consistent resultaat vinden in plaats van het te dupliceren.

Houd berichtformaten compatibel across overlappende releases. Een nieuwe API kan een payload in de wachtrij plaatsen die een oude worker niet kan lezen. Versioneer het contract of sequence de uitrol zodat ondersteunde consumers bestaan voordat nieuwe berichten verschijnen. Neem deze database-writers op in de schema-compatibiliteitsbeoordeling.

Kies de volgende beperking om te wijzigen

Laat een concurrency-instelling, retry-beleid, taakcontract en gemeten stopregel achter. Als dure exports kleine jobs vertragen, overweeg dan afzonderlijke queues met onafhankelijke budgetten voordat je de globale limiet verhoogt. Als de API-latency lijdt onder een realistische exportbelasting, kan het scheiden van workers nuttiger zijn dan het vergroten van één gedeelde host.

Herhaal dezelfde workload na een wijziging en bewaar de vergelijking. De API- en workers-scenario legt uit waar App 2 en extra geheugen de keuze binnenkomen. Deze procedures impliceren geen managed queue, onbeperkte jobs of automatische scaling.