Kuidas käivitada taustatöid veebirakenduses: järjekorrad, ajastajad ja cron

Taustatööde käivitamiseks veebirakenduses jaga töö kõigepealt kaheks liigiks. Käivitatavad tööd (tervitus-e-kirja saatmine, üleslaaditud faili töötlemine) saab salvestada töö järjekorda, sageli sinu andmebaasi tabelisse, ja neid käsitleb töötaja kordusproovidega. Ajastatud tööd (öine aruanne, meeldetuletused iga 15 minuti tagant) vajavad midagi, mis käivitub ajagraafiku järgi: hosti cron-funktsioon või väline ajastaja, mis kutsub sinu rakenduses kaitstud lõpp-punkti. Tee tööd alati turvaliseks kahekordseks käivitamiseks, salvesta vead ja ära looda taimerile serveris, mis võib magada või taaskäivituda.

See juhend selgitab valikuid, millal iga sobib, ja kuidas neid seadistada AI rakenduste ehitajaga, sealhulgas hostidel, mis skaleeruvad nullini.

Mis loetakse taustatööks

Kõik, mis on aeglane, ebausaldusväärne või pole kasutaja kohese vastuse jaoks vajalik:

• E-kirjade, teavituste ja kviitungite saatmine
• Piltide suuruse muutmine, videote kodeerimine, PDF-ide genereerimine
• Aeglaste kolmandate osapoolte API-de kutsumine, sealhulgas AI-mudelid pikkade ülesannete jaoks
• Andmete importimine või sünkroniseerimine teisest süsteemist
• Öised koristustööd, aruanded ja meeldetuletused

Kui seda teha päringu sees, muutuvad lehed aeglaseks ja hapraks: kui e-posti teenusepakkuja on maas, ebaõnnestub kasutaja registreerimine. Taustale viimine tähendab, et kasutaja saab kohese vastuse ja tööd saab uuesti proovida.

Valikud

Ühtegi õiget vastust ei ole. Väike rakendus vajab sageli ainult andmebaasi järjekorda ja välist ajastajat.

Miks nullini skaleeruvad hostid asja muudavad

Paljud kaasaegsed hostid panevad sinu rakenduse magama, kui keegi seda ei kasuta, ja ärkavad järgmise päringu peale. See säästab raha, kuid magav server ei käivita koodi: taimerid ei käivitu ja töötajad ei küsi järjekorda. Nendel hostidel peab ajastatud töö algama sissetulevast päringust, ja kõige lihtsam päringuallikas on väline ajastaja. Iga kutse ärkab rakenduse (ja sageli selle andmebaasi), seega iga minuti tagant kutsumine maksab rohkem kui iga 15 minuti tagant. Vali kõige aeglasem ajagraafik, mis vajadust rahuldab.

Muster 1: andmebaasi töö järjekord

Käivitatavate tööde jaoks:

1. Loo tabel jobs: tüüp, andmed (JSON), staatus (pending, running, done, failed), katsete arv, run_after, last_error, ajatemplid.
2. Kui midagi juhtub, lisa töö rida samas tehingus muudatusega, mis selle põhjustas, nii et need õnnestuvad või ebaõnnestuvad koos.
3. Töötaja võtab tähtajalised tööd, märgib need running, teeb töö ja märgib need done.
4. Ebaõnnestumise korral suurenda attempts, sea run_after hiljemaks (näiteks 1, 5, siis 30 minutit) ja salvesta viga. Pärast maksimumi märgi see failed ja teavita kedagi.

Kui töötajaid võib mitu korraga töötada, peab tööde võtmine olema ohutu. Postgres'is võimaldab SELECT ... FOR UPDATE SKIP LOCKED, et iga töötaja võtaks erinevad read ilma konfliktita.

Mis käivitab töötaja? Alati sees oleval serveril on eraldi protsessis tsükkel. Nullini skaleeruval hostil saab Muster 2 ajastatud lõpp-punkt igal kutsel töödelda partii tähtajalisi töid.

Muster 2: väline ajastaja, mis kutsub sinu rakendust

Ajastatud tööde jaoks:

1. Lisa lõpp-punkt, nt POST /api/cron/send-reminders.
2. Kaitse seda: nõua salajast tokenit päises, hoia seda salajasena mõlemas kohas ja lükka kõik muu tagasi.
3. Tee see idempotentseks: kahe käivitamine samas minutis ei tohi saata kahte meeldetuletust. Salvesta, mis on saadetud.
4. Hoia iga kutse lühikesena: töötle partii (näiteks 100 üksust) ja lase järgmisel kutsel ülejäänu võtta.
5. Suuna ajastaja sinna.

Ajastaja valikud:

• GitHub Actions ajastatud töövood. Tasuta GitHubi kasutuspiirangute piires. Septembris 2026 ütlevad GitHubi dokumendid, et lühim intervall on kord iga 5 minuti tagant, käivitusi võidakse viivitada tihedatel aegadel (eriti iga tunni alguses), ajagraafikud kasutavad vaikimisi UTC-d ning avalikus repositooriumis lõpetatakse ajastatud töövood pärast 60 päeva repositooriumi tegevuseta.
• Hostitud cron-teenused. On palju teenuseid, mille ainus töö on kutsuda URL ajagraafiku järgi. Enne sõltumist kontrolli usaldusväärsust, minimaalset intervalli ja teavitusi.
• Sinu pilveteenuse ajastaja. Kui kasutad suurt pilveteenuse pakkujat, on sul hallatud ajastaja, mis saab kutsuda HTTPS-lõpp-punkti.
• Hostitud töö- või töövoogude teenus. Need ühendavad ajastuse, järjekorrad ja kordused ning kutsuvad iga sammu jaoks sinu lõpp-punkte. Võrdle hindu ja piiranguid iga müüja lehel.

Muster 3: lase teenusepakkujal teha

Mõnikord ei ole parim taustatöö üldse ühtegi:

• Maksed. Stripe proovib ebaõnnestunud tellimuste makseid uuesti ja saadab webhook'e; sina reageerid, selle asemel et küsitleda. Vaata mis on webhook.
• E-post. Teenusepakkujad järjestavad ja proovivad kohaletoimetamist uuesti, kui oled sõnumi üle andnud.
• Massiline AI töö. OpenAI ja Anthropic pakuvad partii-API-sid mittekiireteks päringuteks, mille esitad ja hiljem kogud.

Viibad oma AI ehitajale

Järjekorra jaoks:

Lisa taustatööde järjekord, kasutades meie andmebaasis tabelit jobs (tüüp, JSON-andmed, staatus, attempts, run_after, last_error). Kui kasutaja registreerib, lisa samas tehingus töö send_welcome_email, selle asemel et saata kiri otse. Lisa funktsioon processJobs(limit), mis võtab tähtajalised tööd SELECT ... FOR UPDATE SKIP LOCKED abil, käivitab need ja proovib ebaõnnestumisi uuesti 1, 5 ja 30 minuti pärast, märkides need failed pärast 4 katset.

Ajastatud käivitaja jaoks:

Lisa POST /api/cron/tick, mida kaitseb bearer-token salajasest CRON_SECRET; lükka tagasi iga päring ilma selleta. Iga kutse käivitab processJobs(100) ja saadab broneeringu meeldetuletused, mis on tähtajalised järgmise 24 tunni jooksul ja mida pole veel saadetud, salvestades saadetud meeldetuletused, et midagi ei saadetaks kaks korda. Tagasta JSON-kokkuvõte sellest, mis käivitus. Seejärel kirjuta GitHub Actions töövoog, mis kutsub seda lõpp-punkti iga 15 minuti tagant, lugedes URL-i ja tokenit repositooriumi saladustest.

Levinud vead

• Luottamine setInterval'ile. See peatub vaikselt, kui server magab või taaskäivitub, ja dubleerub, kui töötab kaks koopiat.
• Kaitsmata cron-lõpp-punkt. Igaüks, kes selle leiab, saab sinu töid või sinu e-posti arvet käivitada.
• Mitteidempotentsed tööd. Kordused ja dubleeritud ajastaja kutsed juhtuvad. Projekteeri nende jaoks.
• Puudub nähtavus vigadele. Töö, mis ebaõnnestub vaikselt nädal aega, on hullem kui see, mis ebaõnnestub valjusti. Logi vead ja teavita korduvatest ebaõnnestumistest.
• Pikad käivitused ühes päringus. Päringud aeguvad. Töötle partiidena.
• Liiga sageli ajastamine. Iga kutse nullini skaleeruval hostil ärkab rakenduse ja maksab selle eest. Sobita intervall tegeliku vajadusega.
• Ajavööndid. „Kell 9” tähendab erinevat sinu ajastajale (sageli UTC) ja kasutajatele. Salvesta ajad UTC-na ja teisenda kasutajate kaupa.
• Saladused töövoo failis. Hoia tokenid ajastaja saladuste hoidlas. Vaata kuidas hoida API-võtmeid turvaliselt.

Kontrollnimekiri

• Aeglane töö on kasutaja päringutest välja viidud
• Tööd on salvestatud püsivalt, mitte ainult mälus
• Kordused kasvavate viivitustega ja maksimumiga
• Iga töö on ohutu kahekordseks käivitamiseks
• Ajastatud lõpp-punkt on kaitstud salajase tokeniga
• Iga käivitus töötleb piiratud partii
• Ebaõnnestunud tööd on nähtavad ja neist teavitatakse
• Ajagraafiku intervall on valitud arvestades hostingu kulu
• Ajad on salvestatud UTC-na

Taustatööd Mythexis

Mythexi dokumentatsioon ei kirjelda ajastatud ega cron-töid ning avaldatud rakendused ja nende andmebaasid magavad tühikäigul ning ärkavad järgmise päringu peale (vaata hostingupiirangud). Seega ära looda taimeritele rakenduse sees. Toimiv lähenemine on eespool kirjeldatu: palu agendilt tabel jobs ja tokeniga kaitstud lõpp-punkt, seejärel suuna väline ajastaja oma avaldatud URL-ile. Salvesta token projekti saladusena ja pea meeles, et iga äratus kulutab krediite selle aja eest, mil rakendus ja andmebaas on ärkvel, seega vali mõistlik intervall. Kui sinu rakendus vajab selleks API-taustsüsteemi, on REST API taustsüsteemi retsept hea algus, ja kuidas ehitada REST API selgitab lõpp-punktide disainimist. Kui su toote südameks on pidevalt töötavad töötajad või botid, võib püsivate protsesside jaoks loodud host sobida paremini.

Küsimused