"வேகமும் சரியானது என்பதும் ஒன்றல்ல" என்பதை உணரும் வரை அனைவரும் நிகழ்நேரப் புதுப்பிப்புகளை (real-time updates) விரும்புகிறார்கள். ஒரு பரவலாக்கப்பட்ட அமைப்பில் (distributed system), நிகழ்வுகள் ஒளியின் வேகத்தில் பயணித்தாலும், அவை தவறான வரிசையில் வந்து சேரக்கூடும். WebSockets துண்டிக்கப்பட்டு மீண்டும் இணையலாம். Message brokers தரவுப் பொட்டலங்களை (packets) மீண்டும் அனுப்பலாம். Background workers timeout ரத்துகளுக்கு எதிராகப் போட்டியிடலாம். இதன் விளைவு? ஒரு கிளையண்ட் நிகழ்வு 42-ஐப் பார்த்துவிட்டு, பிறகு நிகழ்வு 40-ஐப் பார்க்கலாம், அல்லது அமைப்பு ஏற்கனவே நிகழ்வு 45-இல் உள்ளது என்று கூறும் ஒரு ஸ்னாப்ஷாட்டைப் பார்க்கலாம். நீங்கள் நீண்ட நேரம் இயங்கும் ஏஜென்ட் பணிப்பாய்வுகளை (agent workflows) உருவாக்குகிறீர்கள் என்றால், அந்த குழப்பம் ஒரு அரிதான நிகழ்வு (edge case) அல்ல; அதுவே அடிப்படை நிலை. விநியோக நேரத்தைக் குறைக்க முயற்சிப்பதற்கு முன், உங்கள் நிகழ்வுகளின் வரிசையைச் சரிசெய்யுங்கள்.
"நிகழ்நேரம்" என்பதன் குழப்பமான யதார்த்தம்
நிகழ்நேரம் என்பது ஒரு கடத்துத் தன்மை (transport property). அது ஒரு தரவுப் பொட்டலம் எவ்வளவு வேகமாக ஒரு கம்பியின் வழியாக நகர்கிறது என்பதை விவரிக்கிறதே தவிர, அது சொல்லும் கதை அர்த்தமுள்ளதா இல்லையா என்பதை அல்ல. நீண்ட நேரம் இயங்கும் பணிகள் ஒவ்வொரு முரண்பாட்டையும் அதிகப்படுத்துகின்றன, ஏனெனில் அவை காலத்தைப் பரப்பிக் கொள்கின்றன. ஒரு மாடல் பயிற்சிப் பணி (model training job), பல படிநிலை ஒப்புதல் ஓட்டம் (multi-step approval flow), அல்லது ஒரு வீடியோ ரெண்டரிங் வழிமுறை (video rendering pipeline) ஆகியவை நிமிடங்கள் அல்லது மணிநேரங்களில் டஜன் கணக்கான நிகழ்வுகளை வெளியிடலாம். அந்த இடைவெளியில், எது வேண்டுமானாலும் தவறாக நடக்கலாம்.
ஒரு உறுதிப்படுத்தல் (acknowledgement) தொலைந்து போவதால் ஒரு புரோக்கர் செய்தியை மீண்டும் அனுப்ப முயலலாம். ஒரு லோட் பேலன்சர் (load balancer) இரண்டு நிகழ்வுகளை வெவ்வேறு நெட்வொர்க் பாதைகளில் வழிநடத்தலாம், இதனால் புதிய நிகழ்வு முதலில் வந்து சேரக்கூடும். ஒரு வொர்க்கர் செயல்முறை (worker process) தரவுத்தளத்தில் எழுதிய பிறகு ஆனால் வெற்றிகரமான நிகழ்வை வெளியிடுவதற்கு முன்பே செயலிழக்கலாம், அதன் பிறகு இரண்டாவது வொர்க்கர் அந்தப் பணியை எடுத்துக்கொண்டு அதன் சொந்த முன்னேற்றத்தை வெளியிடலாம். உங்கள் முன்பக்கத் திரை (frontend) சமீபத்திய செய்தியே உண்மையான செய்தி என்று கருதினால், அது ஒருபோதும் இல்லாத ஒரு நிலையைத் திரையில் காட்டும். பயனர்கள் "முடிக்கப்பட்டது" (completed) என்ற அடையாளக் குறியீடு திடீரென "செயலில் உள்ளது" (processing) என மாறுவதையோ, அல்லது அதைவிட மோசமாக, ரத்து செய்யப்பட்ட ஒரு பணி திடீரென மீண்டும் உயிர்த்தெறுவதையோ பார்ப்பார்கள். வரிசை முறை இல்லாத வேகம் என்பது அதிக வேகத்தில் நடக்கும் குழப்பமேயாகும்.
வரிசை எண்களே உண்மையான கடிகாரம்
இதற்கான தீர்வு, உற்பத்தியாளரால் (producer) உருவாக்கப்படும் கண்டிப்பான, ஏறுவரிசை வரிசை எண்கள் (monotonic sequence numbers) ஆகும். நிலையை மாற்றும் ஒவ்வொரு செயல்பாட்டிற்கும், இடைவெளிகள் இல்லாமலும், பின்னோக்கிச் செல்லாமலும் சரியாக ஒன்று அதிகரிக்கும் ஒரு எண் வழங்கப்பட வேண்டும். அந்த எண் நிகழ்வோடு சேர்த்து அதே பரிவர்த்தனையில் (transaction) சேமிக்கப்பட வேண்டும். தரவுத்தள வரிசை (database row) புதுப்பிக்கப்பட்டு, ஆனால் வரிசை எண் உறுதிப்படுத்தல் (sequence commit) தோல்வியடைந்தால், இரண்டையும் ரத்து செய்ய வேண்டும். இது தர்க்கரீதியான காலவரிசையை நிலைப் மாற்றத்துடன் அணுக்கமானதாக (atomic) வைத்திருக்கும்.
நிகழ்வு ஐடிகள் (Event IDs) இன்னும் பயனுள்ளவைதான், ஆனால் அவை வேறு ஒரு சிக்கலைத் தீர்க்கின்றன. ஒரு நிகழ்வு ஐடி ஒரு குறிப்பிட்ட தரவுப் பகுதியை (payload) அடையாளம் காட்டுகிறது, இதனால் புரோக்கர் ஒரே செய்தியை இரண்டு முறை அனுப்பும்போது நீங்கள் நகல்களை நீக்க முடியும். மறுபுறம், ஒரு வரிசை எண் அந்தத் தரவுப் பகுதி காரணத் தொடர்புச் சங்கிலியில் (causal chain) எங்குள்ளது என்பதை உங்களுக்குச் சொல்கிறது. அது விடுபட்ட இடங்களைக் காட்டுகிறது. அது வரிசையைக் காட்டுகிறது. ஒரு நேர முத்திரை (timestamp) இவை இரண்டையும் செய்வதில்லை. கடிகாரங்கள் விலகலாம் (drift), NTP பின்னோக்கிச் செல்லலாம் மற்றும் விர்ச்சுவல் மெஷின்கள் தற்காலிகமாகத் தடைபடலாம். நேர முத்திரைகளைத் திரையில் காண்பிக்க மட்டுமே பயன்படுத்தவும், உதாரணமாக "3 நிமிடங்களுக்கு முன்பு தொடங்கியது" என்பது போன்ற பயன்பாட்டிற்கு மட்டுமே பயன்படுத்தவும்; வணிகத் தர்க்கத்திற்கான (business logic) வரிசைப்படுத்தும் திறவுகோலாக (sorting key) ஒருபோதும் பயன்படுத்த வேண்டாம்.
கிளையண்ட் (Client) தரவு ஓட்டத்தை எவ்வாறு கையாள வேண்டும்
உற்பத்தியாளர் ஒரு தொடர்ச்சியான வரிசையை உறுதி செய்தவுடன், நுகர்வோருக்கு (consumer) எளிமையான, கடினமான விதிகள் கிடைப்பார்கள். உள்வரும் வரிசை எண் கடைசியாகப் பயன்படுத்தப்பட்ட எண்ணிற்கு சமமாகவோ அல்லது குறைவாகவோ இருந்தால், அதைத் தவிர்த்துவிடவும். அது ஒரு நகலாகவோ அல்லது காலாவதியான தாமதமான செய்தியாகவோ இருக்கலாம். வரிசை எண் கடைசியாகப் பயன்படுத்தப்பட்ட எண்ணை விட சரியாக ஒன்று அதிகமாக இருந்தால், அதை உடனடியாகப் பயன்படுத்தவும். அதுவே சரியான வழி (happy path). வரிசை எண் திடீரெனத் தாண்டினால், உதாரணமாக நீங்கள் 12-ஐ எதிர்பார்த்துவிட்டு 15-ஐப் பெற்றால், ஏதோ ஒன்று விடுபட்டுள்ளது என்று அர்த்தம். புதிய நிகழ்வைத் தற்காலிகமாகச் சேமித்து வைத்து (buffer), அடுத்த எதிர்பார்க்கப்படும் வரிசையிலிருந்து மீண்டும் இயக்க (replay) சர்வரிடம் கேட்கவும். யூகிக்க வேண்டாம். இடைவெளி முக்கியமில்லை என்று நம்பி அடுத்தடுத்த நிகழ்வுகளுக்குத் தாவ வேண்டாம்.
இறுதி நிலைகளை (Terminal states) மாற்ற முடியாதவையாகக் கருத வேண்டும். ஒரு பணி முடிக்கப்பட்டதாகவோ, தோல்வியடைந்ததாகவோ அல்லது ரத்து செய்யப்பட்டதாகவோ குறிக்கப்பட்டால், அந்தச் செயல்பாட்டிற்கான அடுத்தடுத்த நிலைப் மாற்றங்களை கிளையண்ட் நிராகரிக்க வேண்டும். இது மிகவும் எளிமையானதாகத் தோன்றலாம், ஆனால் நீங்கள்...