Kako pokretati pozadinske poslove u web aplikaciji: redovi, planeri i cron

Da biste pokretali pozadinske poslove u web aplikaciji, prvo podijelite posao u dvije vrste. Pokrenuti poslovi (pošalji dobrodošlu e-poštu, obradi učitavanje) mogu se spremiti u red poslova, često kao tablicu u vašoj bazi podataka, i obraditi ih radnik s ponovnim pokušajima. Zakazani poslovi (nočno izvješće, podsjetnici svakih 15 minuta) trebaju nešto što se aktivira po rasporedu: cron značajku hosta ili vanjski planer koji poziva zaštićenu krajnju točku u vašoj aplikaciji. Uvijek osigurajte da se poslovi mogu sigurno izvršiti dvaput, zabilježite greške i nikad se ne oslanjajte na tajmer unutar poslužitelja koji može spavati ili se ponovno pokrenuti.

Ovaj vodič objašnjava mogućnosti, kada koja odgovara i kako ih postaviti s AI graditeljem aplikacija, uključujući hostove koji se skaliraju na nulu.

Što se smatra pozadinskim poslom

Svaki rad koji je spor, nepouzdan ili nije potreban za trenutni odgovor korisniku:

• Slanje e-pošte, obavijesti i računa
• Promjena veličine slika, transkodiranje videa, generiranje PDF-ova
• Pozivanje sporih API-ja trećih strana, uključujući AI modele za duge zadatke
• Uvoz ili sinkronizacija podataka iz drugog sustava
• Nočno čišćenje, izvješća i podsjetnici

Ako se to radi unutar zahtjeva, stranice postaju spore i krhke: ako je davatelj e-pošte nedostupan, registracija korisnika ne uspijeva. Prebacivanje u pozadinu znači da korisnik dobiva trenutni odgovor, a posao se može ponovno pokrenuti.

Mogućnosti

Nema jednog ispravnog odgovora. Mala aplikacija često treba samo red u bazi podataka i vanjski planer.

Zašto hostovi koji se skaliraju na nulu mijenjaju sliku

Mnogi moderni hostovi uspavaju vašu aplikaciju kad je nitko ne koristi i bude je pri sljedećem zahtjevu. To štedi novac, ali spavajući poslužitelj ne izvršava kod: tajmeri ne okidaju, a radnici ne provjeravaju red. Na tim hostovima zakazani rad mora početi dolaznim zahtjevom, a najlakši izvor tog zahtjeva je vanjski planer. Svaki poziv budi aplikaciju (i često njezinu bazu), pa poziv svake minute košta više nego svakih 15 minuta. Odaberite najrjeđi raspored koji zadovoljava potrebu.

Obrazac 1: red poslova u bazi podataka

Za pokrenute poslove:

1. Izradite tablicu jobs: vrsta, teret (JSON), status (pending, running, done, failed), pokušaji, run_after, last_error, vremenske oznake.
2. Kad se nešto dogodi, umetnite redak posla u istoj transakciji kao i promjena koja ga je izazvala, tako da uspiju ili padnu zajedno.
3. Radnik preuzima poslove koji su na redu, označava ih kao running, obavlja rad i označava ih kao done.
4. Pri neuspjehu povećajte attempts, postavite run_after kasnije (na primjer 1, 5, zatim 30 minuta) i spremite grešku. Nakon najvećeg broja pokušaja označite posao kao failed i obavijestite nekoga.

Ako može raditi više radnika istovremeno, poslovi se moraju sigurno preuzimati. Na Postgresu, SELECT ... FOR UPDATE SKIP LOCKED omogućuje svakom radniku da preuzme različite retke bez sukoba.

Što pokreće radnika? Na poslužitelju koji je uvijek uključen, petlja u zasebnom procesu. Na hostu koji se skalira na nulu, zakazana krajnja točka iz Obrasca 2 može obraditi skupinu poslova na koji je red pri svakom pozivu.

Obrazac 2: vanjski planer koji poziva vašu aplikaciju

Za zakazane poslove:

1. Dodajte krajnju točku, poput POST /api/cron/send-reminders.
2. Zaštitite je: zahtijevajte tajni token u zaglavlju, spremljen kao tajna na obje strane, i odbijte sve drugo.
3. Učinite je idempotentnom: pokretanje dvaput u istoj minuti ne smije poslati dva podsjetnika. Zabilježite što je poslano.
4. Neka svaki poziv bude kratak: obradite skupinu (recimo 100 stavki) i neka sljedeći poziv preuzme ostatak.
5. Usmjerite planer na nju.

Izbor planera:

• Zakazani workflowi na GitHub Actionsu. Besplatni unutar GitHubovih ograničenja korištenja. Prema GitHubovoj dokumentaciji od rujna 2026., najkraći interval je jednom svakih 5 minuta, pokretanja se mogu odgoditi u vrijeme velikog opterećenja (osobito na početku svakog sata), rasporedi koriste UTC prema zadanom, a zakazani workflowi u javnom repozitoriju onemogućuju se nakon 60 dana bez aktivnosti u repozitoriju.
• Hostirane cron usluge. Postoji mnogo usluga čija je jedina zadaća pozivanje URL-a po rasporedu. Provjerite pouzdanost, najkraći interval i upozorenja prije nego što se oslonite na jednu.
• Planer vašeg cloud davatelja. Ako već koristite veliki cloud, imat će upravljani planer koji može pozvati HTTPS krajnju točku.
• Hostirana usluga za poslove ili tijekove. Kombiniraju zakazivanje, redove i ponovne pokušaje te pozivaju vaše krajnje točke za svaki korak. Usporedite cijene i ograničenja na stranici svakog dobavljača.

Obrazac 3: prepustite to davatelju

Ponekad najbolji pozadinski posao uopće nije potreban:

• Plaćanja. Stripe ponovno pokušava neuspjela plaćanja pretplate i šalje webhookove; vi reagirate umjesto da anketirate. Pogledajte što je webhook.
• E-pošta. Davatelji stavljaju isporuku u red i ponovno je pokušavaju kad im predate poruku.
• Veliki AI poslovi. OpenAI i Anthropic nude batch API-je za nehitne zahtjeve koje šaljete i preuzimate kasnije.

Upute za vašeg AI graditelja

Za red:

Dodaj red za pozadinske poslove koristeći tablicu jobs u našoj bazi (vrsta, JSON teret, status, pokušaji, run_after, last_error). Kad se korisnik registrira, umetni posao send_welcome_email u istoj transakciji umjesto da šalješ inline. Dodaj funkciju processJobs(limit) koja preuzima poslove na redu s SELECT ... FOR UPDATE SKIP LOCKED, izvršava ih i ponovno pokušava neuspjele nakon 1, 5 i 30 minuta, označavajući ih kao failed nakon 4 pokušaja.

Za zakazani okidač:

Dodaj POST /api/cron/tick zaštićen bearer tokenom iz tajne CRON_SECRET; odbij svaki zahtjev bez njega. Svaki poziv izvršava processJobs(100) i šalje podsjetnike na rezervacije koji dospijevaju u sljedećih 24 sata, a još nisu poslani, bilježeći poslane podsjetnike kako ništa ne bi bilo poslano dvaput. Vrati JSON sažetak onoga što je izvršeno. Zatim napiši GitHub Actions workflow koji poziva ovu krajnju točku svakih 15 minuta, čitajući URL i token iz tajni repozitorija.

Česte pogreške

• Oslanjanje na setInterval. Tiho prestaje kad se poslužitelj uspava ili ponovno pokrene, a udvostručuje se kad rade dvije kopije.
• Nezaštićena cron krajnja točka. Svatko tko je pronađe može pokrenuti vaše poslove ili vaš račun za e-poštu.
• Poslovi koji nisu idempotentni. Ponovni pokušaji i dupli pozivi planera će se dogoditi. Dizajnirajte za to.
• Nema vidljivosti grešaka. Posao koji tiho ne uspijeva tjedan dana gori je od onoga koji glasno padne. Bilježite greške i upozoravajte na ponavljajuće neuspjehe.
• Dugi radovi unutar jednog zahtjeva. Zahtjevi istječu. Obrađujte u skupinama.
• Prečesto zakazivanje. Svaki poziv na hostu koji se skalira na nulu budi aplikaciju i naplaćuje je. Uskladite interval s pravom potrebom.
• Vremenske zone. „9 ujutro” znači različite stvari vašem planeru (često UTC) i vašim korisnicima. Spremajte vremena u UTC i pretvarajte ih za svakog korisnika.
• Tajne u datoteci workflowa. Držite tokene u spremištu tajni planera. Pogledajte kako čuvati API ključeve na sigurnom.

Popis za provjeru

• Spori rad premješten iz zahtjeva korisnika
• Poslovi pohranjeni trajno, ne samo u memoriji
• Ponovni pokušaji s rastućim kašnjenjima i najvećim brojem pokušaja
• Svaki posao siguran za dvostruko izvršavanje
• Zakazana krajnja točka zaštićena tajnim tokenom
• Svako pokretanje obrađuje ograničenu skupinu
• Neuspjeli poslovi su vidljivi, uz upozorenja
• Interval rasporeda odabran uz trošak hostinga na umu
• Vremena spremljena u UTC

Pozadinski poslovi na Mythexu

Mythexova dokumentacija ne opisuje zakazane ili cron poslove, a objavljene aplikacije i njihove baze spavaju kad su neaktivne i bude se pri sljedećem zahtjevu (pogledajte Ograničenja hostinga). Zato se nemojte oslanjati na tajmere unutar aplikacije. Pristup koji radi je onaj gore: od agenta zatražite tablicu poslova i krajnju točku zaštićenu tokenom, zatim usmjerite vanjski planer na vaš objavljeni URL. Token spremite kao tajnu projekta i zapamtite da svako buđenje troši kredite za vrijeme dok su aplikacija i baza budne, pa odaberite razuman interval. Ako vaša aplikacija za to treba API pozadinu, recept za REST API pozadinu je polazna točka, a kako izraditi REST API objašnjava dizajn krajnjih točaka. Ako su pozadinski radnici ili botovi srž vašeg proizvoda, host namijenjen trajnim procesima može bolje odgovarati.

Pitanja