Geben Sie Hintergrund-Workern ein begrenztes Budget

Definieren Sie eine Einheit nützlicher Arbeit

Bei einem internen CSV-Export erstellt eine Anfrage einen Exportdatensatz; ein Worker liest einen begrenzten Datensatz, schreibt ein Ausgabeobjekt und markiert den Datensatz als abgeschlossen. Definieren Sie den maximal nützlichen Umfang, das Zeitlimit und das Abbruchverhalten. Verwenden Sie eine isolierte Warteschlange, Testdatenbank und ein Ziel, das keine echten Kunden benachrichtigen kann.

Rechenzeit von Datenbank- und Speicherwartezeit trennen. Eine einzelne Auftragsdauerzahl verbirgt diese Unterschiede. Das Erstellen der gesamten Datei im Speicher skaliert anders als das Streamen begrenzter Stapel. Halten Sie die Queue-Nachricht klein genug, um die Arbeit zu beschreiben, ohne Kundendaten oder Anmeldedaten einzubetten.

Machen Sie wiederholte Zustellung von Grund auf sicher

Verwenden Sie eine dauerhafte Exportkennung, um Versuche einem logischen Ergebnis zuzuordnen. Erzwingen Sie Eindeutigkeit und einen atomaren Übergang von Eigentümerschaft/Abschluss im dauerhaften Zustand. Wenn Sie prüfen, ob ein Export existiert, und dann in einem separaten ungeschützten Schritt einfügen, können gleichzeitige Versuche in einen Wettlauf geraten. Das Veröffentlichen eines Objekts und das Bestätigen der Queue-Nachricht bilden ebenfalls eine Fehlergrenze.

# 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 verbindet späte Bestätigung mit idempotenten Aufgaben und dokumentiert Fälle, in denen die Bestätigung dennoch nach der Beendigung des Kindprozesses erfolgt. Eine Queue-Option erzeugt keine Exactly-once-Ausführung. Prüfen Sie die Redelivery-Semantik Ihres Systems und gestalten Sie das Anwendungsergebnis so, dass es Wiederholungen toleriert.

Technische Referenz: Celery-Aufgabenverhalten.

Legen Sie das Budget fest, bevor Sie Prozesse erhöhen

Für einen hypothetischen Worker, der 300 MiB pro aktivem Export verwendet, implizieren vier gleichzeitige Exporte bereits etwa 1,200 MiB vor Laufzeit-Overhead. Dies sind Planungsannahmen, keine Benchmarks. Fügen Sie Datenbankverbindungen, Abfragespeicher, temporären Speicherplatz und Ausgabebandbreite hinzu; eine Prozessanzahl ist nur eine Grenze.

Proben Sie mit einem aktiven Export und einem realistischen Rückstand. Erhöhen Sie auf zwei, während Sie denselben API-Verkehr wiederholen. Vergleichen Sie abgeschlossene nützliche Exporte, Alter des ältesten Auftrags, Latenz, Fehler und Host-Auslastung. Wenn der Durchsatz kaum steigt, während Datenbankwartezeiten zunehmen, erhöhen Sie die Parallelität nicht weiter. Zusätzliche CPU beseitigt diesen Engpass möglicherweise nicht.

Verhindern Sie, dass Fehler mehr Last erzeugen

Klassifizieren Sie Fehler vor dem Wiederholen. Ein vorübergehender Speicherausfall kann transient sein; ein nicht autorisiertes Konto oder ein nicht unterstütztes Exportformat erfordert einen terminalen Fehler oder Eingreifen. Verwenden Sie ein endliches Versuchsbudget und verzögerte Wiederholungen mit Backoff und Jitter, wo unterstützt. Halten Sie fehlgeschlagene Aufträge mit entfernten sensiblen Feldern überprüfbar.

Zeitlimits für externe Aufrufe und ein Gesamtbudget pro Aufgabe anwenden. Der Abbruch eines Versuchs beweist nicht, dass seine entfernte Nebenwirkung nicht eingetreten ist. Eine zeitlich überschrittene Veröffentlichung hat möglicherweise bereits die Ausgabe geschrieben. Anhand der Export-ID abgleichen, statt blind ein weiteres Ergebnis zu veröffentlichen.

Beziehen Sie Worker in Deployment und Wiederherstellung ein

Neue Arbeit am alten Worker mit seinem dokumentierten Herunterfahrverhalten stoppen. Laufende Arbeit abschließen lassen oder sicher unter einer bekannten Frist unterbrechen. Einen Absturz testen, nachdem die Ausgabe geschrieben, aber bevor der Abschluss erfasst wurde; der Ersatzversuch sollte ein konsistentes Ergebnis finden, statt es zu duplizieren.

Nachrichtenformate über sich überschneidende Releases hinweg kompatibel halten. Eine neue API kann eine Nutzlast einreihen, die ein alter Worker nicht lesen kann. Den Vertrag versionieren oder den Rollout sequenzieren, sodass unterstützte Konsumenten existieren, bevor neue Nachrichten erscheinen. Diese Datenbank-Schreibvorgänge in die Schema-Kompatibilitätsprüfung einbeziehen.

Wählen Sie die nächste zu ändernde Einschränkung

Eine Parallelitätseinstellung, Retry-Richtlinie, Aufgabenvertrag und gemessene Stoppregel hinterlassen. Wenn teure Exporte kleine Jobs verzögern, separate Queues mit unabhängigen Budgets in Betracht ziehen, bevor das globale Limit erhöht wird. Wenn die API-Latenz bei einer realistischen Exportlast leidet, kann die Trennung von Workern nützlicher sein als die Vergrößerung eines gemeinsamen Hosts.

Dieselbe Arbeitslast nach einer Änderung wiederholen und den Vergleich aufbewahren. Die API- und Worker-Szenario erklärt, wo App 2 und zusätzlicher Speicher in die Entscheidung einfließen. Diese Verfahren implizieren keine verwaltete Queue, unbegrenzte Jobs oder automatische Skalierung.