cron மூலம் இயக்கப்படும் மின்னஞ்சல் சரிபார்ப்புகள் ஏன் குளறுபடிகளைச் சந்திக்கின்றன
சில மணிநேரத்திற்கு ஒருமுறை ஒரு வேலையை (job) இயக்குவது காகித அளவில் எளிமையாகத் தோன்றலாம், ஆனால் நடைமுறைச் சூழலில் (production) அது சிக்கலானது. முந்தைய முறை இயங்கியபோது சில செய்திகள் விடுபட்டிருக்கலாம்; மீண்டும் முயற்சிக்கும் பணிகள் (retries) குவிந்துவிடலாம்; அல்லது ஒரு மெதுவான பணியாளர் (worker) பதினைந்து நிமிடங்களுக்கு முன்பே வந்த ஒரு செய்தியை எடுத்துக்கொள்ளலாம். இந்த விடுபட்ட செய்திகள், பெரும்பாலான ஸ்கிரிப்ட்கள் நம்பியிருக்கும் அந்தத் தவறான "சமீபத்திய மின்னஞ்சலே வெல்லும்" (latest email wins) விதியைச் சிதைத்துவிடுகின்றன.
உள்ளூர் சோதனைகள் (Local tests) வெற்றி பெறுகின்றன, ஏனெனில் அவை சுத்தமான இன்பாக்ஸ் மற்றும் கணிக்கக்கூடிய நேரத்துடன் தொடங்குகின்றன. ஆனால் நடைமுறைச் சூழலில் (production), அதே குறியீடு (code) தவறான செய்தியை எடுக்கலாம், ஒரு எச்சரிக்கையைத் தெரியாமலேயேத் தவறவிடலாம் அல்லது ஒரே நேரத்தில் பல அறிவிப்புகளை அனுப்பலாம். குழுக்கள் பெரும்பாலும் தன்னிச்சையான காலதாமதங்களை (arbitrary delays) வைத்து இந்தப் பிரச்சனையைத் தற்காலிகமாகச் சரிசெய்ய முயல்கின்றன, ஆனால் இத்தகைய காலதாமதம் race condition-ஐ மறைக்க மட்டுமே செய்யும்; அதிகப்படியான பணிச்சுமை அல்லது மின்னஞ்சல் தாமத மாற்றங்களின் போது அது விரைவில் தோல்வியடையும்.
லீஸ் (lease) கருத்துரு: ஓர் இன்பாக்ஸை ஒருமுறை பயன்படுத்தக்கூடிய சொத்தாக மாற்றுதல்
ஓர் இன்பாக்ஸ் லீஸ் (inbox lease) என்பது ஒவ்வொரு cron இயக்கமும் கடைபிடிக்க வேண்டிய ஒரு சிறிய ஒப்பந்தமாகும்:
- பிரத்யேக உரிமை (Exclusive ownership) – ஒரு இயக்கம் ஒரு இன்பாக்ஸைப் (அல்லது அதனுள் உள்ள ஒரு தனித்துவமான namespace-ஐ) பெறும்.
- காலவரையறை (Time-bounded) – லீஸ் ஒரு தொடக்க நேரத்தையும் காலாவதி நேரத்தையும் பதிவு செய்கிறது.
- லேபிள் சரிபார்ப்பு (Label verification) – எதிர்பார்க்கப்படும் ஒவ்வொரு மின்னஞ்சலும் ஒரு லேபிளைக் கொண்டிருக்கும், அதை அந்த வேலை சரிபார்க்கும்.
- பழைய செய்தி பாதுகாப்பு (Stale-message guard) – தலைப்பு (subject) பொருந்தினாலும், லீஸ் காலக்கட்டத்திற்கு வெளியே இருக்கும் எந்தவொரு மின்னஞ்சலையும் அந்த வேலை புறக்கணிக்கும்.
"மின்னஞ்சல் வந்ததா?" என்று கேட்பதற்குப் பதிலாக, வேலை இப்போது "எனது லீஸ் காலக்கட்டத்தில் மின்னஞ்சல் வந்ததா?" என்று கேட்கிறது. இந்த மாற்றம், செய்தி தற்போதைய இயக்கத்திற்குச் சொந்தமானது என்பதைச் சரிபார்க்க குறியீட்டைத் தூண்டுகிறது, இதன் மூலம் வெவ்வேறு இயக்கங்களுக்கு இடையிலான கலப்பு (cross-run contamination) தவிர்க்கப்படுகிறது.
ஒரு சாதாரண நான்கு மணிநேர cron-இல் இந்த முறையை எவ்வாறு இணைப்பது
- ஒரு லீஸ் ID-யை (lease ID) உருவாக்கவும் – இயக்கத்தின் தொடக்கத்தில் ஒரு லீஸ் ID-யை உருவாக்கி, தேர்ந்தெடுக்கப்பட்ட இன்பாக்ஸ் ID-யுடன் சேர்த்துச் சேமிக்கவும்.
- கடுமையான வடிகட்டியைப் (strict filter) பயன்படுத்தவும் – தகவல்களைப் பெறும்போது (polling): லீஸ் லேபிள், பெறுநரின் தனித்துவம், குறிப்பிட்ட தலைப்பு மற்றும் மிக முக்கியமாக, பெறப்பட்ட நேர முத்திரை (receive timestamp) ஆகியவற்றின் அடிப்படையில் பொருத்தவும்.
- லீஸ் மெட்டாடேட்டாவை (lease metadata) பதிவு செய்யவும் – லீஸ் ID, இன்பாக்ஸ் ID மற்றும் பொருந்தும் செய்தியின் துல்லியமான பெறப்பட்ட நேரம் ஆகியவற்றைச் சேமிக்கவும்.
பதிவுகளில் (logs) இந்த மூன்று தகவல்களும் இருந்தால், ஒரு தோல்வி ஏற்பட்டால், அது விடுபட்ட லீஸ், தவறான பாதையில் சென்ற இன்பாக்ஸ் அல்லது காலக்கட்டத்திற்கு வெளியே உள்ள மின்னஞ்சல் ஆகியவற்றைக் காட்டும்; "மின்னஞ்சல் எதுவும் காணப்படவில்லை" என்ற தெளிவற்ற செய்தியாக இருக்காது.
தானியங்கி முறையைச் சிதைக்கும் பொதுவான தவறுகள்
- சுத்தமான டேஷ்போர்டுகளுக்காக (dashboards) இன்பாக்ஸ் பெயர்களை மீண்டும் பயன்படுத்துதல் – மனிதர்கள் வாசிக்கக்கூடிய பெயர்கள் அழகாகத் தெரியலாம், ஆனால் அவை பகிர்ந்துகொள்ளப்பட்ட நிலையை (shared state) மீண்டும் உருவாக்குகின்றன.
- பல கோப்புகளில் (files) polling விதிகளைத் தூவி வைத்தல் – நிலையற்ற "புத்துணர்ச்சி" (freshness) வரையறைகள் பழைய செய்திகள் தவறி உள்ளே நுழைய வழிவகுக்கும்.
- லீஸ்-ID பதிவைச் செய்யத் தவறுதல் – அந்த அடையாளங்காட்டி இல்லாமல், பிழைத்திருத்தம் (debugging) வெறும் யூகமாக மாறிவிடும்; இதுவே நிலையற்ற சரிபார்ப்புகள் தொடரக் காரணமாகிறது.
இந்தத் தவறுகளைத் தவிர்ப்பது அமைப்பைத் துல்லியமாகவும், பதிவுகளைப் பயனுள்ளதாகவும் வைத்திருக்கும்.
தனிமைப்படுத்துதல் சாத்தியமில்லாத போது, வடிகட்டிகளை இறுக்கமாக்கவும்
ஒவ்வொரு இயக்கத்திற்கும் ஒரு பிரத்யேக இன்பாக்ஸை உருவாக்குவது நடைமுறைக்குச் சாத்தியமற்றது என்றால், கடுமையான விதிகளின் மூலம் அதைச் சரிசெய்யலாம்:
- பெறப்பட்ட நேரக் காலக்கட்டம் (Receive time window) – லீஸ் தொடக்க நேரத்தை விடப் பழைய எந்தவொரு மின்னஞ்சலையும் நிராகரிக்கவும்.
- பெறுநரின் தனித்துவம் (Recipient uniqueness) – வழங்குநர் அனுமதித்தால், ஒவ்வொரு இயக்கத்திற்கும் ஒரு தனிப்பட்ட முகவரி அல்லது தனித்துவமான விளிம்புப் பெயரைக் (alias) பயன்படுத்தவும்.
- தலைப்பு கைரேகை (Subject fingerprint) – தலைப்பு வரியில் இயக்கத்திற்குத் தனித்துவமான ஒரு டோக்கனை (token) இணைக்கவும்.
ஒரு பகுதி லீஸ் முறையைச் செயல்படுத்தியதே, பிழைத்திருத்தம் செய்வது கடினமாவதற்கு முன்பே நிலை மாற்றத்தைக் (state drift) கணிசமாகக் குறைக்கும்.
எதிர்வாதம்: "வெறுமனே ஒரு காலதாமதத்தைச் சேர்த்தால் போதும்" என்ற கருத்து ஏன் இன்னும் முன்வைக்கப்படுகிறது
சில குழுக்கள் இயக்கங்களுக்கு இடையே சில வினாடிகள் காத்திருப்பது (sleep) போதுமானது என்று வாதிடுகின்றனர். மின்னஞ்சல் தாமதம் (latency) ஒரு குறிப்பிட்ட வரம்பிற்குள் இருக்கும் வரை காலதாமதம் வேலை செய்யும், ஆனால் வழங்குநரின் தாமதம் அதிகரித்தாலோ, தற்காலிகத் தேக்கம் ஏற்பட்டாலோ அல்லது அளவிடுதல் (scaling) நிகழ்வுகள் நடந்தாலோ அந்த அனுமானம் உடனடியாகத் தோல்வியடையும்.
முக்கியக் கருத்து
ஒவ்வொரு இயக்கத்தையும் அதன் சொந்த இன்பாக்ஸுடன் (அல்லது namespace உடன்) இணைப்பதன் மூலமும், எதிர்பார்க்கப்படும் செய்திகளுக்கு லேபிள் இடுவதன் மூலமும், லீஸ் அடையாளங்காட்டிகளைப் பதிவு செய்வதன் மூலமும், நீங்கள் வெவ்வேறு இயக்கங்களுக்கு இடையிலான கலப்பைக் குறைக்கலாம், தோல்விகளைக் கண்காணிக்க முடியும் மற்றும் திட்டமிடப்பட்ட எச்சரிக்கைகளுக்குத் தேவையான நம்பகத்தன்மையை இறுதியாகப் பெறலாம்.