Poznaj wzorce planowania zadań w tle przy użyciu przepływów pracy i tabeli zadań, aby niezawodnie uruchamiać przypomnienia, codzienne podsumowania i zadania porządkowe.
Cron jest świetny pierwszego dnia: wpisz jedną linię, wybierz czas i zapomnij. Dla jednego serwera i jednego zadania zwykle działa.
Problemy pojawiają się, gdy zaczynasz polegać na harmonogramie jako części rzeczywistego zachowania produktu: przypomnienia, codzienne podsumowania, porządki czy zadania synchronizacji. Większość historii o „przebiegu, który się nie odbył” nie wynika z awarii crona. To wszystko wokół niego: restart serwera, deploy który nadpisał crontab, zadanie które działało dłużej niż oczekiwano, lub rozbieżność zegara czy strefy czasowej. A gdy masz kilka instancji aplikacji, pojawia się odwrotny problem: duplikaty, bo dwie maszyny uznały, że powinny uruchomić to samo zadanie.
Testowanie to kolejny słaby punkt. Linia crona nie daje prostego sposobu, by powtarzalnie uruchomić „co by się stało o 9:00 jutro”. W efekcie harmonogram staje się ręcznymi sprawdzeniami, niespodziankami w produkcji i polowaniem w logach.
Zanim wybierzesz podejście, określ, co właściwie planujesz. Większość pracy w tle mieści się w kilku kategoriach:
Czasem w ogóle można pominąć harmonogram. Jeśli coś może się zdarzyć przy zajściu zdarzenia (użytkownik zakłada konto, płatność dochodzi, zgłoszenie zmienia status), praca zdarzeniowa jest zwykle prostsza i bardziej niezawodna niż praca oparta na czasie.
Gdy potrzebujesz czasu, niezawodność sprowadza się głównie do widoczności i kontroli. Chcesz miejsce, gdzie zapiszesz, co powinno się uruchomić, co się uruchomiło i co się nie udało, oraz bezpieczny sposób powtórzenia bez generowania duplikatów.
Prosty sposób na uniknięcie problemów z cronem to rozdzielenie obowiązków:
Oddzielenie tych ról pomaga na dwa sposoby. Możesz zmieniać harmonogram bez dotykania logiki biznesowej i zmieniać logikę biznesową bez psucia harmonogramu.
Tabela zadań staje się źródłem prawdy. Zamiast chować stan w procesie serwera czy linii crona, każdy kawałek pracy to wiersz: co wykonać, dla kogo, kiedy ma się uruchomić i co się wydarzyło ostatnim razem. Gdy coś pójdzie nie tak, możesz to obejrzeć, ponowić lub anulować bez zgadywania.
Typowy przebieg wygląda tak:
run_at <= now i status = queued).Kluczowa idea: uczynić pracę możliwą do wznowienia, a nie magiczną. Jeśli worker padnie w połowie, rząd zadania powinien nadal mówić, co się stało i co robić dalej.
Tabela zadań powinna szybko odpowiadać na dwa pytania: co ma się uruchomić następne i co stało się ostatnim razem.
Zacznij od niewielkiego zestawu pól obejmujących tożsamość, czas i postęp:
send_reminder lub daily_summary.user_id, a nie cały obiekt użytkownika).queued, running, succeeded, failed, canceled.Dodaj kilka kolumn operacyjnych, które czynią współbieżność bezpieczną i ułatwiają obsługę incydentów. locked_at, locked_by i locked_until pozwalają jednemu workerowi zająć zadanie, żeby nie uruchomić go dwa razy. last_error powinien być krótkim komunikatem (opcjonalnie kod błędu), a nie pełnym zrzutem stack trace’a, który puchnie wiersze.
Na koniec trzymaj znaczniki czasu przydatne dla wsparcia i raportowania: created_at, updated_at i finished_at. Pozwalają odpowiedzieć na pytania typu „Ile przypomnień dziś nie powiodło się?” bez grzebania w logach.
Indeksy mają znaczenie, bo system ciągle pyta „co jest następne?”. Dwa, które zwykle się opłacają:
(status, run_at) do szybkiego pobierania należnych zadań(type, status) by inspekcja lub wstrzymanie jednej rodziny zadań była szybkaDla payloadów preferuj mały, skoncentrowany JSON i waliduj go przed wstawieniem zadania. Przechowuj identyfikatory i parametry, a nie snapshoty danych biznesowych. Traktuj kształt payloadu jak kontrakt API, żeby starsze w kolejce zadania nadal działały po zmianie aplikacji.
Runner zadań pozostaje niezawodny, gdy każde zadanie podąża za małą, przewidywalną ścieżką życia. Ten cykl życia jest siecią bezpieczeństwa, gdy dwóch workerów startuje jednocześnie, serwer restartuje się w trakcie zadania lub trzeba powtórzyć bez tworzenia duplikatów.
Prosty automat stanów zwykle wystarcza:
run_atAby zapobiec duplikatom, rezerwacja zadania musi być atomowa. Powszechne podejście to blokada z limitem czasu (leasing): worker rezerwuje zadanie ustawiając status=running i zapisując locked_by oraz locked_until. Jeśli worker padnie, blokada wygasa i inny worker może ją odzyskać.
Praktyczny zestaw zasad rezerwacji:
queued których run_at <= nowstatus, locked_by i locked_until w tej samej aktualizacjirunning tylko gdy locked_until < nowIdempotencja oznacza: jeśli to samo zadanie wykona się dwa razy, wynik wciąż będzie poprawny.
Najprostsze narzędzie to klucz unikalny. Na przykład dla codziennego podsumowania możesz wymusić jedno zadanie na użytkownika na dzień z kluczem summary:user123:2026-01-25. Jeśli wystąpi duplikat wstawienia, wskazuje on na to samo zadanie zamiast tworzyć drugie.
Oznacz sukces tylko wtedy, gdy efekt uboczny jest naprawdę zakończony (e-mail wysłany, rekord zaktualizowany). Jeśli powtarzasz próbę, ścieżka retry nie powinna tworzyć drugiego e-maila ani duplikować zapisu.
Ponawiania to punkt, w którym systemy zadań albo stają się niezawodne, albo zamieniają się w hałas. Cel jest prosty: powtarzać, gdy błąd jest prawdopodobnie tymczasowy; zatrzymać, gdy nie jest.
Domyślna polityka retry zwykle zawiera:
Zamiast wymyślać nowy status dla ponowień, często możesz użyć queued: ustaw run_at na czas następnej próby i włóż zadanie z powrotem do kolejki. To utrzymuje automat stanów małym.
Gdy zadanie może robić postęp częściowy, traktuj to jako normalne. Zapisz checkpoint, aby retry mógł bezpiecznie kontynuować, albo w payloadzie zadania (np. last_processed_id), albo w powiązanej tabeli.
Przykład: zadanie codziennego podsumowania generuje wiadomości dla 500 użytkowników. Jeśli zawiedzie przy użytkowniku 320, zapisz ostatni poprawnie przetworzony identyfikator i spróbuj od 321. Jeśli dodatkowo zapisujesz rekord summary_sent dla każdego użytkownika na dzień, ponowne uruchomienie może pominąć użytkowników już obsłużonych.
Loguj tyle, by debugować w minutach:
Pętla schedulera to mały proces, który budzi się w stałym rytmie, sprawdza należne zadania i przekazuje je dalej. Celem jest nudna niezawodność, nie perfekcyjna precyzja. W wielu aplikacjach „budź się co minutę” wystarcza.
Wybierz częstotliwość budzenia na podstawie tego, jak wrażliwe na czas są zadania i jak duże obciążenie może przyjąć baza danych. Jeśli przypomnienia muszą być niemal w czasie rzeczywistym, uruchamiaj co 30–60 sekund. Jeśli codzienne podsumowania mogą się przesunąć, co 5 minut jest w porządku i tańsze.
Prosta pętla:
status = 'queued' i run_at <= now.Krok rezerwacji to miejsce, gdzie wiele systemów się łamie. Chcesz oznaczyć zadanie jako running (i zapisać locked_by oraz locked_until) w tej samej transakcji, co jego wybór. Wiele baz wspiera odczyty z "skip locked", więc kilku schedulerów może działać bez wchodzenia sobie w drogę.
-- concept example
BEGIN;
SELECT id FROM jobs
WHERE status='queued' AND run_at <= NOW()
ORDER BY run_at
LIMIT 100
FOR UPDATE SKIP LOCKED;
UPDATE jobs
SET status='running', locked_until=NOW() + INTERVAL '5 minutes'
WHERE id IN (...);
COMMIT;
Trzymaj rozmiar partii mały (np. 50–200). Większe partie mogą spowolnić bazę i uczynić awarie bardziej bolesnymi.
Jeśli scheduler padnie w połowie partii, leasing cię uratuje. Zadania zablokowane jako running staną się znowu kwalifikowalne po locked_until. Twój worker powinien być idempotentny, aby odzyskane zadanie nie generowało ponownych e-maili czy podwójnych opłat.
Większość zespołów ma te same trzy rodzaje pracy w tle: wiadomości, które muszą wyjść na czas, raporty uruchamiane według harmonogramu i porządki, które utrzymują wydajność i miejsce. Ta sama tabela zadań i pętla workerów poradzą sobie ze wszystkimi.
Dla przypomnień przechowuj wszystko, co potrzebne do wysłania wiadomości, w wierszu zadania: odbiorca, kanał (email, SMS, Telegram, in-app), szablon i dokładny czas wysyłki. Worker powinien być w stanie wykonać zadanie bez „szukania” dodatkowego kontekstu.
Jeśli wiele przypomnień jest należnych jednocześnie, dodaj limitowanie przepływu. Ogranicz wiadomości na minutę na kanał i pozwól nadmiarowi poczekać na następne uruchomienie.
Codzienne podsumowania zawodzą, gdy okno czasowe jest nieostre. Wybierz jedno stabilne cutoff (np. 08:00 w lokalnym czasie użytkownika) i zdefiniuj okno jasno (np. „wczoraj 08:00 do dziś 08:00”). Przechowuj cutoff i strefę czasową użytkownika w zadaniu, aby ponowne uruchomienia dawały ten sam wynik.
Trzymaj każde zadanie podsumowania małe. Jeśli musi przetworzyć tysiące rekordów, podziel je na fragmenty (po zespole, koncie lub zakresie ID) i dodaj kolejne zadania.
Porządki są bezpieczniejsze, gdy oddzielisz „usunąć” od „zarchiwizować”. Zdecyduj, co można usunąć na zawsze (tymczasowe tokeny, wygasłe sesje), a co archiwizować (logi audytu, faktury). Uruchamiaj porządki w przewidywalnych partiach, aby uniknąć długich blokad i nagłych skoków obciążenia.
Wiele awarii to błędy czasowe: przypomnienie wychodzi o godzinę za wcześnie, codzienne podsumowanie pomija poniedziałek, albo porządki uruchamiają się dwa razy.
Dobrym domyślnym podejściem jest przechowywać znaczniki czasu harmonogramu w UTC i przechowywać strefę czasową użytkownika osobno. run_at powinien być jedną chwilą w UTC. Gdy użytkownik mówi „9:00 mojego czasu”, konwertuj to na UTC przy harmonogramowaniu.
Czas letni to miejsce, gdzie naiwny setup się łamie. „Codziennie o 9:00” nie jest tym samym co „co 24 godziny”. Przy zmianach DST 9:00 lokalnie mapuje się na inną chwilę UTC, a niektóre lokalne czasy nie istnieją (przy przestawianiu do przodu) lub zdarzają się dwa razy (przy cofaniu). Bezpieczniejsze podejście to za każdym razem obliczyć kolejne lokalne wystąpienie, a potem ponownie przekonwertować na UTC.
Dla codziennego podsumowania zdecyduj, co oznacza „dzień” zanim napiszesz kod. Dzień kalendarzowy (od północy do północy w strefie czasowej użytkownika) pasuje do oczekiwań ludzi. „Ostatnie 24 godziny” jest prostsze, ale dryfuje i zaskakuje.
Dane spóźnione są nieuniknione: zdarzenie przychodzi po retry, albo notatka dodana kilka minut po północy. Zdecyduj, czy spóźnione zdarzenia należą do „wczoraj” (z okresem karencji) czy „dziś” i trzymaj tę zasadę konsekwentnie.
Praktyczny bufor może zapobiec pominięciom:
Większość bólu wynika z kilku przewidywalnych założeń.
Największym jest założenie „dokładnie raz”. W realnych systemach workery restartują się, połączenia sieciowe timeoutują, a blokady mogą zostać utracone. Zwykle masz dostawę „co najmniej raz”, co oznacza, że duplikaty są normalne i kod musi sobie z nimi radzić.
Inny błąd to robienie efektów najpierw (wysyłka e-maila, obciążenie karty) bez sprawdzenia deduplikacji. Prosta zapora często rozwiązuje problem: sent_at timestamp, unikalny klucz jak (user_id, reminder_type, date) lub zapisany token deduplikacyjny.
Widoczność to kolejna luka. Jeśli nie możesz odpowiedzieć „co się zacięło, od kiedy i dlaczego”, skończysz zgadywać. Minimum danych do trzymania blisko to status, liczba prób, następny zaplanowany czas, ostatni błąd i id workera.
Najczęstsze błędy:
Konkretne przykłady: zadanie codziennego podsumowania iteruje po 50 000 użytkowników i wyłącza się przy 20 000. Przy retry zaczyna od początku i ponownie wysyła podsumowania pierwszym 20 000, chyba że śledzisz ukończenie per-user lub dzielisz zadanie na zadania per-user.
Runner zadań jest „gotowy” dopiero wtedy, gdy możesz mu zaufać o 2 w nocy.
Upewnij się, że masz:
run_at w UTC; konwertuj tylko przy wejściu i przy wyświetlaniu.Ogranicz też rozmiar partii (ile zadań rezerwujesz naraz) i konkurencję workerów (ile uruchamia się jednocześnie). Bez limitów jeden skok obciążenia może zalać bazę lub zablokować inne prace.
Niewielkie narzędzie SaaS ma 30 kont klientów. Każde konto chce dwóch rzeczy: przypomnienie o 9:00 dla otwartych zadań i codzienne podsumowanie o 18:00 tego, co się zmieniło dziś. Potrzebują też cotygodniowego porządku, aby baza nie zapełniała się starymi logami i wygasłymi tokenami.
Używają tabeli zadań i workera, który polluje należne zadania. Gdy nowy klient się rejestruje, backend planuje pierwsze przypomnienia i podsumowania zgodnie ze strefą czasową klienta.
Zadania tworzone są w kilku typowych momentach: przy rejestracji (tworzenie harmonogramów cyklicznych), przy pewnych zdarzeniach (enqueue jednorazowych powiadomień), przy cyklicznym ticku schedulera (wstawianie nadchodzących uruchomień) i przy konserwacji (enqueue porządków).
Pewnego wtorku dostawca e-maili ma tymczasową awarię o 8:59. Worker próbuje wysłać przypomnienia, dostaje timeout i przepisuje te zadania ustawiając run_at według backoffu (np. 2 minuty, potem 10, potem 30), inkrementując attempts przy każdej próbie. Ponieważ każde zadanie przypomnienia ma klucz idempotencyjny jak account_id + date + job_type, ponowienia nie generują duplikatów, jeśli dostawca odzyska sprawność w trakcie.
Porządki uruchamiają się co tydzień w małych partiach, więc nie blokują innych prac. Zamiast usuwać milion wierszy w jednym zadaniu, usuwają do N wierszy na uruchomienie i planują się ponownie, aż skończą.
Kiedy klient skarży się „nie dostałem podsumowania”, zespół sprawdza tabelę zadań dla tego konta i dnia: status zadania, liczbę prób, pola blokady i ostatni błąd zwrócony przez dostawcę. To zamienia „powinno było wysłać” w „oto dokładnie, co się stało”.
Wybierz jeden typ zadania i zbuduj go end-to-end, zanim dodasz kolejne. Jedno zadanie przypomnienia to dobry start, bo dotyka wszystkiego: harmonogramowania, rezerwacji należnej pracy, wysyłki wiadomości i zapisu wyników.
Zacznij od wersji, której możesz zaufać:
Gdy to działa, uczyn to obserwowalnym dla ludzi. Nawet proste narzędzie administracyjne szybko się zwraca: wyszukuj zadania po statusie, filtruj po czasie, przeglądaj payload, anuluj zacięte zadanie, ponownie uruchom konkretne id zadania.
Jeśli wolisz budować taki flow schedulera i workerów przy pomocy wizualnej logiki backendu, AppMaster (appmaster.io) może zamodelować tabelę zadań w PostgreSQL i zaimplementować pętlę claim-process-update jako Proces Biznesowy, jednocześnie generując rzeczywisty kod źródłowy do wdrożenia.
21 sty 2026
8 min
20 sty 20268 min
20 sty 20268 minEksperymentuj z AppMaster z darmowym planem.
Kiedy będziesz gotowy, możesz wybrać odpowiednią subskrypcję.
