Acordați lucrătorilor de fundal un buget limitat

Definiți o unitate de muncă utilă

Pentru un export CSV intern, o cerere creează o înregistrare de export; un lucrător citește un set de date limitat, scrie un obiect de ieșire și marchează înregistrarea ca finalizată. Definiți domeniul maxim util, limita de timp și comportamentul de anulare. Folosiți o coadă izolată, o bază de date de test și o destinație care nu poate notifica clienți reali.

Separați timpul de calcul de așteptarea bazei de date și a stocării. Un singur număr de durată a sarcinii ascunde aceste distincții. Construirea întregului fișier în memorie scalează diferit față de fluxul în loturi limitate. Păstrați mesajul din coadă suficient de mic pentru a descrie munca fără a încorpora date de client sau acreditări.

Faceți livrarea repetată sigură prin design

Folosiți un identificator durabil de export pentru a relaționa încercările cu un singur rezultat logic. Impuneți unicitatea și o tranziție atomică de proprietate/finalizare în stare durabilă. Verificarea dacă un export există și apoi inserarea într-un pas separat neprotejat permite încercărilor concurente să se întreacă. Publicarea unui obiect și confirmarea mesajului din coadă formează, de asemenea, o graniță de eșec.

# 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 conectează confirmarea târzie cu sarcini idempotente și documentează cazuri în care confirmarea are loc totuși după terminarea procesului copil. O opțiune de coadă nu creează execuție exactly-once. Revizuiți semantica de relivrare a sistemului dvs. și proiectați rezultatul aplicației pentru a tolera reîncercările.

Referință tehnică: Comportamentul sarcinilor Celery.

Stabiliți bugetul înainte de a crește procesele

Pentru un lucrător ipotetic care folosește 300 MiB per export activ, patru exporturi simultane implică deja aproximativ 1,200 MiB înainte de overhead-ul de runtime. Acestea sunt intrări de planificare, nu benchmark-uri. Adăugați conexiuni la baza de date, memorie pentru interogări, disc temporar și lățime de bandă de ieșire; numărul de procese este doar o singură limită.

Repetați cu un export activ și un backlog realist. Creșteți la două repetând același trafic API. Comparați exporturile utile finalizate, vechimea celei mai vechi sarcini, latența, eșecurile și presiunea pe host. Dacă debitul abia se îmbunătățește în timp ce așteptările bazei de date cresc, opriți creșterea concurenței. CPU suplimentar poate să nu elimine acel blocaj.

Opriți eșecul să creeze mai multă încărcare

Clasificați erorile înainte de a reîncerca. O întrerupere temporară a stocării poate fi tranzitorie; un cont neautorizat sau un format de export neacceptat necesită o eroare terminală sau intervenție. Folosiți un buget finit de încercări și reîncercări întârziate cu backoff și jitter acolo unde este acceptat. Păstrați sarcinile eșuate inspectabile cu câmpurile sensibile eliminate.

Aplicați timeout-uri apelurilor externe și un buget global pentru sarcină. Abandonarea unei încercări nu dovedește că efectul său secundar la distanță nu s-a produs. O publicare expirată poate să fi scris deja rezultatul. Reconciliați după ID-ul de export în loc să publicați orbește un alt rezultat.

Includeți lucrătorii în implementare și recuperare

Opriți lucrul nou pe workerul vechi folosind comportamentul său documentat de oprire. Lăsați lucrul în curs să se termine sau întrerupeți-l în siguranță sub un termen limită cunoscut. Testați o cădere după ce rezultatul este scris, dar înainte de înregistrarea finalizării; încercarea de înlocuire ar trebui să găsească un rezultat consistent, nu să-l dubleze.

Mențineți formatele de mesaje compatibile între versiunile suprapuse. Un API nou poate pune în coadă un payload pe care un worker vechi nu îl poate citi. Versionați contractul sau secvențiați lansarea astfel încât consumatorii acceptați să existe înainte de apariția mesajelor noi. Includeți acești scriitori de baze de date în revizuirea compatibilității schemei.

Alegeți următoarea constrângere de modificat

Lăsați o setare de concurență, o politică de reîncercare, un contract de sarcină și o regulă de oprire măsurată. Dacă exporturile costisitoare întârzie sarcinile mici, luați în considerare cozi separate cu bugete independente înainte de a ridica limita globală. Dacă latența API suferă la orice încărcare realistă de export, separarea workerilor poate fi mai utilă decât mărirea unui singur host partajat.

Repetați aceeași încărcare de lucru după o modificare și păstrați comparația. Scenariul API și workers explică unde App 2 și memoria suplimentară intră în alegere. Aceste proceduri nu implică o coadă gestionată, joburi nelimitate sau scalare automată.