வலை ஆப்பில் background jobs ஐ எப்படி இயக்குவது: Queues, Schedulers மற்றும் Cron
வலை ஆப்பில் background jobs ஐ இயக்க, முதலில் வேலையை இரண்டு வகைகளாகப் பிரியுங்கள். தூண்டப்பட்ட jobs (வரவேற்பு மின்னஞ்சல் அனுப்புவது, ஒரு upload ஐ செயலாக்குவது) job queue இல் சேமிக்கப்பட்டு, மீண்டும் முயற்சிகளுடன் ஒரு worker ஆல் கையாளப்படலாம்; இது பெரும்பாலும் உங்கள் தரவுத்தளத்தில் உள்ள ஓர் அட்டவணை. திட்டமிடப்பட்ட jobs (இரவு அறிக்கை, ஒவ்வொரு 15 நிமிடத்துக்கும் நினைவூட்டல்கள்) கால அட்டவணையில் தூண்டப்படும் ஒன்று தேவை: ஒரு host இன் cron அம்சம், அல்லது உங்கள் ஆப்பில் உள்ள பாதுகாக்கப்பட்ட endpoint ஐ அழைக்கும் ஒரு வெளிப்புற scheduler. jobs இரண்டு முறை இயங்கினாலும் பாதுகாப்பாக இருக்குமாறு எப்போதும் உருவாக்குங்கள், தோல்விகளைப் பதிவு செய்யுங்கள், தூங்கலாம் அல்லது மறுதொடங்கலாம் என்ற சேவையகத்திற்குள் உள்ள timer ஐ ஒருபோதும் நம்பாதீர்கள்.
இந்த வழிகாட்டி விருப்பங்களையும், ஒவ்வொன்றும் எப்போது பொருந்தும் என்பதையும், பூஜ்யத்திற்குக் குறைக்கும் hosts உட்பட, AI app builder உடன் அவற்றை எப்படி அமைப்பது என்பதையும் விளக்குகிறது.
background job என எதைக் கருதுவது
மெதுவானது, நம்பகத்தன்மை இல்லாதது, அல்லது பயனரின் உடனடி பதிலுக்குத் தேவையில்லாத எதுவும்:
- மின்னஞ்சல்கள், அறிவிப்புகள் மற்றும் ரசீதுகளை அனுப்புவது
- படங்களின் அளவை மாற்றுவது, வீடியோவை மாற்றுவது, PDFs உருவாக்குவது
- மெதுவான மூன்றாம் தரப்பு APIs ஐ அழைப்பது, நீண்ட பணிகளுக்கான AI மாதிரிகள் உட்பட
- மற்றொரு அமைப்பிலிருந்து தரவை இறக்குமதி அல்லது ஒத்திசைப்பது
- இரவு சுத்தம் செய்தல், அறிக்கைகள் மற்றும் நினைவூட்டல்கள்
இதை request க்குள்ளேயே செய்தால் பக்கங்கள் மெதுவாகவும் உடையக்கூடியதாகவும் ஆகும்: மின்னஞ்சல் வழங்குநர் கீழே இருந்தால், பயனரின் பதிவுசெய்தல் தோல்வியடையும். பின்னணிக்கு நகர்த்தினால், பயனருக்கு உடனடி பதில் கிடைக்கும், job ஐ மீண்டும் முயற்சிக்கலாம்.
விருப்பங்கள்
| விருப்பம் | எப்படி வேலை செய்கிறது | நன்மைகள் | குறைகள் |
|---|---|---|---|
| அதே செயல்முறையில் fire-and-forget | பதில் அளித்து, பின்னர் சேவையகத்தில் வேலையைத் தொடர்வது | அமைப்பு தேவையில்லை | சேவையகம் நின்றால் இழக்கப்படும்; மீண்டும் முயற்சிகள் இல்லை |
உள்-செயல்முறை timer (setInterval, setTimeout) | இயங்கும் சேவையகத்தில் ஒரு timer | மிக எளிது | தூங்கும்போது இயங்காது; பல நகல்களில் இரட்டிப்பாகும் |
| தரவுத்தளம் சார்ந்த queue | Jobs வரிசைகளாகச் சேமிக்கப்படும்; ஒரு worker அவற்றை எடுத்து இயக்கும் | உங்களிடம் உள்ள தரவுத்தளத்தைப் பயன்படுத்துகிறது; நிலைத்திருக்கும்; ஆய்வு செய்வது எளிது | மீண்டும் முயற்சிகளையும் locking ஐயும் நீங்கள் உருவாக்க வேண்டும்; worker ஐ இயக்க ஏதாவது தேவை |
| பிரத்யேக queue (Redis அடிப்படையிலானது அல்லது நிர்வகிக்கப்பட்டது) | ஒரு queue சேவை மற்றும் workers | முதிர்ச்சியான மீண்டும் முயற்சி மற்றும் திட்டமிடல் அம்சங்கள் | இயக்கி பணம் செலுத்த வேண்டிய மற்றொரு சேவை |
| Hosted job அல்லது workflow சேவை | ஒரு மூன்றாம் தரப்பு, மீண்டும் முயற்சிகள் மற்றும் அட்டவணைகளுடன் உங்கள் endpoints ஐ அழைக்கும் | திட்டமிடலும் மீண்டும் முயற்சிகளும் உங்களுக்காகக் கையாளப்படும் | விற்பனையாளர் சார்பு; இன்னொரு கணக்கும் key உம் |
| ஒரு endpoint ஐ அழைக்கும் வெளிப்புற scheduler | வேறெங்கோ உள்ள timer கால அட்டவணையில் ஒரு HTTP வேண்டுகோளை அனுப்பும் | பூஜ்யத்திற்குக் குறைக்கும் உட்பட, எந்த host இலும் வேலை செய்யும் | குறைந்தபட்ச இடைவெளிகளும் தாமதங்களும்; endpoint ஐப் பாதுகாக்கவும் |
| Host இன் உள்ளமைந்த cron | தளம் ஒரு கட்டளையை அட்டவணையில் இயக்கும் | இருக்கும் இடத்தில் எளிது | எல்லா hosts உம் இதை வழங்குவதில்லை |
ஒரே சரியான பதில் இல்லை. ஒரு சிறிய ஆப்புக்கு பெரும்பாலும் ஒரு தரவுத்தள queue மற்றும் ஒரு வெளிப்புற scheduler மட்டுமே தேவைப்படும்.
பூஜ்யத்திற்குக் குறைக்கும் hosts ஏன் நிலைமையை மாற்றுகின்றன
பல நவீன hosts யாரும் பயன்படுத்தாதபோது உங்கள் ஆப்பைத் தூங்க வைத்து, அடுத்த request இல் எழுப்புகின்றன. அது பணத்தைச் சேமிக்கிறது, ஆனால் தூங்கும் சேவையகம் எந்தக் குறியீட்டையும் இயக்காது: timers இயங்காது, workers polling செய்யாது. இந்த hosts இல், திட்டமிடப்பட்ட வேலை உள்வரும் ஒரு request உடன் தொடங்க வேண்டும், அந்த request க்கான எளிதான மூலம் வெளிப்புற scheduler. ஒவ்வொரு அழைப்பும் ஆப்பை (பெரும்பாலும் அதன் தரவுத்தளத்தையும்) எழுப்பும், எனவே ஒவ்வொரு நிமிடமும் அழைப்பது ஒவ்வொரு 15 நிமிடத்துக்கும் அழைப்பதை விட அதிகம் செலவாகும். தேவையை பூர்த்தி செய்யும் மிக மெதுவான அட்டவணையைத் தேர்ந்தெடுங்கள்.
முறை 1: ஒரு தரவுத்தள job queue
தூண்டப்பட்ட jobs க்கு:
jobsஅட்டவணையை உருவாக்குங்கள்: வகை, payload (JSON), நிலை (pending,running,done,failed), முயற்சிகள், run_after, last_error, நேர முத்திரைகள்.- ஏதாவது நடக்கும்போது, அதற்குக் காரணமான மாற்றத்தின் அதே transaction இல் ஒரு job வரிசையைச் செருகுங்கள், அவை ஒன்றாக வெற்றி அல்லது தோல்வியடையும்.
- ஒரு worker நேரம் வந்த jobs ஐ எடுத்து, அவற்றை
runningஎனக் குறித்து, வேலையைச் செய்துdoneஎனக் குறிக்கும். - தோல்வியில்,
attemptsஐ உயர்த்தி,run_afterஐ பின்னர் அமைத்து (எடுத்துக்காட்டாக 1, 5, பின்னர் 30 நிமிடங்கள்) பிழையைச் சேமியுங்கள். ஒரு அதிகபட்சத்துக்குப் பின், அதைfailedஎனக் குறித்து யாருக்காவது எச்சரிக்கை அனுப்புங்கள்.
ஒரே நேரத்தில் ஒன்றுக்கு மேற்பட்ட workers இயங்கக்கூடும் என்றால், jobs ஐ பாதுகாப்பாக எடுக்க வேண்டும். Postgres இல், SELECT ... FOR UPDATE SKIP LOCKED ஒவ்வொரு worker ம் மோதாமல் வெவ்வேறு வரிசைகளை எடுக்க அனுமதிக்கிறது.
worker ஐ எது இயக்குகிறது? எப்போதும் இயங்கும் சேவையகத்தில், ஒரு தனி செயல்முறையில் ஒரு loop. பூஜ்யத்திற்குக் குறைக்கும் host இல், முறை 2 இல் உள்ள திட்டமிடப்பட்ட endpoint ஒவ்வொரு அழைப்பிலும் நேரம் வந்த jobs இன் தொகுதியைச் செயலாக்க முடியும்.
முறை 2: உங்கள் ஆப்பை அழைக்கும் வெளிப்புற scheduler
திட்டமிடப்பட்ட jobs க்கு:
POST /api/cron/send-remindersபோன்ற ஒரு endpoint ஐச் சேருங்கள்.- அதைப் பாதுகாக்கவும்: ஒரு header இல் ஒரு ரகசிய token ஐக் கோருங்கள், இரு பக்கங்களிலும் ரகசியமாகச் சேமித்து, மற்றதை நிராகரியுங்கள்.
- idempotent ஆக ஆக்குங்கள்: ஒரே நிமிடத்தில் இரண்டு முறை இயக்கினாலும் இரண்டு நினைவூட்டல்கள் அனுப்பக்கூடாது. என்ன அனுப்பப்பட்டது என்பதைப் பதிவு செய்யுங்கள்.
- ஒவ்வொரு அழைப்பையும் குறுகியதாக வையுங்கள்: ஒரு தொகுதியைச் (எடுத்துக்காட்டாக 100 பொருட்கள்) செயலாக்குங்கள், மீதியை அடுத்த அழைப்பு எடுக்கட்டும்.
- அதற்கு ஒரு scheduler ஐ சுட்டிக்காட்டுங்கள்.
Scheduler தேர்வுகள்:
- GitHub Actions திட்டமிடப்பட்ட workflows. GitHub இன் பயன்பாட்டு வரம்புகளுக்குள் இலவசம். 2026 செப்டம்பர் நிலவரப்படி, GitHub இன் ஆவணங்கள் குறுகிய இடைவெளி ஒவ்வொரு 5 நிமிடத்துக்கும் ஒருமுறை என்றும், பரபரப்பான நேரங்களில் (குறிப்பாக ஒவ்வொரு மணி நேரத்தின் தொடக்கத்தில்) இயங்கல் தாமதமாகலாம் என்றும், அட்டவணைகள் இயல்பாக UTC ஐப் பயன்படுத்துகின்றன என்றும், ஒரு பொது repository இல் உள்ள திட்டமிடப்பட்ட workflows 60 நாட்கள் repository செயல்பாடு இல்லாவிட்டால் முடக்கப்படும் என்றும் சொல்கின்றன.
- Hosted cron சேவைகள். ஒரு URL ஐ அட்டவணையில் அழைப்பதே ஒரே வேலையான பல சேவைகள் உள்ளன. ஒன்றைச் சார்ந்திருப்பதற்கு முன் நம்பகத்தன்மை, குறைந்தபட்ச இடைவெளி மற்றும் எச்சரிக்கைகளைச் சரிபாருங்கள்.
- உங்கள் cloud provider இன் scheduler. ஏற்கனவே ஒரு பெரிய cloud provider ஐப் பயன்படுத்தினால், HTTPS endpoint ஐ அழைக்கக்கூடிய நிர்வகிக்கப்பட்ட scheduler அதில் இருக்கும்.
- Hosted job அல்லது workflow சேவை. இவை திட்டமிடல், queues மற்றும் மீண்டும் முயற்சிகளை இணைத்து, ஒவ்வொரு படிக்கும் உங்கள் endpoints ஐ அழைக்கின்றன. ஒவ்வொரு விற்பனையாளரின் தளத்திலும் விலையையும் வரம்புகளையும் ஒப்பிடுங்கள்.
முறை 3: வழங்குநரையே செய்ய விடுங்கள்
சில நேரங்களில் சிறந்த background job எதுவுமே இல்லாததுதான்:
- கட்டணங்கள். Stripe தோல்வியடைந்த சந்தாக் கட்டணங்களை மீண்டும் முயற்சித்து webhooks ஐ அனுப்புகிறது; நீங்கள் polling செய்வதற்குப் பதிலாக அதற்குப் பதிலளிக்கிறீர்கள். webhook என்றால் என்ன ஐப் பாருங்கள்.
- மின்னஞ்சல். நீங்கள் செய்தியை ஒப்படைத்ததும், வழங்குநர்கள் விநியோகத்தை வரிசைப்படுத்தி மீண்டும் முயற்சிக்கின்றனர்.
- மொத்த AI வேலை. OpenAI மற்றும் Anthropic அவசரமில்லாத கோரிக்கைகளுக்கு batch APIs வழங்குகின்றன; நீங்கள் அவற்றைச் சமர்ப்பித்து பின்னர் பெறலாம்.
உங்கள் AI builder க்குக் கொடுக்க வேண்டிய prompts
ஒரு queue க்கு:
எங்கள் தரவுத்தளத்தில் ஒரு jobs அட்டவணையைப் பயன்படுத்தி ஒரு background job queue ஐச் சேருங்கள் (வகை, payload JSON, நிலை, attempts, run_after, last_error). ஒரு பயனர் பதிவுசெய்யும்போது, வரிசையில் அனுப்புவதற்குப் பதிலாக அதே transaction இல் ஒரு send_welcome_email job ஐச் செருகுங்கள். SELECT ... FOR UPDATE SKIP LOCKED உடன் நேரம் வந்த jobs ஐ எடுத்து இயக்கும், தோல்விகளை 1, 5 மற்றும் 30 நிமிடங்களுக்குப் பின் மீண்டும் முயற்சிக்கும், 4 முயற்சிகளுக்குப் பின்
failedஎனக் குறிக்கும் processJobs(limit) செயல்பாட்டைச் சேருங்கள்.
ஒரு திட்டமிடப்பட்ட தூண்டுதலுக்கு:
CRON_SECRET என்ற ரகசியத்திலிருந்து ஒரு bearer token ஆல் பாதுகாக்கப்பட்ட POST /api/cron/tick ஐச் சேருங்கள்; அது இல்லாத எந்த request ஐயும் நிராகரியுங்கள். ஒவ்வொரு அழைப்பும் processJobs(100) ஐ இயக்கி, அடுத்த 24 மணி நேரத்தில் வரவிருக்கும், இன்னும் அனுப்பப்படாத booking நினைவூட்டல்களை அனுப்ப வேண்டும், அனுப்பப்பட்ட நினைவூட்டல்களைப் பதிவு செய்து எதுவும் இரண்டு முறை அனுப்பப்படாமல் பார்த்துக்கொள்ள வேண்டும். என்ன இயங்கியது என்பதன் JSON சுருக்கத்தைத் திருப்பித் தரவும். பின்னர் ஒவ்வொரு 15 நிமிடத்துக்கும் இந்த endpoint ஐ அழைக்கும் ஒரு GitHub Actions workflow ஐ எழுதுங்கள், URL மற்றும் token ஐ repository secrets இலிருந்துப் படிக்க வேண்டும்.
பொதுவான தவறுகள்
setIntervalஐ நம்புவது. சேவையகம் தூங்கும்போது அல்லது மறுதொடங்கும்போது அது அமைதியாக நின்றுவிடும், இரண்டு நகல்கள் இயங்கினால் இரட்டிப்பாகும்.- பாதுகாக்கப்படாத cron endpoint. அதைக் கண்டறிந்த எவரும் உங்கள் jobs ஐ, அல்லது உங்கள் மின்னஞ்சல் பில்லை, தூண்டலாம்.
- idempotent அல்லாத jobs. மீண்டும் முயற்சிகளும் நகல் scheduler அழைப்புகளும் நடக்கும். அவற்றுக்காக வடிவமையுங்கள்.
- தோல்வி தெரிவதற்கான வழி இல்லாதது. ஒரு வாரம் அமைதியாகத் தோல்வியடையும் job, உரக்கத் தோல்வியடையும் job ஐ விட மோசமானது. பிழைகளைப் பதிவு செய்து, மீண்டும் மீண்டும் வரும் தோல்விகளுக்கு எச்சரிக்கை செய்யுங்கள்.
- ஒரே request இல் நீண்ட ஓட்டங்கள். Requests நேரம் முடிந்துவிடும். தொகுதிகளாகச் செயலாக்குங்கள்.
- அடிக்கடி திட்டமிடுவது. பூஜ்யத்திற்குக் குறைக்கும் host இல் ஒவ்வொரு அழைப்பும் ஆப்பை எழுப்பி பில் செய்யும். இடைவெளியை உண்மையான தேவையுடன் பொருத்துங்கள்.
- நேர மண்டலங்கள். "காலை 9" உங்கள் scheduler க்கும் (பெரும்பாலும் UTC) உங்கள் பயனர்களுக்கும் வெவ்வேறு பொருளைத் தரும். நேரங்களை UTC இல் சேமித்து, பயனருக்கு ஏற்ப மாற்றுங்கள்.
- workflow கோப்பில் ரகசியங்கள். Tokens ஐ scheduler இன் ரகசியக் களஞ்சியத்தில் வையுங்கள். API keys ஐ பாதுகாப்பாக வைப்பது எப்படி ஐப் பாருங்கள்.
சரிபார்ப்புப் பட்டியல்
- மெதுவான வேலை பயனர் requests இலிருந்து நகர்த்தப்பட்டுள்ளது
- Jobs நினைவகத்தில் மட்டுமல்லாமல், நிலைத்திருக்கும் வகையில் சேமிக்கப்படுகின்றன
- அதிகரிக்கும் தாமதங்களுடனும் ஒரு அதிகபட்சத்துடனும் மீண்டும் முயற்சிகள்
- ஒவ்வொரு job உம் இரண்டு முறை இயக்கினாலும் பாதுகாப்பானது
- திட்டமிடப்பட்ட endpoint ஒரு ரகசிய token ஆல் பாதுகாக்கப்பட்டுள்ளது
- ஒவ்வொரு ஓட்டமும் வரையறுக்கப்பட்ட தொகுதியைச் செயலாக்குகிறது
- தோல்வியடைந்த jobs தெரியும், எச்சரிக்கைகளுடன்
- hosting செலவை மனதில் வைத்து திட்டமிடல் இடைவெளி தேர்ந்தெடுக்கப்பட்டுள்ளது
- நேரங்கள் UTC இல் சேமிக்கப்படுகின்றன
Mythex இல் background jobs
Mythex இன் ஆவணங்கள் திட்டமிடப்பட்ட அல்லது cron jobs பற்றி விவரிக்கவில்லை, வெளியிடப்பட்ட ஆப்களும் அவற்றின் தரவுத்தளங்களும் செயலற்றபோது தூங்கி, அடுத்த request இல் எழுகின்றன (Hosting வரம்புகள் ஐப் பாருங்கள்). எனவே உங்கள் ஆப்பிற்குள் உள்ள timers ஐ நம்பாதீர்கள். வேலை செய்யும் அணுகுமுறை மேலே உள்ளதுதான்: jobs அட்டவணை மற்றும் token ஆல் பாதுகாக்கப்பட்ட endpoint ஐ agent இடம் கேளுங்கள், பின்னர் வெளியிடப்பட்ட URL இல் ஒரு வெளிப்புற scheduler ஐ சுட்டிக்காட்டுங்கள். Token ஐ ஒரு project secret ஆக வையுங்கள், ஒவ்வொரு விழிப்பும் ஆப்பும் தரவுத்தளமும் விழித்திருக்கும் நேரத்துக்கு credits செலவாகும் என்பதை நினைவில் கொள்ளுங்கள், எனவே நியாயமான இடைவெளியைத் தேர்ந்தெடுங்கள். இதற்கு உங்கள் ஆப்புக்கு API backend தேவைப்பட்டால், REST API backend recipe ஒரு தொடக்கப் புள்ளி, மேலும் REST API ஐ எப்படி உருவாக்குவது endpoints ஐ வடிவமைப்பதை உள்ளடக்குகிறது. உங்கள் தயாரிப்பின் மையமே எப்போதும் இயங்கும் workers அல்லது bots என்றால், நிலைத்திருக்கும் செயல்முறைகளுக்காக கட்டப்பட்ட host உங்களுக்கு மிகப் பொருத்தமாக இருக்கலாம்.
கேள்விகள்
background job என்றால் என்ன?
background job என்பது ஒரு பயனர் காத்திருக்கும் request க்கு வெளியே உங்கள் ஆப் செய்யும் வேலை, எடுத்துக்காட்டாக மின்னஞ்சல் அனுப்புவது, படங்களின் அளவை மாற்றுவது, அறிக்கைகளை உருவாக்குவது அல்லது தரவை ஒத்திசைப்பது. பயனருக்கு விரைவான பதில் கிடைக்கும், job தனியாக இயங்கும், தோல்வியடைந்தால் மீண்டும் முயற்சிக்கலாம்.
என் host இல் cron இல்லை என்றால் திட்டமிடப்பட்ட பணியை எப்படி இயக்குவது?
வேலையைச் செய்யும் பாதுகாக்கப்பட்ட endpoint ஒன்றைச் சேர்த்து, ஒரு வெளிப்புற scheduler அதை ஒரு கால அட்டவணையில் அழைக்குமாறு செய்யுங்கள். திட்டமிடப்பட்ட GitHub Actions workflow, hosted cron சேவை, அல்லது உங்கள் cloud provider இன் scheduler ஆகியவை விருப்பங்கள். endpoint ஐ ஒரு ரகசிய token மூலம் பாதுகாக்கவும்.
திட்டமிடப்பட்ட jobs க்கு setInterval அல்லது setTimeout ஐப் பயன்படுத்தலாமா?
எப்போதும் இயங்கும் சேவையகத்தில் சிறிய, முக்கியமற்ற பணிகளுக்கு மட்டும். சேவையகம் மறுதொடக்கம் ஆனாலோ, பூஜ்யத்திற்குக் குறைந்தாலோ, அல்லது பல நகல்களாக இயங்கினாலோ, timers இழக்கப்படும் அல்லது ஒன்றுக்கு மேல் முறை இயங்கும். திட்டமிடப்பட்ட பணியை ஒரு தரவுத்தளத்தில் சேமிக்கவும் அல்லது அதற்குப் பதிலாக ஒரு scheduler ஐப் பயன்படுத்தவும்.
Mythex cron jobs ஐ ஆதரிக்கிறதா?
Mythex இன் ஆவணங்கள் திட்டமிடப்பட்ட அல்லது cron jobs பற்றி விவரிக்கவில்லை, வெளியிடப்பட்ட ஆப்கள் செயலற்றபோது தூங்குகின்றன. நம்பகமான அணுகுமுறை, உங்கள் ஆப்பில் உள்ள பாதுகாக்கப்பட்ட endpoint ஐ ஒரு வெளிப்புற scheduler அழைப்பது; அது ஆப்பை எழுப்பி வேலையை இயக்கும்.