Veľkú operáciu rozdeľte na malé idempotentné úlohy so stabilným identifikátorom a explicitným stavom. Dočasné chyby opakujte s rastúcim odstupom a limitom, trvalé presuňte do kontrolnej fronty. Monitorujte vek najstaršej úlohy, počet zlyhaní, čas spracovania a chýbajúci beh workera. Súbeh obmedzte podľa kapacity závislých služieb.
Fronty úloh vo WordPresse presúvajú pomalú alebo dočasne nespoľahlivú prácu mimo webovej požiadavky. Import, generovanie súboru, synchronizácia či väčšia e-mailová dávka nemajú držať používateľa na načítavacej obrazovke. Zaradenie úlohy do Action Scheduleru alebo vlastnej fronty však samo osebe nezaručí, že sa vykoná iba raz, v správnom poradí a bez straty.
Spoľahlivé spracovanie potrebuje malú jednotku práce, stav, idempotentný kľúč, retry politiku a prevádzkový dohľad. Tento návod rieši návrh fronty a workerov. Odlišuje sa od diagnostiky samotného WP-Cronu: plánovač môže spúšťať worker, ale fronta musí osobitne vedieť, čo čaká, čo zlyhalo a ako bezpečne pokračovať.
Rozhodnite, čo patrí do fronty
Do fronty patrí práca, ktorá je pomalá, dávková alebo závisí od vzdialenej služby a nemusí dokončiť odpoveď používateľovi. Webová požiadavka najprv validuje vstup a spoľahlivo uloží zámer, potom vráti identifikátor a zrozumiteľný stav. Kritická kontrola oprávnenia a základná validácia sa nesmú bezdôvodne odsunúť až na neskôr.
Úlohu navrhnite ako jednu obchodnú operáciu s ohraničeným časom a pamäťou. Spracovanie desaťtisíc produktov rozdeľte na stránky alebo jednotlivé záznamy s kurzorom. Príliš malé úlohy môžu vytvoriť veľkú réžiu; veľká nedeliteľná úloha sa po chybe opakuje celá. Rozsah overte meraním.
Uložte stav a idempotentný kľúč
Každá úloha má typ, bezpečný payload, stav, počet pokusov, čas dostupnosti a stabilný kľúč obchodnej operácie. Payload neobsahuje tajomstvá, ak ich možno načítať bezpečne až pri behu. Namiesto celej objednávky uložte jej ID a požadovanú verziu, aby sa dalo rozhodnúť, či je úloha ešte aktuálna.
Worker pred vedľajším účinkom overí, či výsledok už neexistuje. Pri vytvorení zásielky použije rovnaký idempotentný kľúč aj vo vzdialenom API, ak ho podporuje. Po páde medzi vzdialeným úspechom a lokálnym zápisom ďalší pokus najprv výsledok dohľadá. Stav hotovo sa nastaví až po všetkých potvrdených krokoch.
- Jednoznačný typ a bezpečný payload
- Idempotentný kľúč operácie
- Počet pokusov a ďalší čas behu
- Dohľadateľný výsledok alebo dôvod chyby
Rozlíšte dočasnú, trvalú a neznámu chybu
Timeout, rate limit a krátky výpadok bývajú dočasné, preto sa opakujú s exponenciálnym odstupom a náhodným rozptylom. Neplatná hodnota alebo chýbajúce mapovanie sa opakovaním neopraví; úloha ide do kontrolnej fronty s konkrétnym dôvodom. Neznámy výsledok vyžaduje najprv stavový dotaz, nie slepý ďalší zápis.
Počet pokusov a maximálny vek obmedzte podľa obchodného dopadu. Po vyčerpaní limitu úlohu nevymažte. Zachovajte diagnostické metadata, upozornite vlastníka a ponúknite bezpečné opakovanie po oprave príčiny. Retry tlačidlo musí získať zámok a rešpektovať idempotenciu rovnako ako automatický worker.
Riaďte súbeh, poradie a kapacitu
Dva workery nesmú spracovať rovnakú úlohu súčasne. Použite atómový claim alebo zámok s primeranou expiráciou a heartbeat pri dlhej práci. Zatuchnutý claim sa môže vrátiť do fronty až po bezpečnom čase. Globálny zámok všetkého zasa zbytočne znižuje priechodnosť nezávislých úloh.
Poradie garantujte iba tam, kde ho obchodný proces potrebuje. Udalosti jednej objednávky možno serializovať podľa kľúča, kým nezávislé produkty spracovať paralelne. Nastavte limit súbehu voči databáze a externému API. Backpressure zabráni tomu, aby veľký import vytlačil malé urgentné úlohy z dostupnej kapacity.
Monitorujte frontu ako produkčnú službu
Sledujte počet čakajúcich, vek najstaršej úlohy, čas behu, úspešnosť, retry a zlyhania podľa typu. Samostatné upozornenie zachytí worker, ktorý sa vôbec nespustil. Dashboard ukáže obchodný objekt a korelačné ID bez citlivého payloadu, aby prevádzka vedela nájsť objednávku či import.
V stagingu testujte paralelný beh, pád po každom vedľajšom účinku, timeout, rate limit a opakovanie po oprave. Pravidelne čistite dokončenú históriu podľa retenčného pravidla, nie aktívne či chybové úlohy. Runbook popíše pozastavenie producenta, odčerpanie backlogu a kontrolu úplnosti po incidente.
Časté otázky
Je Action Scheduler to isté ako WP-Cron?
Nie. Action Scheduler eviduje jednotlivé akcie, stavy a pokusy; mechanizmus ich spúšťania môže využívať WP-Cron alebo systémový runner. Obe vrstvy potrebujú samostatnú kontrolu a monitoring.
Prečo sa úloha vo fronte vykonala dvakrát?
Pri timeoute alebo paralelnom workeri môže dôjsť k opakovaniu. Worker preto musí byť idempotentný, používať atómový claim a pred vedľajším účinkom overiť existujúci výsledok.
Ako bezpečne zopakovať zlyhanú úlohu?
Najprv opravte a klasifikujte príčinu, overte či nevznikol čiastočný výsledok, potom použite rovnaký idempotentný kľúč a kontrolovaný retry. Uchovajte pôvodnú históriu aj nový pokus.
Zdroje a ďalšie čítanie
Web developer zo Spišskej Novej Vsi. Venuje sa WordPressu, WooCommerce, vlastným pluginom, API integráciám, webovým aplikáciám a praktickým AI automatizáciám.
