Velkou operaci rozdělte na malé idempotentní úlohy se stabilním identifikátorem a explicitním stavem. Dočasné chyby opakujte s rostoucím odstupem a limitem, trvalé přesuňte do kontrolní fronty. Monitorujte stáří nejstarší úlohy, počet selhání, dobu zpracování a chybějící běh workeru. Souběh omezte podle kapacity závislých služeb.
Fronty úloh ve WordPressu přesouvají pomalou nebo dočasně nespolehlivou práci mimo webový požadavek. Import, generování souboru, synchronizace či větší e-mailová dávka nemají držet uživatele na načítací obrazovce. Zařazení úlohy do Action Scheduleru nebo vlastní fronty však samo o sobě nezaručí, že se provede pouze jednou, ve správném pořadí a beze ztráty.
Spolehlivé zpracování potřebuje malou jednotku práce, stav, idempotentní klíč, retry politiku a provozní dohled. Tento návod se zabývá návrhem fronty a workerů. Liší se od diagnostiky samotného WP-Cronu: plánovač může spouštět worker, ale fronta musí samostatně vědět, co čeká, co selhalo a jak bezpečně pokračovat.
Rozhodněte, co patří do fronty
Do fronty patří práce, která je pomalá, dávková nebo závisí na vzdálené službě a nemusí být dokončena před odpovědí uživateli. Webový požadavek nejprve validuje vstup a spolehlivě uloží záměr, poté vrátí identifikátor a srozumitelný stav. Kritická kontrola oprávnění a základní validace se nesmějí bezdůvodně odsouvat na později.
Úlohu navrhněte jako jednu obchodní operaci s omezeným časem a pamětí. Zpracování deseti tisíc produktů rozdělte na stránky nebo jednotlivé záznamy s kurzorem. Příliš malé úlohy mohou vytvářet velkou režii; velká nedělitelná úloha se po chybě opakuje celá. Vhodný rozsah ověřte měřením.
Uložte stav a idempotentní klíč
Každá úloha má typ, bezpečný payload, stav, počet pokusů, čas dostupnosti a stabilní klíč obchodní operace. Payload neobsahuje tajemství, pokud je lze bezpečně načíst až za běhu. Místo celé objednávky uložte její ID a požadovanou verzi, aby bylo možné rozhodnout, zda je úloha ještě aktuální.
Worker před vedlejším účinkem ověří, zda výsledek již neexistuje. Při vytvoření zásilky použije stejný idempotentní klíč i ve vzdáleném API, pokud jej podporuje. Po pádu mezi vzdáleným úspěchem a lokálním zápisem další pokus nejprve výsledek dohledá. Stav hotovo se nastaví až po všech potvrzených krocích.
- Jednoznačný typ a bezpečný payload
- Idempotentní klíč operace
- Počet pokusů a další čas běhu
- Dohledatelný výsledek nebo důvod chyby
Rozlišujte dočasnou, trvalou a neznámou chybu
Timeout, rate limit a krátký výpadek bývají dočasné, proto se opakují s exponenciálním odstupem a náhodným rozptylem. Neplatná hodnota nebo chybějící mapování se opakováním neopraví; úloha jde do kontrolní fronty s konkrétním důvodem. Neznámý výsledek vyžaduje nejprve stavový dotaz, nikoli slepý další zápis.
Počet pokusů a maximální stáří omezte podle obchodního dopadu. Po vyčerpání limitu úlohu nemažte. Zachovejte diagnostická metadata, upozorněte vlastníka a nabídněte bezpečné opakování po odstranění příčiny. Tlačítko Retry musí získat zámek a respektovat idempotenci stejně jako automatický worker.
Řiďte souběh, pořadí a kapacitu
Dva workery nesmí zpracovat stejnou úlohu současně. Použijte atomický claim nebo zámek s přiměřenou expirací a heartbeat při dlouhé práci. Zatuchlý claim se může vrátit do fronty až po bezpečné době. Globální zámek na všechno zase zbytečně snižuje propustnost nezávislých úloh.
Pořadí garantujte pouze tam, kde je obchodní proces vyžaduje. Události jedné objednávky lze serializovat podle klíče, zatímco nezávislé produkty lze zpracovávat paralelně. Nastavte limit souběhu vůči databázi a externímu API. Backpressure zabrání tomu, aby velký import vytlačil malé urgentní úlohy z dostupné kapacity.
Monitorujte frontu jako produkční službu
Sledujte počet čekajících úloh, stáří nejstarší úlohy, dobu běhu, úspěšnost, opakování (retry) a selhání podle typu. Samostatné upozornění zachytí worker, který se vůbec nespustil. Dashboard zobrazí obchodní objekt a korelační ID bez citlivého payloadu, aby provoz dokázal dohledat objednávku či import.
Ve stagingu otestujte paralelní běh, pád po každém vedlejším účinku, timeout, rate limit a opakování po opravě. Pravidelně čistěte dokončenou historii podle retenčního pravidla, nikoli aktivní či chybové úlohy. Runbook popíše pozastavení producenta, odčerpání backlogu a kontrolu úplnosti po incidentu.
Časté dotazy
Je Action Scheduler totéž co WP-Cron?
Ne. Action Scheduler eviduje jednotlivé akce, stavy a pokusy; mechanismus jejich spouštění může využívat WP-Cron nebo systémový runner. Obě vrstvy potřebují samostatnou kontrolu a monitoring.
Proč se úloha ve frontě vykonala dvakrát?
Při timeoutu nebo paralelním workeru může dojít k opakování. Worker proto musí být idempotentní, používat atomický claim a před vedlejším účinkem ověřit existující výsledek.
Jak bezpečně zopakovat neúspěšnou úlohu?
Nejprve opravte a klasifikujte příčinu, ověřte, zda nevznikl částečný výsledek, a poté použijte stejný idempotentní klíč a kontrolovaný retry. Uchovejte původní historii i nový pokus.
Zdroje a další čtení
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
