వెబ్ యాప్‌లో బ్యాక్‌గ్రౌండ్ జాబ్‌లను ఎలా నడపాలి: queues, schedulers మరియు cron

వెబ్ యాప్‌లో బ్యాక్‌గ్రౌండ్ జాబ్‌లు నడపాలంటే, ముందుగా పనిని రెండు రకాలుగా విభజించండి. ట్రిగ్గర్ అయ్యే జాబ్‌లు (స్వాగత ఇమెయిల్ పంపడం, అప్‌లోడ్ ప్రాసెస్ చేయడం) job queue లో సేవ్ చేయవచ్చు, తరచూ మీ database లోని ఒక table, మరియు retries తో ఒక worker దాన్ని నిర్వహిస్తుంది. షెడ్యూల్డ్ జాబ్‌లు (రాత్రివేళ report, ప్రతి 15 నిమిషాలకు రిమైండర్లు) ఒక షెడ్యూల్‌పై నడిచే దానిని కోరతాయి: host యొక్క cron ఫీచర్, లేదా మీ యాప్‌లోని రక్షిత endpoint ను పిలిచే బాహ్య scheduler. జాబ్‌లు రెండుసార్లు నడిచినా సురక్షితంగా ఉండేలా చేయండి, వైఫల్యాలను నమోదు చేయండి, నిద్రపోగల లేదా restart అయ్యే server లోని timer పై ఎప్పుడూ ఆధారపడకండి.

ఈ గైడ్ ఎంపికలను, ప్రతిదీ ఎప్పుడు సరిపోతుందో, AI app builder తో, స్కేల్-టు-జీరో అయ్యే hosts తో సహా, వాటిని ఎలా సెటప్ చేయాలో వివరిస్తుంది.

బ్యాక్‌గ్రౌండ్ జాబ్ అంటే ఏమిటి

నెమ్మదిగా ఉండేది, నమ్మదగనిది, లేదా వినియోగదారు తక్షణ స్పందనకు అవసరం లేనిది ఏదైనా:

• ఇమెయిళ్లు, నోటిఫికేషన్లు మరియు రసీదులు పంపడం
• చిత్రాల పరిమాణం మార్చడం, వీడియో transcoding, PDFలు తయారు చేయడం
• నెమ్మదైన మూడవ పక్ష APIలను పిలవడం, దీర్ఘకాల పనుల కోసం AI మోడల్స్ సహా
• మరో వ్యవస్థ నుండి డేటాను దిగుమతి లేదా sync చేయడం
• రాత్రివేళ clean-up, reports మరియు రిమైండర్లు

ఈ పనిని request లోపల చేస్తే పేజీలు నెమ్మదిగా మరియు పెళుసుగా మారతాయి: ఇమెయిల్ provider డౌన్ అయితే, వినియోగదారు signup విఫలమవుతుంది. బ్యాక్‌గ్రౌండ్‌కు తరలిస్తే, వినియోగదారుకు తక్షణ స్పందన వస్తుంది, జాబ్‌ను మళ్లీ ప్రయత్నించవచ్చు.

ఎంపికలు

ఒకే సరైన సమాధానం లేదు. చిన్న యాప్‌కు తరచూ database queue మరియు బాహ్య scheduler మాత్రమే అవసరం.

zero కు స్కేల్ అయ్యే hosts చిత్రాన్ని ఎలా మారుస్తాయి

ఆధునిక hosts చాలావరకు ఎవరూ వాడనప్పుడు మీ యాప్‌ను నిద్రపుచ్చుతాయి, తర్వాతి request కు మేల్కొలుపుతాయి. అది ఖర్చును ఆదా చేస్తుంది, కానీ నిద్రపోతున్న server ఏ కోడ్‌నూ నడపదు: timers పనిచేయవు, workers poll చేయరు. ఈ hosts పై షెడ్యూల్ చేసిన పని ఒక వస్తున్న request తో ప్రారంభం కావాలి, మరియు దానికి సులభమైన మూలం బాహ్య scheduler. ప్రతి call యాప్‌ను (తరచూ దాని database ను కూడా) మేల్కొలుపుతుంది, కాబట్టి ప్రతి నిమిషం పిలవడం ప్రతి 15 నిమిషాలకు కంటే ఎక్కువ ఖర్చవుతుంది. అవసరాన్ని తీర్చే అతి నెమ్మదైన షెడ్యూల్ ఎంచుకోండి.

పద్ధతి 1: database job queue

ట్రిగ్గర్ అయ్యే జాబ్‌ల కోసం:

1. jobs table సృష్టించండి: type, payload (JSON), status (pending, running, done, failed), attempts, run_after, last_error, timestamps.
2. ఏదైనా జరిగినప్పుడు, దానికి కారణమైన మార్పుతో అదే transaction లో ఒక job row ను insert చేయండి, తద్వారా అవి కలిసి విజయవంతమవుతాయి లేదా విఫలమవుతాయి.
3. ఒక worker సమయం వచ్చిన జాబ్‌లను తీసుకుని, running గా గుర్తించి, పనిని చేసి done గా గుర్తిస్తుంది.
4. విఫలమైతే, attempts పెంచి, run_after ను తర్వాతకు సెట్ చేయండి (ఉదాహరణకు 1, 5, తర్వాత 30 నిమిషాలు) మరియు error ను నిల్వ చేయండి. గరిష్ట సంఖ్య తర్వాత దాన్ని failed గా గుర్తించి ఎవరికైనా హెచ్చరించండి.

ఒకేసారి ఒకటి కంటే ఎక్కువ workers నడవవచ్చంటే, జాబ్‌లను సురక్షితంగా claim చేయాలి. Postgres పై, SELECT ... FOR UPDATE SKIP LOCKED ప్రతి worker వేర్వేరు rows ను ఢీకొనకుండా claim చేయడానికి అనుమతిస్తుంది.

worker ను ఏమి నడుపుతుంది? ఎల్లప్పుడూ ఆన్‌లో ఉండే server పై, విడి process లోని loop. నిద్రపోగల host పై, పద్ధతి 2 లోని షెడ్యూల్డ్ endpoint ప్రతి call కు సమయం వచ్చిన జాబ్‌ల batch ను ప్రాసెస్ చేయగలదు.

పద్ధతి 2: మీ యాప్‌ను పిలిచే బాహ్య scheduler

షెడ్యూల్డ్ జాబ్‌ల కోసం:

1. POST /api/cron/send-reminders వంటి endpoint జోడించండి.
2. రక్షించండి: header లో రహస్య token అడగండి, రెండు వైపులా secret గా నిల్వ చేయండి, మిగతావాటిని తిరస్కరించండి.
3. Idempotent చేయండి: ఒకే నిమిషంలో రెండుసార్లు నడిస్తే రెండు రిమైండర్లు పంపకూడదు. ఏమి పంపబడిందో నమోదు చేయండి.
4. ప్రతి call ను చిన్నదిగా ఉంచండి: ఒక batch (ఉదాహరణకు 100 అంశాలు) ప్రాసెస్ చేయండి, మిగతావి తర్వాతి call తీసుకుంటుంది.
5. ఒక scheduler ను దానికి సూచించండి.

Scheduler ఎంపికలు:

• GitHub Actions షెడ్యూల్డ్ workflows. GitHub వినియోగ పరిమితుల్లో ఉచితం. సెప్టెంబర్ 2026 నాటికి, GitHub డాక్యుమెంటేషన్ ప్రకారం అతి తక్కువ విరామం ప్రతి 5 నిమిషాలకు ఒకసారి; రద్దీ సమయాల్లో (ముఖ్యంగా ప్రతి గంట ప్రారంభంలో) runs ఆలస్యం కావచ్చు; షెడ్యూల్స్ డిఫాల్ట్‌గా UTC వాడతాయి; పబ్లిక్ repository లోని షెడ్యూల్డ్ workflows 60 రోజుల repository కార్యకలాపం లేకపోతే నిలిపివేయబడతాయి.
• Hosted cron సేవలు. ఒకే పని షెడ్యూల్‌లో URL ను పిలవడం అయిన అనేక సేవలు ఉన్నాయి. వాటిపై ఆధారపడే ముందు నమ్మకత్వం, కనీస విరామం మరియు హెచ్చరికలు తనిఖీ చేయండి.
• మీ cloud provider యొక్క scheduler. మీరు ఇప్పటికే ఒక పెద్ద cloud provider వాడుతుంటే, దానికి HTTPS endpoint ను పిలవగల managed scheduler ఉంటుంది.
• Hosted job లేదా workflow సేవ. ఇవి షెడ్యూలింగ్, queues మరియు retries ను కలుపుతాయి, ప్రతి దశకు మీ endpoints ను పిలుస్తాయి. ధర మరియు పరిమితులను ప్రతి విక్రేత సైట్‌లో పోల్చండి.

పద్ధతి 3: ప్రొవైడర్‌కే వదిలేయండి

కొన్నిసార్లు ఉత్తమ బ్యాక్‌గ్రౌండ్ జాబ్ అసలు ఏదీ కాదు:

• చెల్లింపులు. Stripe విఫలమైన subscription చెల్లింపులను మళ్లీ ప్రయత్నిస్తుంది మరియు webhooks పంపుతుంది; మీరు పోల్ చేయడానికి బదులు ప్రతిస్పందిస్తారు. webhook అంటే ఏమిటి చూడండి.
• ఇమెయిల్. మీరు సందేశాన్ని అప్పగించాక ప్రొవైడర్లు డెలివరీని queue చేసి మళ్లీ ప్రయత్నిస్తారు.
• బల్క్ AI పని. OpenAI మరియు Anthropic అత్యవసరం కాని అభ్యర్థనల కోసం batch APIs అందిస్తాయి, మీరు సమర్పించి తర్వాత సేకరిస్తారు.

మీ AI builder కు ఇవ్వవలసిన prompts

queue కోసం:

మన database లో jobs table (type, payload JSON, status, attempts, run_after, last_error) ఉపయోగించి ఒక background job queue జోడించు. ఒక వినియోగదారు sign up అయినప్పుడు, ఇన్‌లైన్‌లో ఇమెయిల్ పంపకుండా అదే transaction లో send_welcome_email job ను insert చేయి. SELECT ... FOR UPDATE SKIP LOCKED తో సమయం వచ్చిన jobs ను claim చేసి నడిపే processJobs(limit) function జోడించు, విఫలాలను 1, 5 మరియు 30 నిమిషాల తర్వాత మళ్లీ ప్రయత్నించు, 4 ప్రయత్నాల తర్వాత failed గా గుర్తించు.

షెడ్యూల్డ్ ట్రిగ్గర్ కోసం:

POST /api/cron/tick ను CRON_SECRET అనే secret నుండి bearer token తో రక్షించు; token లేని ఏ request ను తిరస్కరించు. ప్రతి call processJobs(100) నడిపి, రాబోయే 24 గంటల్లో సమయం వచ్చి ఇంకా పంపని booking రిమైండర్లను పంపాలి, పంపినవాటిని నమోదు చేసి ఏదీ రెండుసార్లు పంపబడకుండా చూడాలి. ఏమి నడిచిందో సారాంశాన్ని JSON గా తిరిగివ్వు. తర్వాత ఈ endpoint ను ప్రతి 15 నిమిషాలకు పిలిచే GitHub Actions workflow రాయి, URL మరియు token ను repository secrets నుండి చదవాలి.

సాధారణ తప్పులు

• setInterval పై ఆధారపడటం. server నిద్రపోయినప్పుడు లేదా restart అయినప్పుడు అది నిశ్శబ్దంగా ఆగిపోతుంది, రెండు కాపీలు నడిచితే రెట్టింపు అవుతుంది.
• రక్షణ లేని cron endpoint. దాన్ని కనుగొన్న ఎవరైనా మీ జాబ్‌లను, లేదా మీ ఇమెయిల్ బిల్లును ట్రిగ్గర్ చేయగలరు.
• Idempotent కాని జాబ్‌లు. retries మరియు నకిలీ scheduler calls జరుగుతాయి. వాటికి అనుగుణంగా డిజైన్ చేయండి.
• వైఫల్యం కనిపించకపోవడం. ఒక వారం నిశ్శబ్దంగా విఫలమయ్యే జాబ్, గట్టిగా విఫలమయ్యే జాబ్ కంటే ఘోరం. errors లాగ్ చేయండి, పదేపదే వైఫల్యాలపై హెచ్చరించండి.
• ఒకే request లో దీర్ఘ పరుగులు. requests timeout అవుతాయి. batches లో ప్రాసెస్ చేయండి.
• చాలా తరచూ షెడ్యూల్ చేయడం. zero కు స్కేల్ అయ్యే host పై ప్రతి call యాప్‌ను మేల్కొలిపి బిల్ చేస్తుంది. విరామాన్ని నిజ అవసరానికి సరిపోల్చండి.
• సమయ మండలాలు. “ఉదయం 9” మీ scheduler (తరచూ UTC) మరియు మీ వినియోగదారులకు వేర్వేరుగా అర్థమవుతుంది. సమయాలను UTC లో నిల్వ చేసి, ప్రతి వినియోగదారు కోసం మార్చండి.
• Workflow ఫైల్‌లో రహస్యాలు. tokens ను scheduler యొక్క secret store లో ఉంచండి. API keys ను సురక్షితంగా ఎలా ఉంచాలి చూడండి.

చెక్‌లిస్ట్

• నెమ్మదైన పని వినియోగదారు requests నుండి బయటకు తరలించబడింది
• Jobs మెమరీలో మాత్రమే కాకుండా మన్నికగా నిల్వ చేయబడ్డాయి
• పెరుగుతున్న విరామాలు మరియు గరిష్ట సంఖ్యతో retries
• ప్రతి job రెండుసార్లు నడిచినా సురక్షితం
• షెడ్యూల్డ్ endpoint రహస్య token తో రక్షించబడింది
• ప్రతి run పరిమిత batch ను ప్రాసెస్ చేస్తుంది
• విఫలమైన jobs కనిపిస్తాయి, హెచ్చరికలతో
• Hosting ఖర్చును దృష్టిలో ఉంచుకుని షెడ్యూల్ విరామం ఎంచుకున్నారు
• సమయాలు UTC లో నిల్వ చేయబడ్డాయి

Mythex లో బ్యాక్‌గ్రౌండ్ జాబ్‌లు

Mythex డాక్యుమెంటేషన్ షెడ్యూల్డ్ లేదా cron jobs గురించి వివరించదు, మరియు ప్రచురిత యాప్‌లు, వాటి databases నిష్క్రియంగా ఉన్నప్పుడు నిద్రపోతాయి, తర్వాతి సందర్శనలో మేల్కొంటాయి (చూడండి Hosting limits). కాబట్టి మీ యాప్ లోపల timers పై ఆధారపడకండి. పనిచేసే పద్ధతి పైన వివరించినదే: jobs table మరియు రక్షిత endpoint కోసం agent ను అడగండి, తర్వాత మీ ప్రచురిత URL కు బాహ్య scheduler ను సూచించండి. token ను ప్రాజెక్ట్ secret గా నిల్వ చేయండి, ప్రతి మేల్కొలుపు యాప్ మరియు database మెలకువగా ఉన్న సమయానికి credits ఖర్చు చేస్తుందని గుర్తుంచుకోండి, కాబట్టి తెలివైన విరామం ఎంచుకోండి. ఈ కోసం మీ యాప్‌కు API backend అవసరమైతే, REST API backend recipe ప్రారంభ బిందువు, మరియు REST API ఎలా నిర్మించాలి endpoints డిజైన్ చేయడం వివరిస్తుంది. మీ ఉత్పత్తి కేంద్రం always-on workers లేదా bots అయితే, నిరంతర processes కోసం నిర్మించిన host మీకు మరింత సరిపోవచ్చు.

ప్రశ్నలు