Jinsi ya Kuendesha Kazi za Usuli katika App ya Wavuti: Foleni, Wapangaji na Cron

Ili kuendesha kazi za usuli katika app ya wavuti, kwanza gawanya kazi katika aina mbili. Kazi zinazochochewa (kutuma barua pepe ya karibu, kuchakata upakiaji) zinaweza kuhifadhiwa kwenye foleni ya kazi, mara nyingi jedwali kwenye hifadhidata yako, na kushughulikiwa na mfanyakazi mwenye majaribio upya. Kazi zilizopangwa (ripoti ya usiku, vikumbusho kila dakika 15) zinahitaji kitu kinachowashwa kwa ratiba: kipengele cha cron cha host, au mpangaji wa nje anayemwita mwisho uliolindwa kwenye app yako. Fanya kazi zote ziwe salama kuendeshwa mara mbili, rekodi kushindwa, na usiwahi kutegemea kipima muda ndani ya seva inayoweza kulala au kuanzishwa upya.

Mwongozo huu unaeleza chaguo, zinapofaa kila moja, na jinsi ya kuziweka kwa kijenzi cha app cha AI, ikiwemo kwenye hosts zinazoshuka hadi sifuri.

Kazi ya usuli ni nini

Kitu chochote kinachochukua muda, si cha kuaminika, au hakihitajiki kwa jibu la papo hapo la mtumiaji:

• Kutuma barua pepe, arifa na risiti
• Kubadilisha ukubwa wa picha, kubadilisha video, kutengeneza PDF
• Kuita API za watu wa tatu za polepole, zikiwemo modeli za AI kwa kazi ndefu
• Kuingiza au kusawazisha data kutoka mfumo mwingine
• Usafishaji wa usiku, ripoti na vikumbusho

Kufanya hili ndani ya ombi kunafanya kurasa ziwe polepole na dhaifu: mtoa huduma wa barua pepe akiwa chini, usajili wa mtumiaji unashindwa. Kulihamishia usuli kunamaanisha mtumiaji anapata jibu papo hapo na kazi inaweza kujaribiwa tena.

Chaguo zilizopo

Hakuna jibu moja sahihi. App ndogo mara nyingi inahitaji foleni ya hifadhidata pamoja na mpangaji wa nje tu.

Kwa nini hosts zinazoshuka hadi sifuri zinabadilisha picha

Hosts nyingi za kisasa huweka app yako kulala wakati hakuna anayeitumia na kuiamsha ombi linalofuata. Hilo linaokoa pesa, lakini seva inayolala haiendeshi msimbo wowote: vipima muda havirushi na wafanyakazi hawakagui foleni. Kwenye hosts hizi, kazi zilizopangwa lazima zianze kwa ombi linalokuja, na chanzo rahisi cha ombi hilo ni mpangaji wa nje. Kila mwito unaamsha app (na mara nyingi hifadhidata yake), kwa hiyo kuita kila dakika kunagharimu zaidi ya kila dakika 15. Chagua ratiba ya polepole zaidi inayotimiza mahitaji.

Mfano 1: foleni ya kazi ya hifadhidata

Kwa kazi zinazochochewa:

1. Unda jedwali jobs: aina, payload (JSON), hali (pending, running, done, failed), idadi ya majaribio, run_after, last_error, muda wa kuanza na kumaliza.
2. Kitu kinapotokea, ingiza safu ya kazi katika muamala uleule kama mabadiliko yaliyosababisha, ili zifanikiwe au zishindwe pamoja.
3. Mfanyakazi anachukua kazi zilizofika wakati wake, anaziweka running, anazifanya na kuziweka done.
4. Ikishindwa, ongeza attempts, weka run_after baadaye (kwa mfano dakika 1, 5, kisha 30) na uhifadhi hitilafu. Baada ya kikomo, iweke failed na umjulishe mtu.

Ikiwa mfanyakazi zaidi ya mmoja anaweza kuendesha kwa wakati mmoja, kazi lazima zichukuliwe kwa usalama. Kwenye Postgres, SELECT ... FOR UPDATE SKIP LOCKED inaruhusu kila mfanyakazi kuchukua safu tofauti bila kugongana.

Nini kinaendesha mfanyakazi? Kwenye seva inayoendelea kufanya kazi muda wote, ni kitanzi katika mchakato tofauti. Kwenye host inayoshuka hadi sifuri, mwisho uliopangwa wa Mfano 2 unaweza kuchakata kundi la kazi zilizofika kila unapoitwa.

Mfano 2: mpangaji wa nje anayeita app yako

Kwa kazi zilizopangwa:

1. Ongeza mwisho kama POST /api/cron/send-reminders.
2. Ulinde: hitaji tokeni ya siri kwenye kichwa cha ombi, iliyohifadhiwa kama siri pande zote mbili, na kataa chochote kingine.
3. Ifanye idempotent: kuiendesha mara mbili ndani ya dakika moja lisitume vikumbusho viwili. Rekodi kilichotumwa.
4. Weka kila wito fupi: chakata kundi (kwa mfano 100) na uache wito unaofuata uchukue mengine.
5. Elekeza mpangaji kwake.

Chaguo za mpangaji:

• Workflow zilizopangwa za GitHub Actions. Bure ndani ya mipaka ya matumizi ya GitHub. Kufikia Septemba 2026, nyaraka za GitHub zinasema muda mfupi zaidi ni mara moja kila dakika 5, uendeshaji unaweza kuchelewa nyakati za msongamano (hasa mwanzo wa kila saa), ratiba hutumia UTC kwa chaguo-msingi, na workflow zilizopangwa katika hazina ya umma huzimwa baada ya siku 60 bila shughuli ya hazina.
• Huduma za cron zinazohostiwa. Zipo huduma nyingi ambazo kazi yake pekee ni kuita URL kwa ratiba. Angalia uaminifu, muda wa chini zaidi na tahadhari kabla ya kuitegemea.
• Mpangaji wa mtoa huduma wako wa wingu. Ukitumia mtoa huduma mkubwa wa wingu tayari, atakuwa na mpangaji aliyesimamiwa anayeweza kuita mwisho wa HTTPS.
• Huduma ya kazi au workflow inayohostiwa. Hizi zinachanganya ratiba, foleni na majaribio upya, na kuita miisho yako kwa kila hatua. Linganisha bei na vikomo kwenye tovuti ya kila muuzaji.

Mfano 3: acha mtoa huduma aifanye

Wakati mwingine kazi bora ya usuli ni kutokuwa na kazi kabisa:

• Malipo. Stripe hujaribu tena malipo ya usajili yaliyoshindwa na kutuma webhooks; wewe unajibu badala ya kukagua mara kwa mara. Tazama webhook ni nini.
• Barua pepe. Watoa huduma huweka barua pepe kwenye foleni na kujaribu tena uwasilishaji mara tu umewakabidhi ujumbe.
• Kazi nyingi za AI. OpenAI na Anthropic zinatoa API za batch kwa maombi yasiyo ya haraka unayoyawasilisha na kuyakusanya baadaye.

Maagizo ya kumpa kijenzi chako cha AI

Kwa foleni:

Ongeza foleni ya kazi za usuli kwa kutumia jedwali la jobs kwenye hifadhidata yetu (aina, payload ya JSON, hali, idadi ya majaribio, run_after, last_error). Mtumiaji anapojisajili, ingiza kazi ya send_welcome_email katika muamala uleule badala ya kuituma moja kwa moja. Ongeza kazi ya processJobs(limit) inayochukua kazi zilizofika kwa SELECT ... FOR UPDATE SKIP LOCKED, inaziendesha, na kujaribu tena zilizoshindwa baada ya dakika 1, 5 na 30, kuziweka failed baada ya majaribio 4.

Kwa kichochezi kilichopangwa:

Ongeza POST /api/cron/tick inayolindwa na bearer token kutoka kwenye siri CRON_SECRET; kataa ombi lolote lisilo nayo. Kila wito uendeshe processJobs(100) na utume vikumbusho vya miadi vinavyofika ndani ya saa 24 zijazo ambavyo bado hazijatumwa, ukirekodi vikumbusho vilivyotumwa ili hakuna kitu kitumwe mara mbili. Rudisha muhtasari wa JSON wa kilichoendeshwa. Kisha andika workflow ya GitHub Actions inayoita mwisho huu kila dakika 15, ikisoma URL na tokeni kutoka kwenye siri za hazina.

Makosa ya kawaida

• Kutegemea setInterval. Inasimama kimya seva inapolala au kuanzishwa upya, na inarudia mara mbili nakala mbili zinapoendeshwa.
• Mwisho wa cron usiolindwa. Yeyote anayeupata anaweza kuanzisha kazi zako, au bili yako ya barua pepe.
• Kazi zisizo idempotent. Majaribio upya na miito ya mara mbili ya mpangaji vitatokea. Yabuni kwa ajili yake.
• Hakuna mwonekano wa kushindwa. Kazi inayoshindwa kimya kwa wiki nzima ni mbaya zaidi kuliko inayoshindwa kwa sauti. Rekodi makosa na utoe tahadhari kwa kushindwa kurudiwa.
• Uendeshaji mrefu katika ombi moja. Maombi huisha muda. Chakata kwa makundi.
• Kupanga mara nyingi mno. Kila wito kwenye host inayoshuka hadi sifuri unaamsha na kulipisha app. Linganisha muda na mahitaji halisi.
• Saa za maeneo. "Saa tatu asubuhi" ina maana tofauti kwa mpangaji wako (mara nyingi UTC) na kwa watumiaji wako. Hifadhi muda kwa UTC na ubadilishe kwa kila mtumiaji.
• Siri kwenye faili la workflow. Weka tokeni kwenye hifadhi ya siri ya mpangaji. Tazama jinsi ya kuweka funguo za API salama.

Orodha ya kuangalia

• Kazi nzito zimetolewa nje ya maombi ya watumiaji
• Kazi zimehifadhiwa kwa kudumu, si kwenye kumbukumbu tu
• Majaribio upya yenye ucheleweshaji unaoongezeka na kikomo
• Kila kazi ni salama kuendeshwa mara mbili
• Mwisho uliopangwa umelindwa kwa tokeni ya siri
• Kila uendeshaji unachakata kundi lenye mipaka
• Kazi zilizoshindwa zinaonekana, zikiwa na tahadhari
• Muda wa ratiba umechaguliwa kwa kuzingatia gharama ya hosting
• Muda umehifadhiwa kwa UTC

Kazi za usuli kwenye Mythex

Nyaraka za Mythex hazielezi kazi zilizopangwa au cron, na app zilizochapishwa pamoja na hifadhidata zake hulala zisipotumika na kuamka ombi linalofuata (tazama Vikomo vya hosting). Kwa hiyo usitegemee vipima muda ndani ya app yako. Njia inayofanya kazi ni ile iliyo hapo juu: muombe wakala jedwali la kazi na mwisho uliolindwa kwa tokeni, kisha elekeza mpangaji wa nje kwenye URL yako iliyochapishwa. Hifadhi tokeni kama siri ya mradi, na kumbuka kwamba kila kuamka kunatumia credits kwa muda ambao app na hifadhidata zinakuwa macho, kwa hiyo chagua muda unaofaa. Ikiwa app yako inahitaji backend ya API kwa hili, mapishi ya REST API backend ni mwanzo mzuri, na jinsi ya kujenga REST API inaeleza kubuni miisho. Ikiwa wafanyakazi wa kudumu au roboti ndio kiini cha bidhaa yako, host iliyojengwa kwa michakato inayoendelea inaweza kukufaa zaidi.

Maswali