Како да извршувате позадински задачи во веб-апликација: редици, планери и cron

За да извршувате позадински задачи во веб-апликација, прво поделете ја работата на два вида. Задачи што се стартуваат настанот (испрати добредојде е-пошта, обработи прикачување) може да се зачуваат во редица задачи, често табела во вашата база, и да ги обработи работник со повторни обиди. Закажани задачи (ноќен извештај, потсетници на секои 15 минути) имаат потреба од нешто што се активира според распоред: функција за cron на хостот или надворешен планер што повикува заштитена крајна точка во вашата апликација. Секогаш направете задачите безбедни за извршување два пати, запишувајте неуспеси и никогаш не се потпирајте на тајмер во сервер што може да спие или да се рестартира.

Овој водич ги објаснува опциите, кога одговара секоја и како да ги поставите со AI градител на апликации, вклучително и на хостови што скалираат до нула.

Што се смета за позадинска задача

Секое нешто бавно, нестабилно или не потребно за непосредниот одговор на корисникот:

• Испраќање е-пошта, известувања и потврди
• Промена на големина на слики, транскодирање видео, генерирање PDF-ови
• Повикување бавни API-ја на трети страни, вклучително и AI модели за долги задачи
• Увоз или синхронизација на податоци од друг систем
• Ноќно чистење, извештаи и потсетници

Правењето на ова во самото барање ги прави страниците бавни и кревки: ако провајдерот за е-пошта не работи, регистрацијата на корисникот пропаѓа. Преместувањето во позадина значи дека корисникот добива моментален одговор и задачата може да се повтори.

Опциите

Нема единствен точен одговор. Мала апликација често треба само редица во база плус надворешен планер.

Зошто хостовите што скалираат до нула го менуваат сликата

Многу современи хостови ја приспиваат вашата апликација кога никој не ја користи и ја будат при следното барање. Тоа штеди пари, но спиечкиот сервер не извршува код: тајмерите не се активираат и работниците не прашуваат. На овие хостови, закажаната работа мора да започне со дојдовно барање, а најлесниот извор на тоа барање е надворешен планер. Секое повикување ја буди апликацијата (и често нејзината база), па повикувањето на секоја минута чини повеќе од на секои 15 минути. Изберете најреткиот распоред што ја задоволува потребата.

Шема 1: редица задачи во база

За задачи што се стартуваат настанот:

1. Создајте табела jobs: вид, податоци (JSON), статус (pending, running, done, failed), обиди, run_after, last_error, временски ознаки.
2. Кога нешто ќе се случи, вметнете ред за задача во истата транзакција со промената што ја предизвикала, за да успеат или да пропаднат заедно.
3. Работник ги зема задачите што им дошло времето, ги означува како running, ја извршува работата и ги означува како done.
4. При неуспех, зголемете attempts, поставете run_after подоцна (на пример 1, 5, па 30 минути) и зачувајте ја грешката. По максимумот, означете ја како failed и известете некого.

Ако повеќе од еден работник може да работи истовремено, задачите мора безбедно да се зафатат. Кај Postgres, SELECT ... FOR UPDATE SKIP LOCKED овозможува секој работник да зема различни редови без судири.

Што го пушта работникот? На сервер што секогаш работи, јамка во посебен процес. На хост што скалира до нула, закажаната крајна точка од Шема 2 може да обработи серија должни задачи при секое повикување.

Шема 2: надворешен планер што ја повикува вашата апликација

За закажани задачи:

1. Додајте крајна точка, како POST /api/cron/send-reminders.
2. Заштитете ја: барајте тајна токен во заглавие, чуван како тајна на двете страни, и отфрлете сè друго.
3. Направете ја идемпотентна: ако се изврши два пати во истата минута, не смее да испрати два потсетника. Запишете што е испратено.
4. Držете го секое повикување кратко: обработете серија (на пример 100 ставки) и нека следното повикување ги земе останатите.
5. Насочете планер кон неа.

Избор на планер:

• Закажани GitHub Actions workflow-и. Бесплатни во рамките на ограничувањата за користење на GitHub. Од септември 2026, документацијата на GitHub вели дека најкраткиот интервал е еднаш на секои 5 минути, извршувањата може да се одложат во време на голем сообраќај (особено на почетокот на секој час), распоредите користат UTC по основно, а закажаните workflow-и во јавен репозиториум се оневозможуваат по 60 дена без активност во репозиториумот.
• Услуги за hosted cron. Постојат многу услуги чија единствена задача е да повикуваат URL по распоред. Проверете ја поузданоста, минималниот интервал и известувањата пред да се потпрете на една.
• Планерот на вашиот облак провајдер. Ако веќе користите голем облак провајдер, ќе има управуван планер што може да повикува HTTPS крајна точка.
• Hosted услуга за задачи или текови. Тие го комбинираат закажувањето, редиците и повторните обиди и ги повикуваат вашите крајни точки за секој чекор. Споредете ги цените и ограничувањата на страницата на секој добавувач.

Шема 3: нека ја направи провајдерот

Понекогаш најдобрата позадинска задача е никоја:

• Плаќања. Stripe повторно ги обидува неуспешните плаќања на претплатите и испраќа webhook-ови; вие реагирате наместо да прашувате. Видете што е webhook.
• Е-пошта. Провајдерите ја редат и повторно ја испраќаат испораката откако ќе ја добијат пораката.
• Масовна AI работа. OpenAI и Anthropic нудат batch API-ја за необврзувачки барања што ги испраќате и ги преземате подоцна.

Упатства за вашиот AI градител

За редица:

Додајте редица позадински задачи со табела jobs во нашата база (вид, податоци JSON, статус, обиди, run_after, last_error). Кога корисник се регистрира, вметнете задача send_welcome_email во истата транзакција, наместо да испраќате внатре во барањето. Додајте функција processJobs(limit) што ги зема должните задачи со SELECT ... FOR UPDATE SKIP LOCKED, ги извршува и ги повторува неуспесите после 1, 5 и 30 минути, означувајќи ги како failed после 4 обиди.

За закажан окидач:

Додајте POST /api/cron/tick заштитен со bearer токен од тајната CRON_SECRET; отфрлете секое барање без него. Секое повикување да ја извршува processJobs(100) и да ги испраќа потсетниците за резервации што доаѓаат во следните 24 часа и уште не се испратени, запишувајќи ги испратените потсетници за ништо да не се испрати двапати. Вратете JSON резиме на она што се извршило. Потоа напишете GitHub Actions workflow што ја повикува оваа крајна точка на секои 15 минути, читајќи ги URL-то и токенот од тајните на репозиториумот.

Чести грешки

• Потпирање на setInterval. Тихо престанува кога серверот спие или се рестартира, а се удвојува кога работат две копии.
• Незаштитена cron крајна точка. Секој што ќе ја најде може да ги активира вашите задачи, или вашата сметка за е-пошта.
• Задачи што не се идемпотентни. Повторните обиди и дупликатите повици од планерот ќе се случат. Дизајнирајте за тоа.
• Нема видливост на неуспеси. Задача што тивко не успева цела недела е полоша од онаа што гласно пропаѓа. Запишувајте грешки и известувајте за повторени неуспеси.
• Долги извршувања во едно барање. Барањата истекуваат. Обработувајте во серии.
• Премногу често закажување. Секое повикување на хост што скалира до нула ја буди апликацијата и ја наплатува. Усогласете го интервалот со вистинската потреба.
• Временски зони. „9 часот“ значи различно за вашиот планер (често UTC) и за корисниците. Чувајте ги времињата во UTC и претворајте ги за секој корисник.
• Тајни во workflow датотеката. Чувајте ги токените во складиштето за тајни на планерот. Видете како да ги чувате API клучевите безбедни.

Листа за проверка

• Бавната работа е префрлена надвор од барањата на корисниците
• Задачите се чуваат трајно, не само во меморија
• Повторни обиди со растечки доцнења и максимум
• Секоја задача е безбедна за извршување два пати
• Закажаната крајна точка е заштитена со тајна токен
• Секое извршување обработува ограничена серија
• Неуспешните задачи се видливи, со известувања
• Интервалот на закажување е избран според трошокот за хостинг
• Времињата се чуваат во UTC

Позадински задачи во Mythex

Документацијата на Mythex не опишува закажани или cron задачи, а објавените апликации и нивните бази спијат кога се неактивни и се будат при следното барање (видете Ограничувања за хостинг). Затоа не се потпирајте на тајмери во вашата апликација. Пристапот што функционира е оној погоре: побарајте од агентот табела jobs и крајна точка заштитена со токен, па насочете надворешен планер кон вашиот објавен URL. Чувајте го токенот како тајна на проектот и имајте предвид дека секое будење троши кредити за времето додека апликацијата и базата се будни, затоа изберете разумен интервал. Ако вашата апликација за ова треба API backend, REST API backend рецептот е почетна точка, а како да изградите REST API ги опфаќа крајните точки. Ако главниот дел од вашиот производ се постојани работници или ботови, хост наменет за долготрајни процеси можеби подобро ќе одговара.

Прашања