Dużą operację podziel na małe, idempotentne zadania ze stabilnym identyfikatorem i jawnym stanem. Błędy przejściowe ponawiaj z rosnącym odstępem i limitem, a trwałe przenoś do kolejki kontrolnej. Monitoruj wiek najstarszego zadania, liczbę niepowodzeń, czas przetwarzania i brak uruchomień workera. Współbieżność ograniczaj zgodnie z przepustowością usług zależnych.
Kolejki zadań w WordPressie przenoszą powolną lub chwilowo zawodną pracę poza żądanie HTTP. Import, generowanie pliku, synchronizacja czy większa wysyłka e-maili nie powinny zatrzymywać użytkownika na ekranie ładowania. Samo dodanie zadania do Action Schedulera lub własnej kolejki nie gwarantuje jednak, że zostanie ono wykonane tylko raz, we właściwej kolejności i bez utraty.
Niezawodne przetwarzanie wymaga małej jednostki pracy, stanu, klucza idempotentności, polityki ponowień i nadzoru operacyjnego. Ten poradnik dotyczy projektowania kolejki i workerów. Różni się od diagnostyki samego WP-Crona: harmonogram może uruchamiać workera, ale kolejka musi osobno wiedzieć, co czeka, co się nie powiodło i jak bezpiecznie kontynuować.
Zdecyduj, co trafia do kolejki
Do kolejki trafia praca, która jest powolna, wsadowa lub zależy od zdalnej usługi i nie musi zakończyć się przed udzieleniem odpowiedzi użytkownikowi. Żądanie webowe najpierw waliduje dane wejściowe i niezawodnie zapisuje zamiar, a następnie zwraca identyfikator i zrozumiały status. Krytycznej kontroli uprawnień i podstawowej walidacji nie wolno bez powodu odkładać na później.
Zadanie należy zaprojektować jako jedną operację biznesową z ograniczonym czasem i pamięcią. Przetwarzanie dziesięciu tysięcy produktów warto podzielić na strony lub pojedyncze rekordy z kursorem. Zbyt małe zadania mogą generować duży narzut; duże niepodzielne zadanie po błędzie jest powtarzane w całości. Zakres należy zweryfikować pomiarem.
Zapisz stan i klucz idempotencji
Każde zadanie ma typ, bezpieczny payload, stan, liczbę prób, czas dostępności i stabilny klucz operacji biznesowej. Payload nie zawiera sekretów, jeśli można je bezpiecznie pobrać dopiero w czasie wykonania. Zamiast całego zamówienia zapisz jego ID i wymaganą wersję, aby można było ocenić, czy zadanie jest nadal aktualne.
Worker przed wykonaniem efektu ubocznego sprawdza, czy wynik już nie istnieje. Przy tworzeniu przesyłki używa tego samego klucza idempotentności również w zdalnym API, jeśli je obsługuje. Po awarii między sukcesem po stronie zdalnej a lokalnym zapisem kolejna próba najpierw odszukuje wynik. Status „gotowe” ustawia się dopiero po wszystkich potwierdzonych krokach.
- Jednoznaczny typ i bezpieczny payload
- Idempotentny klucz operacji
- Liczba prób i czas kolejnego uruchomienia
- Możliwy do prześledzenia wynik lub przyczyna błędu
Proszę odróżniać błąd tymczasowy, trwały i nieznany
Timeout, rate limit i krótka awaria są zazwyczaj przejściowe, dlatego ponawia się je z wykładniczym odstępem i losowym rozrzutem. Nieprawidłowej wartości ani brakującego mapowania ponawianie nie naprawi; zadanie trafia do kolejki kontrolnej z konkretnym powodem. Nieznany wynik wymaga najpierw zapytania o stan, a nie kolejnego zapisu na ślepo.
Liczbę prób i maksymalny wiek ogranicz zgodnie z wpływem biznesowym. Po wyczerpaniu limitu nie usuwaj zadania. Zachowaj metadane diagnostyczne, powiadom właściciela i zapewnij bezpieczne ponowienie po usunięciu przyczyny. Przycisk retry musi uzyskać blokadę i respektować idempotencję tak samo jak automatyczny worker.
Zarządzaj współbieżnością, kolejnością i przepustowością
Dwa workery nie mogą przetwarzać tego samego zadania jednocześnie. Należy użyć atomowego claimu lub blokady z odpowiednim czasem wygaśnięcia oraz heartbeatu przy długiej pracy. Przeterminowany claim może wrócić do kolejki dopiero po bezpiecznym czasie. Z kolei globalna blokada wszystkiego niepotrzebnie obniża przepustowość niezależnych zadań.
Kolejność gwarantujcie tylko tam, gdzie wymaga jej proces biznesowy. Zdarzenia jednego zamówienia można serializować według klucza, a niezależne produkty przetwarzać równolegle. Ustawcie limit współbieżności względem bazy danych i zewnętrznego API. Backpressure zapobiegnie temu, by duży import wypchnął małe pilne zadania z dostępnej przepustowości.
Monitorujcie kolejkę jak usługę produkcyjną
Proszę monitorować liczbę oczekujących zadań, wiek najstarszego zadania, czas wykonania, skuteczność, ponowienia i awarie według typu. Osobny alert wychwyci worker, który w ogóle się nie uruchomił. Dashboard pokaże obiekt biznesowy i identyfikator korelacji bez wrażliwego payloadu, aby zespół operacyjny mógł odnaleźć zamówienie lub import.
Na stagingu testuj równoległe uruchomienia, awarię po każdym efekcie ubocznym, timeout, rate limit oraz ponowienie po naprawie. Regularnie czyść zakończoną historię zgodnie z regułą retencji, nie zadania aktywne ani zakończone błędem. Runbook opisze wstrzymanie producenta, opróżnienie backlogu i kontrolę kompletności po incydencie.
Najczęstsze pytania
Czy Action Scheduler to to samo co WP-Cron?
Nie. Action Scheduler rejestruje poszczególne akcje, statusy i próby; mechanizm ich uruchamiania może korzystać z WP-Cron lub systemowego runnera. Obie warstwy wymagają osobnej kontroli i monitoringu.
Dlaczego zadanie w kolejce wykonało się dwukrotnie?
Przy timeoucie lub równoległym workerze może dojść do powtórzenia. Dlatego worker musi być idempotentny, używać atomowego claimu i przed efektem ubocznym sprawdzić istniejący wynik.
Jak bezpiecznie powtórzyć nieudane zadanie?
Najpierw należy usunąć i sklasyfikować przyczynę, sprawdzić, czy nie powstał częściowy wynik, a następnie użyć tego samego klucza idempotencji i kontrolowanego retry. Warto zachować zarówno pierwotną historię, jak i nową próbę.
Źródła i dalsza lektura
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.
