Kā palaist fona darbus tīmekļa lietotnē: rindas, plānotāji un cron

Lai palaistu fona darbus tīmekļa lietotnē, vispirms sadaliet darbu divos veidos. Sāktie darbi (nosūtīt sveiciena e-pastu, apstrādāt augšupielādi) var tikt saglabāti darbu rindā, bieži vien datubāzes tabulā, un apstrādāti darbiniekā ar atkārtojumiem. Ieplānotie darbi (nakts atskaite, atgādinājumi ik pēc 15 minūtēm) prasa kaut ko, kas tiek palaists pēc grafika: hosta cron funkciju vai ārēju plānotāju, kas izsauc aizsargātu galapunktu jūsu lietotnē. Vienmēr padariet darbus drošus, lai tos var palaist divreiz, reģistrējiet kļūmes un nekad nepaļaujieties uz taimeri serverī, kas var gulēt vai restartēties.

Šis ceļvedis izskaidro iespējas, kad katra derīga un kā tās iestatīt ar AI lietotņu veidotāju, arī hostos, kas samazina darbību līdz nullei.

Kas ir fona darbs

Viss, kas ir lēns, nedrošs vai nav vajadzīgs lietotāja tūlītējai atbildei:

• E-pastu, paziņojumu un kvītu sūtīšana
• Attēlu mainīšana izmēros, video pārkodēšana, PDF veidošana
• Lēnu trešo pušu API izsaukumi, arī AI modeļi garākiem uzdevumiem
• Datu importēšana vai sinhronizēšana no citas sistēmas
• Nakts tīrīšana, atskaites un atgādinājumi

Ja to dara pieprasījuma ietvaros, lapas kļūst lēnas un trauslas: ja e-pasta pakalpojums nedarbojas, lietotāja reģistrācija neizdodas. Pārceļot to uz fonu, lietotājs saņem tūlītēju atbildi un darbu var atkārtot.

Iespējas

Nav vienas pareizās atbildes. Mazai lietotnei bieži pietiek ar datubāzes darbu rindu un ārēju plānotāju.

Kāpēc hosti, kas samazina darbību līdz nullei, maina ainu

Daudzi mūsdienu hosti liek jūsu lietotnei gulēt, kad to neviens neizmanto, un pamodina to nākamajā pieprasījumā. Tas ietaupa naudu, bet guļošs serveris nepalaiž kodu: taimeri neaizdegas un darbinieki neaptaujā. Šādos hostos ieplānotajam darbam jāsākas ar ienākošu pieprasījumu, un visvienkāršākais šī pieprasījuma avots ir ārējs plānotājs. Katrs izsaukums pamodina lietotni (bieži arī datubāzi), tāpēc izsaukums ik minūti maksā vairāk nekā ik pēc 15 minūtēm. Izvēlieties lēnāko grafiku, kas atbilst vajadzībai.

Modelis 1: datubāzes darbu rinda

Sāktajiem darbiem:

1. Izveidojiet tabulu jobs: tips, payload (JSON), statuss (pending, running, done, failed), mēģinājumi, run_after, last_error, laika zīmogi.
2. Kad kaut kas notiek, ievietojiet darba rindu tajā pašā transakcijā kā izmaiņa, kas to izraisīja, lai tie izdodas vai neizdodas kopā.
3. Darbinieks paņem gatavos darbus, atzīmē tos kā running, izpilda darbu un atzīmē kā done.
4. Ja neizdodas, palieliniet attempts, iestatiet run_after vēlāk (piemēram, 1, 5, tad 30 minūtes) un saglabājiet kļūdu. Pēc maksimālā skaita atzīmējiet kā failed un brīdiniet kādu.

Ja vairāki darbinieki var darboties vienlaikus, darbi jāpaņem droši. Postgres gadījumā SELECT ... FOR UPDATE SKIP LOCKED ļauj katram darbiniekam paņemt citas rindas, nesadoties.

Kas palaiž darbinieku? Vienmēr pieejamā serverī — cilpa atsevišķā procesā. Hostā, kas samazina darbību līdz nullei, ieplānotais galapunkts 2. modelī var apstrādāt partiju gatavu darbu katrā izsaukumā.

Modelis 2: ārējs plānotājs, kas izsauc jūsu lietotni

Ieplānotajiem darbiem:

1. Pievienojiet galapunktu, piemēram, POST /api/cron/send-reminders.
2. Aizsargājiet to: pieprasiet slepenu pilnvaru galvenē, glabātu kā noslēpumu abās pusēs, un noraidiet visu citu.
3. Padariet to idempotentu: palaižot divreiz tajā pašā minūtē, nedrīkst nosūtīt divus atgādinājumus. Ierakstiet, kas nosūtīts.
4. Turiet katru izsaukumu īsu: apstrādājiet partiju (piemēram, 100 vienumus) un ļaujiet nākamajam izsaukumam paņemt pārējos.
5. Norādiet plānotāju uz to.

Plānotāju izvēles:

• GitHub Actions ieplānotās darbplūsmas. Bez maksas GitHub lietošanas limitos. Uz 2026. gada septembri GitHub dokumentācija saka, ka īsākais intervāls ir reizi 5 minūtēs, palaišanu var kavēt noslogotos laikos (īpaši katras stundas sākumā), grafiki pēc noklusējuma izmanto UTC, un ieplānotās darbplūsmas publiskā repozitorijā tiek atspējotas pēc 60 dienām bez repozitorija aktivitātes.
• Hostēti cron pakalpojumi. Eksistē daudzi pakalpojumi, kuru vienīgais uzdevums ir izsaukt URL pēc grafika. Pārbaudiet uzticamību, minimālo intervālu un brīdinājumus, pirms no tiem esat atkarīgi.
• Jūsu mākoņpakalpojumu sniedzēja plānotājs. Ja jau izmantojat lielu mākoņpakalpojumu sniedzēju, tam būs pārvaldīts plānotājs, kas var izsaukt HTTPS galapunktu.
• Hostēts darbu vai darbplūsmu pakalpojums. Tie apvieno plānošanu, rindas un atkārtojumus un izsauc jūsu galapunktus katram solim. Salīdziniet cenas un limitus katra pārdevēja vietnē.

Modelis 3: ļaujiet nodrošinātājam to izdarīt

Dažreiz labākais fona darbs nav nekāds:

• Maksājumi. Stripe atkārto neizdevušos abonementu maksājumus un nosūta webhook; jūs reaģējat, nevis aptaujājat. Skatiet kas ir webhook.
• E-pasts. Nodrošinātāji ievieto piegādi rindā un atkārto to, kad esat nodevis ziņojumu.
• Lielapjoma AI darbs. OpenAI un Anthropic piedāvā partiju API steidzamībai nesaistītiem pieprasījumiem, ko iesniedzat un savācat vēlāk.

Uzvednes jūsu AI veidotājam

Rindai:

Pievienojiet fona darbu rindu, izmantojot tabulu jobs mūsu datubāzē (tips, payload JSON, statuss, mēģinājumi, run_after, last_error). Kad lietotājs reģistrējas, ievietojiet darbu send_welcome_email tajā pašā transakcijā, nevis sūtiet iekšēji. Pievienojiet funkciju processJobs(limit), kas paņem gatavos darbus ar SELECT ... FOR UPDATE SKIP LOCKED, tos izpilda un atkārto neizdevušos pēc 1, 5 un 30 minūtēm, atzīmējot tos kā failed pēc 4 mēģinājumiem.

Ieplānotam aktivizētājam:

Pievienojiet POST /api/cron/tick, ko aizsargā bearer pilnvara no noslēpuma CRON_SECRET; noraidiet jebkuru pieprasījumu bez tās. Katrs izsaukums palaiž processJobs(100) un nosūta rezervāciju atgādinājumus, kas gaidāmi nākamajās 24 stundās un vēl nav nosūtīti, ierakstot nosūtītos atgādinājumus, lai nekas netiktu nosūtīts divreiz. Atgrieziet JSON kopsavilkumu par to, kas tika palaists. Pēc tam uzrakstiet GitHub Actions darbplūsmu, kas izsauc šo galapunktu ik pēc 15 minūtēm, nolasot URL un pilnvaru no repozitorija noslēpumiem.

Biežākās kļūdas

• Paļaušanās uz setInterval. Tas klusi apstājas, kad serveris guļ vai restartējas, un dubultojas, kad darbojas divi eksemplāri.
• Neaizsargāts cron galapunkts. Ikviens, kas to atrod, var palaist jūsu darbus vai jūsu e-pasta rēķinu.
• Darbi, kas nav idempotenti. Atkārtojumi un dublēti plānotāja izsaukumi notiks. Projektējiet tiem.
• Nav redzamības kļūmēm. Darbs, kas nedēļu klusi neizdodas, ir sliktāks nekā tas, kas skaļi krīt. Ierakstiet kļūdas žurnālā un brīdiniet par atkārtotām kļūmēm.
• Gari darbi vienā pieprasījumā. Pieprasījumi iziet no laika. Apstrādājiet partijās.
• Pārāk bieža plānošana. Katrs izsaukums hostā, kas samazina darbību līdz nullei, pamodina un maksā par lietotni. Saskaņojiet intervālu ar reālo vajadzību.
• Laika joslas. "9:00" nozīmē dažādas lietas jūsu plānotājam (bieži UTC) un jūsu lietotājiem. Glabājiet laikus UTC un pārvērtiet katram lietotājam.
• Noslēpumi darbplūsmas failā. Glabājiet pilnvaras plānotāja noslēpumu glabātuvē. Skatiet kā glabāt API atslēgas drošībā.

Kontrolsaraksts

• Lēnais darbs pārvietots ārpus lietotāja pieprasījumiem
• Darbi glabāti izturīgi, nevis tikai atmiņā
• Atkārtojumi ar pieaugošiem intervāliem un maksimumu
• Katrs darbs drošs palaišanai divreiz
• Ieplānotais galapunkts aizsargāts ar slepenu pilnvaru
• Katra palaišana apstrādā ierobežotu partiju
• Neizdevušies darbi ir redzami, ar brīdinājumiem
• Plānošanas intervāls izvēlēts, ņemot vērā hostinga izmaksas
• Laiki glabāti UTC

Fona darbi Mythex

Mythex dokumentācija neapraksta ieplānotus vai cron darbus, un publicētās lietotnes un to datubāzes, kad ir dīkstāve, iet gulēt un pamostas nākamajā pieprasījumā (skatiet Hostinga ierobežojumi). Tāpēc nepaļaujieties uz taimeriem savā lietotnē. Darbojošā pieeja ir tā, kas aprakstīta iepriekš: lūdziet aģentam darbu tabulu un galapunktu, kas aizsargāts ar pilnvaru, un pēc tam norādiet ārēju plānotāju uz savu publicēto URL. Glabājiet pilnvaru kā projekta noslēpumu un ņemiet vērā, ka katra pamodināšana tērē kredītus par laiku, kad lietotne un datubāze ir nomodā, tāpēc izvēlieties saprātīgu intervālu. Ja jūsu lietotnei šim nolūkam nepieciešams API serveris, REST API serveris recepte ir sākumpunkts, un kā izveidot REST API aptver galapunktu projektēšanu. Ja jūsu produkta kodols ir pastāvīgi darbojoši darbinieki vai boti, hosts, kas veidots ilgstošiem procesiem, varētu būt piemērotāks.

Jautājumi