Ինչպես գործարկել ֆոնային աշխատանքները վեբ հավելվածում. հերթեր, պլանավորիչներ և cron
Վեբ հավելվածում ֆոնային աշխատանքներ գործարկելու համար նախ բաժանեք աշխատանքը երկու տեսակի. ձգանվող աշխատանքները (ողջույնի նամակ ուղարկել, վերբեռնում մշակել) կարելի է պահել աշխատանքների հերթում, հաճախ ձեր տվյալների բազայի աղյուսակում, և կատարել աշխատողի կողմից կրկնակի փորձերով։ Ժամանակացույցով աշխատանքները (գիշերային հաշվետվություն, հիշեցումներ յուրաքանչյուր 15 րոպեն մեկ) կարիք ունեն մի բանի, որ գործարկվում է ըստ ժամանակացույցի. հոսթի cron գործառույթ կամ արտաքին պլանավորիչ, որ կանչում է պաշտպանված endpoint ձեր հավելվածում։ Միշտ պահեք աշխատանքները անվտանգ՝ կրկին կատարելու համար, գրանցեք ձախողումները և երբեք մի հենվեք տայմերի վրա սերվերում, որ կարող է քնել կամ վերագործարկվել։
Այս ուղեցույցը բացատրում է տարբերակները, թե երբ է յուրաքանչյուրը հարմար, և ինչպես դրանք կարգավորել AI հավելվածների կառուցողով, ներառյալ այն հոսթերում, որոնք իջնում են մինչև զրո։
Ի՞նչն է համարվում ֆոնային աշխատանք
Յուրաքանչյուր դանդաղ, անվստահելի կամ օգտատիրոջ անմիջական պատասխանի համար անհրաժեշտ չեղած բան.
- Էլ. նամակների, ծանուցումների և անդորագրերի ուղարկում
- Պատկերների չափի փոխում, տեսանյութի վերամշակում, PDF-ների ստեղծում
- Դանդաղ երրորդ կողմի API-ների կանչ, ներառյալ AI մոդելները երկար առաջադրանքների համար
- Տվյալների ներմուծում կամ համաժամեցում մեկ այլ համակարգից
- Գիշերային մաքրում, հաշվետվություններ և հիշեցումներ
Այս ամենն անել հարցման ներսում դանդաղեցնում և փխրուն է դարձնում էջերը. եթե էլ. նամակի մատակարարը անջատված է, օգտատիրոջ գրանցումը ձախողվում է։ Տեղափոխելով ֆոն՝ օգտատերը ստանում է ակնթարթային պատասխան, և աշխատանքը կարելի է կրկնել։
Տարբերակները
| Տարբերակ | Ինչպես է աշխատում | Plus | Minus |
|---|---|---|---|
| Նույն պրոցեսում «արձակել և մոռանալ» | Պատասխանել, հետո շարունակել աշխատանքը սերվերում | Առանց կարգավորման | Կորչում է, եթե սերվերը կանգ առնի. կրկնակի փորձեր չկան |
Պրոցեսի ներսի տայմեր (setInterval, setTimeout) | Տայմեր աշխատող սերվերում | Պարզ | Չի աշխատում, երբ քնած է. կրկնվում է մի քանի օրինակի դեպքում |
| Տվյալների բազայով հերթ | Աշխատանքները պահվում են որպես տողեր. աշխատողը վերցնում և կատարում է դրանք | Օգտագործում է ձեր արդեն ունեցած տվյալների բազան. հուսալի. հեշտ է ստուգել | Կրկնակի փորձերը և կողպումը դուք եք կառուցում. պետք է ինչ-որ բան աշխատեցնի աշխատողին |
| Առանձին հերթ (Redis-ով կամ կառավարվող) | Հերթի ծառայություն և աշխատողներ | Հասուն կրկնակի փորձի և ժամանակացույցի գործառույթներ | ԵՒս մեկ ծառայություն՝ աշխատեցնելու և վճարելու համար |
| Հոսթված աշխատանքի կամ աշխատանքային հոսքի ծառայություն | Երրորդ կողմը կանչում է ձեր endpoint-ները կրկնակի փորձերով և ժամանակացույցով | Ժամանակացույցը և կրկնակի փորձերը կատարվում են ձեզ փոխարեն | Կախվածություն վաճառողից. մեկ այլ հաշիվ և բանալի |
| Արտաքին պլանավորիչ, որ կանչում է endpoint | Մեկ այլ տեղ ժամանակացույցով HTTP հարցում է ուղարկվում | Աշխատում է ցանկացած հոսթի վրա, ներառյալ զրոյի իջնողները | Նվազագույն ընդմիջումներ և ուշացումներ. պաշտպանեք endpoint-ը |
| Հոսթի ներկառուցված cron | Հարթակը հրամանը գործարկում է ըստ ժամանակացույցի | Պարզ, որտեղ գոյություն ունի | Ոչ բոլոր հոսթերն են առաջարկում |
Մեկ ճիշտ պատասխան չկա. փոքր հավելվածին հաճախ բավական է տվյալների բազայի հերթ և արտաքին պլանավորիչ։
Ինչու հոսթերը, որ իջնում են մինչև զրո, փոխում են պատկերը
Շատ ժամանակակից հոսթեր քնեցնում են ձեր հավելվածը, երբ ոչ ոք չի օգտագործում, և արթնացնում են հաջորդ հարցման ժամանակ։ Դա խնայում է գումար, բայց քնած սերվերը կոդ չի աշխատեցնում. տայմերները չեն գործարկվում, աշխատողները չեն հարցնում։ Այս հոսթերում ժամանակացույցով աշխատանքը պետք է սկսվի մուտքային հարցումից, և ամենահեշտ աղբյուրը արտաքին պլանավորիչն է։ Յուրաքանչյուր կանչ արթնացնում է հավելվածը (և հաճախ նրա տվյալների բազան), ուստի յուրաքանչյուր րոպեն մեկ կանչելը ավելի թանկ է, քան յուրաքանչյուր 15 րոպեն մեկ։ Ընտրեք ամենադանդաղ ժամանակացույցը, որ բավարարում է կարիքը։
Օրինակ 1. տվյալների բազայի աշխատանքների հերթ
Ձգանվող աշխատանքների համար.
- Ստեղծեք
jobsաղյուսակ. տեսակ, բովանդակություն (JSON), կարգավիճակ (pending,running,done,failed), փորձերի քանակ, run_after, last_error, ժամանակային դրոշմներ։ - Երբ ինչ-որ բան տեղի է ունենում, տեղադրեք աշխատանքի տող նույն գործարքի մեջ, որ առաջացրեց փոփոխությունը, որպեսզի դրանք հաջողվեն կամ ձախողվեն միասին։
- Աշխատողը վերցնում է ժամը եկած աշխատանքները, նշում դրանք
running, կատարում և նշումdone։ - Ձախողման դեպքում մեծացրեք
attempts-ը, դրեքrun_after-ը ավելի ուշ (օրինակ՝ 1, 5, հետո 30 րոպե) և պահեք սխալը։ Առավելագույն քանակից հետո նշեքfailedև տեղեկացրեք որևէ մեկին։
Եթե մի քանի աշխատող կարող է միաժամանակ աշխատել, աշխատանքները պետք է ապահով վերցվեն։ Postgres-ում SELECT ... FOR UPDATE SKIP LOCKED-ը թույլ է տալիս յուրաքանչյուր աշխատողին վերցնել տարբեր տողեր՝ առանց բախման։
Ո՞վ է աշխատեցնում աշխատողին։ Միշտ միացած սերվերի վրա՝ առանձին պրոցեսի մեջ գտնվող օղակ։ Զրոյի իջնող հոսթի վրա՝ Օրինակ 2-ի պլանավորված endpoint-ը կարող է յուրաքանչյուր կանչով մշակել ժամը եկած աշխատանքների խմբաքանակ։
Օրինակ 2. արտաքին պլանավորիչ, որ կանչում է ձեր հավելվածը
Ժամանակացույցով աշխատանքների համար.
- Ավելացրեք endpoint, օրինակ՝
POST /api/cron/send-reminders։ - Պաշտպանեք այն. պահանջեք գաղտնի թոքեն վերնագրում, որ պահված է որպես գաղտնիք երկու կողմում, և մերժեք ամեն ինչ այլ։
- Դարձրեք այն իդեմպոտենտ. երկու անգամ նույն րոպեին գործարկելը չպետք է երկու հիշեցում ուղարկի։ Գրանցեք, թե ինչ է ուղարկվել։
- Պահեք յուրաքանչյուր կանչը կարճ. մշակեք խմբաքանակ (ասենք՝ 100 տարր) և թողեք հաջորդ կանչին մնացածը վերցնել։
- Ուղղեք պլանավորիչը դրա վրա։
Պլանավորիչի ընտրություններ.
- GitHub Actions ժամանակացույցով աշխատանքային հոսքեր. անվճար են GitHub-ի օգտագործման սահմաններում։ 2026 թվականի սեպտեմբերի դրությամբ GitHub-ի փաստաթղթերը նշում են, որ ամենակարճ ընդմիջումը յուրաքանչյուր 5 րոպեն մեկ է, գործարկումները կարող են ուշանալ զբաղված ժամերին (հատկապես յուրաքանչյուր ժամվա սկզբին), ժամանակացույցները լռելյայն օգտագործում են UTC, իսկ հանրային repository-ում ժամանակացույցով աշխատանքային հոսքերը անջատվում են 60 օր repository-ի ակտիվություն չլինելուց հետո։
- Հոսթված cron ծառայություններ. շատ ծառայություններ գոյություն ունեն, որոնց միակ գործն է ժամանակացույցով կանչել URL։ Ստուգեք հուսալիությունը, նվազագույն ընդմիջումը և ծանուցումները, նախքան դրանցից կախվելը։
- Ձեր cloud մատակարարի պլանավորիչ. եթե արդեն օգտագործում եք խոշոր cloud մատակարար, նրա մոտ կլինի կառավարվող պլանավորիչ, որ կարող է կանչել HTTPS endpoint։
- Հոսթված աշխատանքի կամ աշխատանքային հոսքի ծառայություն. սրանք համատեղում են ժամանակացույցը, հերթերը և կրկնակի փորձերը և կանչում են ձեր endpoint-ները յուրաքանչյուր քայլի համար։ Համեմատեք գները և սահմանները յուրաքանչյուր վաճառողի կայքում։
Օրինակ 3. թող մատակարարը անի դա
Բոլորովին երբեմն լավագույն ֆոնային աշխատանքը բացակայում է.
- Վճարումներ. Stripe-ը կրկնում է ձախողված բաժանորդագրության վճարումները և ուղարկում webhook-ներ. դուք արձագանքում եք, այլ ոչ թե հարցնում։ Տես ինչ է webhook-ը։
- Էլ. նամակ. մատակարարները հերթում են և կրկնում առաքումը, երբ դուք հաղորդագրությունը փոխանցել եք։
- Զանգվածային AI աշխատանք. OpenAI-ն և Anthropic-ը առաջարկում են batch API-ներ՝ ոչ շտապ հարցումների համար, որոնք դուք ուղարկում և հետո հավաքում եք։
Հրահանգներ ձեր AI կառուցողին
Հերթի համար.
Ավելացրու ֆոնային աշխատանքների հերթ՝ օգտագործելով jobs աղյուսակ մեր տվյալների բազայում (տեսակ, payload JSON, կարգավիճակ, attempts, run_after, last_error)։ Երբ օգտատերը գրանցվում է, տեղադրիր send_welcome_email աշխատանք նույն գործարքի մեջ՝ ուղղակիորեն ուղարկելու փոխարեն։ Ավելացրու processJobs(limit) ֆունկցիա, որ վերցնում է ժամը եկած աշխատանքները SELECT ... FOR UPDATE SKIP LOCKED-ով, կատարում դրանք և կրկնում ձախողումները 1, 5 և 30 րոպե հետո, նշելով դրանք failed 4 փորձից հետո։
Ժամանակացույցով գործարկման համար.
Ավելացրու POST /api/cron/tick, պաշտպանված CRON_SECRET գաղտնիքից ստացված bearer թոքենով. մերժիր յուրաքանչյուր հարցում առանց դրա։ Յուրաքանչյուր կանչ գործարկում է processJobs(100)-ը և ուղարկում հաջորդ 24 ժամում ժամը եկած և դեռ չուղարկված ամրագրման հիշեցումները՝ գրանցելով ուղարկվածները, որպեսզի ոչինչ երկու անգամ չուղարկվի։ Վերադարձրու JSON ամփոփում այն մասին, թե ինչ է աշխատել։ Ապա գրիր GitHub Actions աշխատանքային հոսք, որ այս endpoint-ը կանչում է յուրաքանչյուր 15 րոպեն մեկ՝ URL-ը և թոքենը կարդալով repository գաղտնիքներից։
Տարածված սխալներ
- Ապավինել
setInterval-ին. այն լռելյայն կանգ է առնում, երբ սերվերը քնում է կամ վերագործարկվում, և կրկնվում է, երբ աշխատում են երկու օրինակ։ - Չպաշտպանված cron endpoint. ով էլ գտնի այն, կարող է գործարկել ձեր աշխատանքները կամ ձեր էլ. նամակի հաշիվը բարձրացնել։
- Աշխատանքներ, որ իդեմպոտենտ չեն. կրկնակի փորձեր և կրկնվող պլանավորիչի կանչեր լինելու են։ Նախագծեք դրանց համար։
- Ձախողումների տեսանելիության բացակայություն. աշխատանք, որ մեկ շաբաթ անձայն ձախողվում է, ավելի վատ է, քան այն, որ բարձր ձայնով է ձախողվում։ Գրանցեք սխալները և ծանուցեք կրկնվող ձախողումների մասին։
- Երկար աշխատանք մեկ հարցման մեջ. հարցումները ժամանակի սահմանից են անցնում։ Մշակեք խմբաքանակներով։
- Չափազանց հաճախ պլանավորելը. զրոյի իջնող հոսթի յուրաքանչյուր կանչ արթնացնում և վճարել է տալիս հավելվածը։ Համապատասխանեցրեք ընդմիջումը իրական կարիքին։
- Ժամային գոտիներ. «9am»-ը տարբեր բան է նշանակում ձեր պլանավորիչի (հաճախ UTC) և ձեր օգտատերերի համար։ Պահեք ժամանակը UTC-ով և փոխարկեք յուրաքանչյուր օգտատիրոջ համար։
- Գաղտնիքներ աշխատանքային հոսքի ֆայլում. պահեք թոքենները պլանավորիչի գաղտնիքների պահոցում։ Տես ինչպես պահել API բանալիները ապահով։
Ստուգաթերթ
- Դանդաղ աշխատանքը տեղափոխված է օգտատիրոջ հարցումներից
- Աշխատանքները պահվում են հուսալիորեն, ոչ միայն հիշողության մեջ
- Կրկնակի փորձեր աճող ընդմիջումներով և առավելագույն սահմանով
- Յուրաքանչյուր աշխատանք անվտանգ է կրկին գործարկելու համար
- Ժամանակացույցով endpoint-ը պաշտպանված է գաղտնի թոքենով
- Յուրաքանչյուր գործարկում մշակում է սահմանափակ խմբաքանակ
- Ձախողված աշխատանքները տեսանելի են, ծանուցումներով
- Ժամանակացույցի ընդմիջումը ընտրված է՝ հոսթինգի ծախսը հաշվի առնելով
- Ժամանակը պահված է UTC-ով
Ֆոնային աշխատանքները Mythex-ում
Mythex-ի փաստաթղթերը չեն նկարագրում ժամանակացույցով կամ cron աշխատանքները, իսկ հրապարակված հավելվածները և նրանց տվյալների բազաները անգործության ժամանակ քնում են և արթնանում հաջորդ հարցման ժամանակ (տես Հոսթինգի սահմանաչափերը)։ Ուստի մի ապավինեք ձեր հավելվածի ներսում տայմերներին։ Աշխատող մոտեցումը վերը նկարագրվածն է. agent-ից խնդրեք jobs աղյուսակ և թոքենով պաշտպանված endpoint, ապա ուղղեք արտաքին պլանավորիչը ձեր հրապարակված URL-ին։ Պահեք թոքենը որպես նախագծի գաղտնիք և հիշեք, որ յուրաքանչյուր արթնացում ծախսում է կրեդիտներ այն ժամանակի համար, երբ հավելվածը և տվյալների բազան արթուն են, ուստի ընտրեք խելամիտ ընդմիջում։ Եթե ձեր հավելվածին այս նպատակով API backend է պետք, REST API backend բաղադրատոմսը սկզբնակետ է, իսկ ինչպես կառուցել REST API-ը ներառում է endpoint-ների նախագծումը։ Եթե ձեր արտադրանքի հիմքը միշտ աշխատող աշխատողներ կամ բոտեր են, պրոցեսների համար նախատեսված հոսթը կարող է ավելի հարմար լինել ձեզ։
Հարցեր
Ի՞նչ է ֆոնային աշխատանքը։
Ֆոնային աշխատանքը այն աշխատանքն է, որ ձեր հավելվածն անում է այն հարցումից դուրս, որին օգտատերը սպասում է, օրինակ՝ էլ. նամակ ուղարկելը, պատկերի չափը փոխելը, հաշվետվություն կազմելը կամ տվյալների համաժամեցումը։ Օգտատերը արագ պատասխան է ստանում, իսկ աշխատանքն առանձին է աշխատում և կարող է կրկնվել, եթե ձախողվի։
Ինչպե՞ս գործարկեմ ժամանակացույցով առաջադրանք, եթե հոսթս cron չունի։
Ավելացրեք պաշտպանված endpoint, որ կատարում է աշխատանքը, հետո թող արտաքին պլանավորիչը այն կանչի ըստ ժամանակացույցի։ Տարբերակները ներառում են ժամանակացույցով GitHub Actions աշխատանքային հոսք, հոսթված cron ծառայություն կամ ձեր cloud մատակարարի պլանավորիչը։ Պաշտպանեք endpoint-ը գաղտնի թոքենով։
Կարո՞ղ եմ օգտագործել setInterval կամ setTimeout ժամանակացույցով աշխատանքների համար։
Միայն փոքր, անկարևոր առաջադրանքների համար, միշտ աշխատող սերվերի վրա։ Եթե սերվերը վերագործարկվում է, զրոյի է իջնում կամ աշխատում է մի քանի օրինակով, տայմերները կորում են կամ կատարվում են ավելի քան մեկ անգամ։ Պահեք ժամանակացույցով աշխատանքները տվյալների բազայում կամ օգտագործեք պլանավորիչ։
Աջակցում է՞ արդյոք Mythex-ը cron աշխատանքներին։
Mythex-ի փաստաթղթերը չեն նկարագրում ժամանակացույցով կամ cron աշխատանքները, իսկ հրապարակված հավելվածները անգործության ժամանակ քնում են։ Վստահելի մոտեցումը արտաքին պլանավորիչն է, որ կանչում է պաշտպանված endpoint ձեր հավելվածում, ինչը արթնացնում է հավելվածը և կատարում աշխատանքը։