Kako zagnati opravila v ozadju v spletni aplikaciji: čakalne vrste, načrtovalci in cron

Za zagon opravil v ozadju v spletni aplikaciji najprej delo razdelite na dve vrsti. Sprožena opravila (pošlji dobrodošlo e-pošto, obdelaj nalaganje) lahko shranite v čakalno vrsto opravil, pogosto tabelo v vaši bazi, nalogo pa obdela delavec s ponovitvami. Načrtovana opravila (nočno poročilo, opomniki vsakih 15 minut) potrebujejo nekaj, kar se sproži po urniku: funkcijo cron pri gostitelju ali zunanji načrtovalec, ki kliče zaščiteno končno točko v vaši aplikaciji. Opravila vedno naredite varna za dvakratni zagon, napake beležite in se nikoli ne zanašajte na časovnik v strežniku, ki lahko spi ali se ponovno zažene.

Ta vodnik pojasni možnosti, kdaj je vsaka primerna in kako jih nastaviti z AI graditeljem aplikacij, tudi pri gostiteljih, ki se skrčijo na nič.

Kaj šteje za opravilo v ozadju

Karkoli, kar je počasno, nezanesljivo ali ni potrebno za takojšnji odgovor uporabniku:

• Pošiljanje e-pošte, obvestil in računov
• Spreminjanje velikosti slik, pretvarjanje videa, ustvarjanje PDF-jev
• Klicanje počasnih zunanjih API-jev, vključno z modeli umetne inteligence za dolge naloge
• Uvoz ali sinhronizacija podatkov iz drugega sistema
• Nočno čiščenje, poročila in opomniki

Če to delate znotraj zahteve, strani postanejo počasne in krhke: če ponudnik e-pošte ne deluje, registracija uporabnika spodleti. Če premaknete v ozadje, uporabnik dobi takojšen odgovor, opravilo pa je mogoče ponoviti.

Možnosti

Ni ene same prave odgovore. Majhna aplikacija pogosto potrebuje samo čakalno vrsto v bazi in zunanji načrtovalec.

Zakaj gostitelji, ki se skrčijo na nič, spremenijo sliko

Mnogi sodobni gostitelji uspavajo vašo aplikacijo, ko je nihče ne uporablja, in jo zbudijo ob naslednji zahtevi. To prihrani denar, a speči strežnik ne izvaja kode: časovniki se ne sprožijo in delavci ne preverjajo. Pri teh gostiteljih se mora načrtovano delo začeti z dohodno zahtevo, najlažji vir takšne zahteve pa je zunanji načrtovalec. Vsak klic zbudi aplikacijo (pogosto tudi bazo), zato klicanje vsako minuto stane več kot vsakih 15 minut. Izberite najpočasnejši urnik, ki zadosti potrebi.

Vzorec 1: čakalna vrsta opravil v bazi

Za sprožena opravila:

1. Ustvarite tabelo jobs: vrsta, podatki (JSON), stanje (pending, running, done, failed), število poskusov, run_after, last_error, časovni žigi.
2. Ko se nekaj zgodi, vstavite vrstico opravila v isto transakcijo kot sprememba, ki jo je povzročila, da uspeta ali spodletita skupaj.
3. Delavec prevzame opravila, ki so na vrsti, jih označi kot running, opravi delo in označi kot done.
4. Ob napaki povečajte attempts, nastavite run_after kasneje (na primer 1, 5, nato 30 minut) in shranite napako. Po največjem številu poskusov označite kot failed in obvestite nekoga.

Če lahko hkrati teče več delavcev, je treba opravila varno prevzeti. Na Postgresu SELECT ... FOR UPDATE SKIP LOCKED omogoča, da vsak delavec prevzame različne vrstice, ne da bi se prekrivali.

Kaj zažene delavca? Na strežniku, ki vedno teče, zanka v ločenem procesu. Na gostitelju, ki se skrči na nič, lahko načrtovana končna točka iz vzorca 2 ob vsakem klicu obdela paket opravil, ki so na vrsti.

Vzorec 2: zunanji načrtovalec kliče vašo aplikacijo

Za načrtovana opravila:

1. Dodajte končno točko, na primer POST /api/cron/send-reminders.
2. Zaščitite jo: zahtevajte skrivni žeton v glavi, shranjen kot skrivnost na obeh straneh, vse ostalo zavrnite.
3. Naredite jo idempotentno: če se zažene dvakrat v isti minuti, ne sme poslati dveh opomnikov. Beležite, kaj je bilo poslano.
4. Naj bo vsak klic kratek: obdelajte paket (recimo 100 elementov) in naj naslednji klic obdela preostale.
5. Usmerite načrtovalec nanjo.

Izbira načrtovalca:

• Načrtovani poteki dela GitHub Actions. Brezplačno v okviru omejitev uporabe GitHuba. Od septembra 2026 dokumentacija GitHuba navaja, da je najkrajši interval enkrat na 5 minut, zagoni se lahko zamudijo v času velike obremenitve (zlasti na začetku vsake ure), urniki privzeto uporabljajo UTC, načrtovani poteki dela v javnem repozitoriju pa se po 60 dneh brez aktivnosti v repozitoriju izklopijo.
• Storitve cron v oblaku. Obstaja veliko storitev, katerih edina naloga je po urniku klicati URL. Preden se na katero zanesete, preverite zanesljivost, najkrajši interval in obveščanje.
• Načrtovalec vašega ponudnika oblaka. Če že uporabljate velikega ponudnika oblaka, ima upravljani načrtovalec, ki lahko kliče končno točko HTTPS.
• Gostujoča storitev za opravila ali poteke dela. Te združujejo načrtovanje, čakalne vrste in ponovitve ter za vsak korak kličejo vaše končne točke. Primerjajte cene in omejitve na spletnih straneh posameznega ponudnika.

Vzorec 3: naj opravi ponudnik

Včasih najboljše opravilo v ozadju sploh ni potrebno:

• Plačila. Stripe ponovno poskuša neuspešna plačila naročnin in pošilja webhooke; vi se odzovete, namesto da anketirate. Glejte kaj je webhook.
• E-pošta. Ponudniki dajo sporočila v čakalno vrsto in ponovijo dostavo, ko jim enkrat predate sporočilo.
• Množično delo z umetno inteligenco. OpenAI in Anthropic ponujata paketne API-je za nenujne zahteve, ki jih oddate in pozneje prevzamete.

Pozivi za vaš AI graditelj

Za čakalno vrsto:

Dodaj čakalno vrsto opravil z uporabo tabele jobs v naši bazi (vrsta, podatki JSON, stanje, število poskusov, run_after, last_error). Ko se uporabnik registrira, v isti transakciji vstavi opravilo send_welcome_email namesto pošiljanja v vrsti. Dodaj funkcijo processJobs(limit), ki prevzame opravila, ki so na vrsti, z uporabo SELECT ... FOR UPDATE SKIP LOCKED, jih zažene in ponovi napake po 1, 5 in 30 minutah, ter jih po 4 poskusih označi kot failed.

Za sprožilec po urniku:

Dodaj POST /api/cron/tick, zaščiten z žetonom bearer iz skrivnosti CRON_SECRET; zavrni vsako zahtevo brez njega. Vsak klic naj zažene processJobs(100) in pošlje opomnike o rezervacijah, ki so načrtovani v naslednjih 24 urah in še niso bili poslani, ter beleži poslane opomnike, da se nič ne pošlje dvakrat. Vrni povzetek v JSON o tem, kaj se je zagnalo. Nato napiši delovni tok GitHub Actions, ki to končno točko kliče vsakih 15 minut, URL in žeton pa bere iz skrivnosti repozitorija.

Pogoste napake

• Zanašanje na setInterval. Tiho se ustavi, ko strežnik spi ali se ponovno zažene, in se podvoji, ko tečeta dve kopiji.
• Nezaščitena končna točka cron. Vsak, ki jo najde, lahko sproži vaša opravila ali vaš račun za e-pošto.
• Opravila, ki niso idempotentna. Ponovitve in podvojeni klici načrtovalca se bodo zgodili. Zasnujte jih za to.
• Brez vidnosti napak. Opravilo, ki teden dni tiho ne uspe, je slabše kot tisto, ki glasno ne uspe. Beležite napake in opozarjajte ob ponavljajočih se napakah.
• Dolgi zagoni v eni zahtevi. Zahteve potečejo. Obdelujte v paketih.
• Prepogosto načrtovanje. Vsak klic na gostitelju, ki se skrči na nič, zbudi in obremeni aplikacijo. Interval uskladite s pravo potrebo.
• Časovni pasovi. »9.00« pomeni različne stvari za vaš načrtovalec (pogosto UTC) in za uporabnike. Čase shranjujte v UTC in jih pretvarjajte za vsakega uporabnika.
• Skrivnosti v datoteki delovnega toka. Žetone hranite v skrivnostnem skladišču načrtovalca. Glejte kako varno hraniti ključe API.

Kontrolni seznam

• Počasno delo premaknjeno iz zahtev uporabnikov
• Opravila shranjena trajno, ne samo v pomnilniku
• Ponovitve s povečujočimi se zamudami in največjim številom
• Vsako opravilo je varno za dvakratni zagon
• Načrtovana končna točka zaščitena s skrivnim žetonom
• Vsak zagon obdela omejen paket
• Neuspela opravila vidna, z opozorili
• Interval načrtovanja izbran ob upoštevanju stroškov gostovanja
• Časi shranjeni v UTC

Opravila v ozadju v Mythexu

Dokumentacija Mythexa ne opisuje načrtovanih ali cron opravil, objavljene aplikacije in njihove baze pa spijo, ko so neaktivne, in se zbudijo ob naslednji zahtevi (glejte Omejitve gostovanja). Zato se ne zanašajte na časovnike v svoji aplikaciji. Deluje pristop, opisan zgoraj: agenta prosite za tabelo opravil in končno točko, zaščiteno z žetonom, nato pa zunanjemu načrtovalcu usmerite svoj objavljeni URL. Žeton shranite kot skrivnost projekta in ne pozabite, da vsako zbujanje porabi kredite za čas, ko sta aplikacija in baza budni, zato izberite smiseln interval. Če vaša aplikacija za to potrebuje API zaledje, je recept za REST API zaledje izhodišče, kako zgraditi REST API pa pokrije zasnovo končnih točk. Če so jedro vašega izdelka stalni delavci ali roboti, vam bo morda bolj ustrezal gostitelj, zgrajen za trajne procese.

Vprašanja