விநியோகிக்கப்பட்ட அமைப்புகளில் நம்பகமான செய்தியிடல்

இரட்டை எழுதுதல் பிரச்சனை நம்பகமான, மிகவும் கிடைக்கக்கூடிய, அளவிடக்கூடிய விநியோகிக்கப்பட்ட அமைப்பை உருவாக்க, குறிப்பிட்ட நுட்பங்கள், கொள்கைகள் மற்றும் வடிவங்களைக் கடைப்பிடிக்க வேண்டும். இத்தகைய அமைப்புகளின் வடிவமைப்பு எண்ணற்ற சவால்களை எதிர்கொள்வதை உள்ளடக்கியது. மிகவும் பொதுவான மற்றும் அடிப்படை சிக்கல்களில் உள்ளது. இரட்டை எழுதும் பிரச்சனை என்பது விநியோகிக்கப்பட்ட அமைப்புகளில் எழும் ஒரு சவாலாகும், முக்கியமாக பல தரவு மூலங்கள் அல்லது தரவுத்தளங்கள் ஒத்திசைக்கப்பட வேண்டும். தரவு முரண்பாடுகள், முரண்பாடுகள் அல்லது செயல்திறன் இடையூறுகள் போன்ற சிக்கல்களை அறிமுகப்படுத்தாமல், தரவுத்தளங்கள் அல்லது தற்காலிக சேமிப்புகள் போன்ற பல்வேறு தரவு அங்காடிகளில் தரவு மாற்றங்கள் தொடர்ந்து எழுதப்படுவதை உறுதி செய்வதில் உள்ள சிரமத்தை இது குறிக்கிறது. "இரட்டை எழுதுதல் சிக்கல்" மைக்ரோ சர்வீஸ் கட்டமைப்பு மற்றும் ஒரு சேவைக்கான பேட்டர்ன் தரவுத்தளமானது, சுயாதீனமான வரிசைப்படுத்தல் மற்றும் அளவிடுதல், தனிமைப்படுத்தப்பட்ட தோல்விகள் மற்றும் வளர்ச்சி வேகத்தின் சாத்தியமான ஊக்கம் போன்ற பல நன்மைகளைத் தருகிறது. இருப்பினும், செயல்பாடுகளுக்கு பல மைக்ரோ சர்வீஸ்களில் மாற்றங்கள் தேவைப்படுகின்றன, இந்த சிக்கலைச் சமாளிக்க நம்பகமான தீர்வைப் பற்றி சிந்திக்க உங்களை கட்டாயப்படுத்துகிறது. கிட்டத்தட்ட ஒரு உண்மையான உதாரணம் எங்கள் டொமைனில் கடன் விண்ணப்பங்களை ஏற்றுக்கொள்வது, அவற்றை மதிப்பிடுவது மற்றும் வாடிக்கையாளர்களுக்கு அறிவிப்பு விழிப்பூட்டல்களை அனுப்புவது போன்றவற்றைக் கருத்தில் கொள்வோம். ஒற்றைப் பொறுப்புக் கொள்கை, கான்வேயின் சட்டம் மற்றும் டொமைன் சார்ந்த வடிவமைப்பு அணுகுமுறை ஆகியவற்றின் அடிப்படையில், பல நிகழ்வு-புயல் அமர்வுகளுக்குப் பிறகு, முழு டொமைனும் மூன்று துணை டொமைன்களாகப் பிரிக்கப்பட்டது, வரையறுக்கப்பட்ட எல்லைக்குட்பட்ட சூழல்கள் தெளிவான எல்லைகள், டொமைன் மாதிரிகள் மற்றும் எங்கும் நிறைந்த மொழி. புதிய கடன் விண்ணப்பங்களை உள்வாங்குதல் மற்றும் தொகுத்தல் ஆகியவற்றுடன் பணிபுரிகிறது. அமைப்பு இந்த பயன்பாடுகளை மதிப்பீடு செய்து, வழங்கப்பட்ட தரவின் அடிப்படையில் முடிவுகளை எடுக்கிறது. KYC/KYB, ஆண்டிஃபிராட் மற்றும் கிரெடிட் ரிஸ்க் காசோலைகள் உள்ளிட்ட இந்த மதிப்பீட்டுச் செயல்முறையானது நேரத்தைச் செலவழிக்கும், ஆயிரக்கணக்கான விண்ணப்பங்களை ஒரே நேரத்தில் கையாளும் திறனைத் தேவைப்படுத்துகிறது. இதன் விளைவாக, இந்த செயல்பாடு அதன் சொந்த தரவுத்தளத்துடன் ஒரு பிரத்யேக மைக்ரோ சர்வீஸுக்கு ஒப்படைக்கப்பட்டது, இது சுயாதீனமான அளவிடுதலை அனுமதிக்கிறது. முதலாவது இரண்டாவது மேலும், இந்த துணை அமைப்புகள் இரண்டு வெவ்வேறு குழுக்களால் நிர்வகிக்கப்படுகின்றன, ஒவ்வொன்றும் அதன் சொந்த வெளியீட்டு சுழற்சிகள், சேவை நிலை ஒப்பந்தங்கள் (SLA) மற்றும் அளவிடுதல் தேவைகள். , வாடிக்கையாளர்களுக்கு விழிப்பூட்டல்களை அனுப்ப ஒரு சிறப்பு அறிவிப்பு சேவை உள்ளது. கடைசியாக சிஸ்டத்தின் முதன்மை பயன்பாட்டு வழக்கின் சுத்திகரிக்கப்பட்ட விளக்கம் இங்கே: ஒரு வாடிக்கையாளர் கடன் விண்ணப்பத்தை சமர்ப்பிக்கிறார். கடன் விண்ணப்பச் சேவையானது புதிய விண்ணப்பத்தை "நிலுவையிலுள்ள" நிலையில் பதிவுசெய்து, மதிப்பீட்டுச் சேவைக்கு விண்ணப்பத்தை அனுப்புவதன் மூலம் மதிப்பீட்டுச் செயல்முறையைத் தொடங்குகிறது. மதிப்பீட்டுச் சேவை உள்வரும் கடன் விண்ணப்பத்தை மதிப்பிட்டு, அதன்பின் கடன் விண்ணப்பச் சேவைக்கு முடிவைத் தெரிவிக்கும். முடிவைப் பெற்றவுடன், கடன் விண்ணப்பச் சேவையானது அதற்கேற்ப கடன் விண்ணப்ப நிலையைப் புதுப்பித்து, அதன் முடிவை வாடிக்கையாளருக்குத் தெரிவிக்க அறிவிப்புச் சேவையைத் தூண்டுகிறது. அறிவிப்புச் சேவை இந்தக் கோரிக்கையைச் செயல்படுத்துகிறது மற்றும் வாடிக்கையாளரின் அமைப்புகளுக்கு ஏற்ப மின்னஞ்சல், SMS அல்லது பிற விருப்பமான தகவல் தொடர்பு முறைகள் மூலம் வாடிக்கையாளருக்கு அறிவிப்புகளை அனுப்புகிறது. இது முதல் பார்வையில் மிகவும் எளிமையான மற்றும் பழமையான அமைப்பாகும், ஆனால் கடன் விண்ணப்பச் சேவை சமர்ப்பிக்கும் கடன் விண்ணப்பக் கட்டளையை எவ்வாறு செயல்படுத்துகிறது என்பதைப் பற்றி பார்ப்போம். சேவை தொடர்புகளுக்கான இரண்டு அணுகுமுறைகளை நாம் பரிசீலிக்கலாம்: இந்த அணுகுமுறையில், சேவை அதன் உள்ளூர் தரவுத்தளத்தை மேம்படுத்துகிறது (உறுதிப்படுத்துகிறது) பின்னர் ஒரு நிகழ்வு அல்லது செய்தியை பிற சேவைகளுக்கு வெளியிடுகிறது. முதல்-உள்ளூர்-கமிட்-பிறகு-வெளியிடு: மாறாக, இந்த முறையானது உள்ளூர் தரவுத்தளத்தில் மாற்றங்களைச் செய்வதற்கு முன் ஒரு நிகழ்வு அல்லது செய்தியை வெளியிடுவதை உள்ளடக்குகிறது. முதலில் வெளியிடு-பிறகு-உள்ளூர்-உறுதி: இரண்டு முறைகளும் அவற்றின் குறைபாடுகளைக் கொண்டுள்ளன மற்றும் விநியோகிக்கப்பட்ட அமைப்புகளில் தகவல்தொடர்புக்கு ஓரளவு மட்டுமே தோல்வியடையும். இது முதல் அணுகுமுறையைப் பயன்படுத்துவதற்கான வரிசை வரைபடம். இந்தச் சூழ்நிலையில், கடன் விண்ணப்பச் சேவையானது அணுகுமுறையைப் பயன்படுத்துகிறது, அங்கு அது முதலில் ஒரு பரிவர்த்தனையைச் செய்து பின்னர் மற்றொரு அமைப்பிற்கு அறிவிப்பை அனுப்ப முயற்சிக்கிறது. எவ்வாறாயினும், எடுத்துக்காட்டாக, பிணையச் சிக்கல்கள், மதிப்பீட்டுச் சேவை கிடைக்கவில்லை அல்லது கடன் விண்ணப்பச் சேவையானது நினைவாற்றல் இல்லாத (OOM) பிழையை எதிர்கொண்டு செயலிழந்தால் இந்த செயல்முறை தோல்வியடையும். இதுபோன்ற சந்தர்ப்பங்களில், கூடுதல் நடவடிக்கைகள் செயல்படுத்தப்படாவிட்டால், புதிய கடன் விண்ணப்பத்தின் அறிவிப்பு இல்லாமல் மதிப்பீட்டில் இருந்து செய்தி தொலைந்துவிடும். முதல்-உள்ளூர்-கமிட்-பின்-பப்ளிஷ் மற்றும் இரண்டாவது. சூழ்நிலையில், கடன் விண்ணப்பச் சேவை மிகவும் குறிப்பிடத்தக்க அபாயங்களை எதிர்கொள்கிறது. இது ஒரு புதிய பயன்பாட்டைப் பற்றி மதிப்பீட்டுச் சேவைக்குத் தெரிவிக்கலாம், ஆனால் தரவுத்தளச் சிக்கல்கள், நினைவகப் பிழைகள் அல்லது குறியீடு பிழைகள் போன்ற பிரச்சனைகளால் இந்தப் புதுப்பிப்பை உள்நாட்டில் சேமிக்க முடியவில்லை. இந்த அணுகுமுறை தரவுகளில் குறிப்பிடத்தக்க முரண்பாடுகளுக்கு வழிவகுக்கும், இது கடன் மதிப்பாய்வு சேவை உள்வரும் விண்ணப்பங்களை எவ்வாறு கையாளுகிறது என்பதைப் பொறுத்து கடுமையான சிக்கல்களை ஏற்படுத்தலாம். முதல்-வெளியீடு-பின்னர்-உள்ளூர்-கமிட் எனவே, வெளிப்புற நுகர்வோருக்கு நிகழ்வுகளை வெளியிடுவதற்கான வலுவான பொறிமுறையை வழங்கும் ஒரு தீர்வை நாம் அடையாளம் காண வேண்டும். ஆனால், சாத்தியமான தீர்வுகளை ஆராய்வதற்கு முன், விநியோகிக்கப்பட்ட அமைப்புகளில் அடையக்கூடிய செய்தி விநியோக உத்தரவாதங்களின் வகைகளை நாம் முதலில் தெளிவுபடுத்த வேண்டும். செய்தி விநியோக உத்தரவாதம் நாம் அடையக்கூடிய நான்கு வகையான உத்தரவாதங்கள் உள்ளன. உத்தரவாதம் இல்லை சேருமிடத்திற்குச் செய்தி அனுப்பப்படும் என்பதற்கு எந்த உத்தரவாதமும் இல்லை. என்ற அணுகுமுறை துல்லியமாக இதைப் பற்றியது. நுகர்வோர் ஒருமுறை, பலமுறை செய்திகளைப் பெறலாம் அல்லது ஒரு போதும் செய்திகளைப் பெறலாம். முதல்-உள்ளூர்-கமிட்-பின்-பப்ளிஷ் அதிகபட்சம் ஒரு முறை டெலிவரி அதிக பட்சம் ஒரு முறை டெலிவரி என்றால், அந்தச் செய்தி அதிகபட்சம் 1 முறை இலக்குக்கு அனுப்பப்படும். என்ற அணுகுமுறையை இந்த வழியில் செயல்படுத்தலாம், அதே போல் மதிப்பு ஒன்று கொண்ட முயற்சிகளின் மறுமுயற்சி கொள்கையுடன். முதல்-உள்ளூர்-உறுதி-பிறகு-வெளியீடு குறைந்தபட்சம் ஒருமுறை டெலிவரி\நுகர்வோர் ஒவ்வொரு செய்தியையும் பெறுவார்கள் மற்றும் செயலாக்குவார்கள் ஆனால் ஒரே செய்தியை ஒன்றுக்கு மேற்பட்ட முறை பெறலாம். சரியாக ஒரு முறை டெலிவரி\சரியாக ஒரு முறை டெலிவரி செய்தால், நுகர்வோர் ஒரு முறை செய்தியை திறம்படப் பெறுவார்கள். தொழில்நுட்ப ரீதியாக, காஃப்கா பரிவர்த்தனைகள் மற்றும் உற்பத்தியாளர் மற்றும் நுகர்வோரின் குறிப்பிட்ட செயலற்ற செயல்பாட்டின் மூலம் சாதிக்க முடியும். பெரும்பாலான சந்தர்ப்பங்களில், டெலிவரி உத்தரவாதங்கள், செய்திகள் ஒரு முறையாவது வழங்கப்படுவதை உறுதி செய்வதன் மூலம் பல சிக்கல்களைத் தீர்க்கும், ஆனால் நுகர்வோர் சக்தியற்றவர்களாக இருக்க வேண்டும். இருப்பினும், தவிர்க்க முடியாத நெட்வொர்க் தோல்விகளைக் கருத்தில் கொண்டு, தயாரிப்பாளரின் உத்தரவாதங்களைப் பொருட்படுத்தாமல், நகல் செய்திகளைச் செயலாக்குவதைத் தவிர்ப்பதற்கு அனைத்து நுகர்வோர் தர்க்கங்களும் உறுதியானதாக இருக்க வேண்டும். எனவே, இந்த தேவை ஒரு குறைபாடு அல்ல, ஏனெனில் இது யதார்த்தத்தை பிரதிபலிக்கிறது. 'குறைந்தபட்சம் ஒருமுறை' தீர்வுகள் இந்த சிக்கலுக்கு ஏராளமான தீர்வுகள் உள்ளன, அவற்றின் நன்மைகள் மற்றும் தீமைகள் உள்ளன. இரண்டு கட்ட உறுதி விக்கிப்பீடியாவின் படி, இரண்டு-கட்ட கமிட் (2PC) என்பது விநியோகிக்கப்பட்ட பரிவர்த்தனைகளின் நிலைத்தன்மை மற்றும் நம்பகத்தன்மையை உறுதிப்படுத்த கணினி அறிவியல் மற்றும் தரவுத்தள மேலாண்மை அமைப்புகளில் பயன்படுத்தப்படும் விநியோகிக்கப்பட்ட பரிவர்த்தனை நெறிமுறை ஆகும். பல வளங்கள் (எ.கா., தரவுத்தளங்கள்) ஒரு பரிவர்த்தனையில் பங்கேற்க வேண்டிய சூழ்நிலைகளுக்காக இது வடிவமைக்கப்பட்டுள்ளது, மேலும் அவை அனைத்தும் பரிவர்த்தனை செய்வதை உறுதி செய்கிறது அல்லது அவை அனைத்தும் அதைத் தடுக்கிறது, அதன் மூலம் தரவு நிலைத்தன்மையை பராமரிக்கிறது. இது நமக்குத் தேவையானதாகத் தெரிகிறது, ஆனால் இரண்டு-கட்ட கமிட்டியில் பல குறைபாடுகள் உள்ளன: ஒரு பங்கேற்பு ஆதாரம் பதிலளிக்கவில்லை அல்லது தோல்வியை சந்தித்தால், சிக்கல் தீர்க்கப்படும் வரை முழு செயல்முறையும் தடுக்கப்படும். இது சாத்தியமான செயல்திறன் மற்றும் கிடைக்கும் சிக்கல்களுக்கு வழிவகுக்கும். இரண்டு-கட்ட கமிட் உள்ளமைக்கப்பட்ட தவறு சகிப்புத்தன்மை வழிமுறைகளை வழங்காது. இது தோல்விகளைக் கையாள வெளிப்புற வழிமுறைகள் அல்லது கைமுறையான தலையீட்டை நம்பியுள்ளது. அனைத்து நவீன தரவுத்தளங்களும் இரண்டு-கட்ட உறுதிமொழியை ஆதரிக்கவில்லை. பகிரப்பட்ட தரவுத்தளம் மைக்ரோ சர்வீஸ் கட்டிடக்கலைக்கான மிகவும் வெளிப்படையான தீர்வானது ஒரு வடிவத்தைப் பயன்படுத்துவதாகும் (அல்லது சில சமயங்களில் எதிர்ப்பு வடிவமும் கூட) - பகிரப்பட்ட தரவுத்தளமாகும். வெவ்வேறு தரவுத்தளங்களில் உள்ள பல அட்டவணைகளில் பரிவர்த்தனை நிலைத்தன்மை தேவைப்பட்டால், இந்த மைக்ரோ சர்வீஸுக்கு ஒரு பகிரப்பட்ட தரவுத்தளத்தைப் பயன்படுத்தினால், இந்த அணுகுமுறை மிகவும் உள்ளுணர்வுடன் இருக்கும். இந்த அணுகுமுறையின் குறைபாடுகளில் தோல்வியின் ஒரு புள்ளியை அறிமுகப்படுத்துதல், சுயாதீன தரவுத்தள அளவைத் தடுப்பது மற்றும் குறிப்பிட்ட தேவைகள் மற்றும் பயன்பாட்டு நிகழ்வுகளுக்கு மிகவும் பொருத்தமான பல்வேறு தரவுத்தள தீர்வுகளைப் பயன்படுத்துவதற்கான திறனைக் கட்டுப்படுத்துதல் ஆகியவை அடங்கும். கூடுதலாக, விநியோகிக்கப்பட்ட பரிவர்த்தனையின் அத்தகைய வடிவத்தை ஆதரிக்க மைக்ரோ சர்வீஸ் கோட்பேஸ்களில் மாற்றங்கள் அவசியம். பரிவர்த்தனை அவுட்பாக்ஸ் ' ' என்பது நம்பகத்தன்மையற்ற செய்தியிடல் அமைப்புகளின் முகத்திலும் கூட, நம்பகமான செய்தி பரப்புதலை உறுதிசெய்ய விநியோகிக்கப்பட்ட அமைப்புகளில் பயன்படுத்தப்படும் வடிவமைப்பு வடிவமாகும். செயல்பாட்டின் அதே பரிவர்த்தனைக்குள், நியமிக்கப்பட்ட 'அவுட்பாக்ஸ் நிகழ்வுகள்' அட்டவணையில் நிகழ்வுகளைச் சேமிப்பதை இது உள்ளடக்குகிறது. இந்த அணுகுமுறை தொடர்புடைய தரவுத்தளங்களின் ACID பண்புகளுடன் நன்றாக இணைகிறது. இதற்கு நேர்மாறாக, பல No-SQL தரவுத்தளங்கள் ACID பண்புகளை முழுமையாக ஆதரிக்கவில்லை, மாறாக CAP தேற்றம் மற்றும் BASE தத்துவத்தின் கொள்கைகளைத் தேர்ந்தெடுக்கின்றன, இது கடுமையான நிலைத்தன்மையைக் காட்டிலும் கிடைக்கும் மற்றும் இறுதியில் நிலைத்தன்மைக்கு முன்னுரிமை அளிக்கிறது. பரிவர்த்தனை அவுட்பாக்ஸ் ஒரு பரிவர்த்தனை அவுட்பாக்ஸ் அளிக்கிறது மற்றும் பல அணுகுமுறைகளுடன் செயல்படுத்தப்படலாம்: குறைந்தபட்சம் ஒரு முறை உத்தரவாதத்தை பரிவர்த்தனை பதிவு தையல் கருத்துக்கணிப்பு வெளியீட்டாளர் அணுகுமுறை CDC (தரவு பிடிப்பை மாற்று) போன்ற தரவுத்தள-குறிப்பிட்ட தீர்வுகளைப் பயன்படுத்துவதைக் குறிக்கிறது. அந்த அணுகுமுறையின் முக்கிய குறைபாடுகள்: பரிவர்த்தனை பதிவு டெய்லிங் தரவுத்தள குறிப்பிட்ட தீர்வுகள் CDC செயலாக்கங்களின் பிரத்தியேகங்கள் காரணமாக அதிகரித்த தாமதம் மற்றொரு முறை ஆகும், இது அவுட்பாக்ஸ் அட்டவணையை வாக்களிப்பதன் மூலம் அவுட்பாக்ஸ் ஆஃப்லோடிங்கை எளிதாக்குகிறது. இந்த அணுகுமுறையின் முதன்மையான குறைபாடு தரவுத்தள சுமை அதிகரிப்பதற்கான சாத்தியமாகும், இது அதிக செலவுகளுக்கு வழிவகுக்கும். மேலும், அனைத்து No-SQL தரவுத்தளங்களும் குறிப்பிட்ட ஆவணப் பிரிவுகளுக்கான திறமையான வினவலை ஆதரிக்காது. முழு ஆவணங்களையும் பிரித்தெடுப்பது, எனவே, செயல்திறன் சிதைவை ஏற்படுத்தும். வாக்குப்பதிவு வெளியீட்டாளர் இது எவ்வாறு செயல்படுகிறது என்பதை விளக்கும் ஒரு சிறிய வரிசை வரைபடம் இங்கே உள்ளது. நீங்களே கேளுங்கள் பரிவர்த்தனை அவுட்பாக்ஸ் வடிவத்தின் முதன்மையான சவால், தரவுத்தள ACID பண்புகளில் அதன் சார்புநிலையில் உள்ளது. இது வழக்கமான OLTP தரவுத்தளங்களில் நேரடியானதாக இருக்கலாம் ஆனால் NoSQL சாம்ராஜ்யத்தில் சவால்களை ஏற்படுத்துகிறது. இதை நிவர்த்தி செய்ய, கோரிக்கை செயலாக்கத்தைத் தொடங்குவதிலிருந்தே, பின்னிணைப்பு பதிவை (உதாரணமாக, காஃப்கா) பயன்படுத்துவதே சாத்தியமான தீர்வாகும். 'கடன் விண்ணப்பத்தைச் சமர்ப்பி' கட்டளையை நேரடியாகச் செயலாக்குவதற்குப் பதிலாக, நாங்கள் உடனடியாக அதை உள் காஃப்கா தலைப்புக்கு அனுப்புகிறோம், பின்னர் வாடிக்கையாளருக்கு 'ஏற்றுக்கொள்ளப்பட்ட' முடிவைக் கொடுக்கிறோம். இருப்பினும், கட்டளை இன்னும் செயலாக்கப்பட வேண்டியிருக்கும் என்பதால், முடிவை வாடிக்கையாளருக்கு உடனடியாக தெரிவிக்க முடியாது. இந்த இறுதி நிலைத்தன்மையை நிர்வகிக்க, நீண்ட வாக்குப்பதிவு, கிளையன்ட் தொடங்கப்பட்ட வாக்குப்பதிவு, நம்பிக்கையான UI புதுப்பிப்புகள் அல்லது அறிவிப்புகளுக்காக WebSockets அல்லது Server-Sent Events போன்ற நுட்பங்களைப் பயன்படுத்தலாம். இருப்பினும், இது முற்றிலும் ஒரு தனித்துவமான தலைப்பு, எனவே எங்கள் ஆரம்ப விஷயத்திற்குத் திரும்புவோம். உள் காஃப்கா தலைப்பில் செய்தியை அனுப்பினோம். லோன் அப்ளிகேஷன் சர்வீஸ் இந்தச் செய்தியைப் பயன்படுத்துகிறது - வாடிக்கையாளரிடமிருந்து பெறப்பட்ட அதே கட்டளை - மற்றும் செயலாக்கத்தைத் தொடங்குகிறது. முதலில், இது சில வணிக தர்க்கத்தை செயல்படுத்துகிறது; இந்த தர்க்கம் வெற்றிகரமாகச் செயல்படுத்தப்பட்டு, முடிவுகள் தொடர்ந்த பிறகுதான், பொது காஃப்கா தலைப்பில் புதிய செய்திகளை வெளியிடுகிறது. ஒரு பிட் போலி-குறியீட்டைப் பார்ப்போம். public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); } எந்த கவலையும் இல்லை, ஆஃப்செட் இன்னும் செய்யப்படவில்லை என்பதால், செய்தி மீண்டும் முயற்சிக்கப்படும். வணிக தர்க்கத்தின் செயலாக்கம் தோல்வியடைந்தால் என்ன செய்வது? கவலை வேண்டாம், வணிக தர்க்கம் செயலற்றதாக இருப்பதால், அது நகல் கடன் விண்ணப்பத்தை உருவாக்காது. மாறாக, பொது காஃப்கா தலைப்புக்கு செய்திகளை மீண்டும் அனுப்ப முயற்சிக்கும். புதிய நிகழ்வுகளை காஃப்காவிற்கு அனுப்புவது தோல்வியடைந்தால் என்ன செய்வது? கவலை வேண்டாம், வணிக தர்க்கம் செயலற்றதாக இருப்பதால், அது நகல் கடன் விண்ணப்பத்தை உருவாக்காது. மாறாக, இது பொது காஃப்கா தலைப்புக்கு செய்திகளை மீண்டும் அனுப்பும் மற்றும் இந்த முறை ஆஃப்செட் கமிட் வெற்றிபெறும் என்று நம்புகிறது. காஃப்காவுக்கு செய்திகள் அனுப்பப்பட்டாலும், ஆஃப்செட் கமிட் தோல்வியடைந்தால் என்ன செய்வது? இந்த அணுகுமுறையின் முக்கிய குறைபாடுகள், புதிய நிரலாக்க பாணியுடன் தொடர்புடைய கூடுதல் சிக்கலான தன்மை, இறுதியில் நிலைத்தன்மை (வாடிக்கையாளருக்கு உடனடியாக முடிவு தெரியாது என்பதால்) மற்றும் அனைத்து வணிக தர்க்கங்களும் திறமையற்றதாக இருக்க வேண்டும். நிகழ்வு ஆதாரம் நிகழ்வு ஆதாரம் என்றால் என்ன, அதை இங்கே எப்படிப் பயன்படுத்தலாம்? ஈவென்ட் சோர்சிங் என்பது ஒரு கணினியின் நிலையை மாதிரியாகக் கொண்டு அதன் தரவுகளில் ஏற்படும் அனைத்து மாற்றங்களையும் மாற்ற முடியாத நிகழ்வுகளின் தொடராகப் படம்பிடிக்கப் பயன்படும் ஒரு மென்பொருள் கட்டமைப்பு வடிவமாகும். இந்த நிகழ்வுகள் உண்மைகள் அல்லது நிலை மாற்றங்களை பிரதிநிதித்துவப்படுத்துகின்றன மற்றும் அமைப்பின் தற்போதைய நிலைக்கு உண்மையின் ஒற்றை ஆதாரமாக செயல்படுகின்றன. எனவே, தொழில்நுட்ப ரீதியாக, நிகழ்வு-மூல அமைப்பைச் செயல்படுத்துவதன் மூலம், எங்களிடம் ஏற்கனவே எல்லா நிகழ்வுகளும் EventStore இல் உள்ளன, மேலும் இந்த EventStore ஆனது என்ன நடந்தது என்பதைப் பற்றிய உண்மையின் ஒரே ஆதாரமாக நுகர்வோரால் பயன்படுத்தப்படலாம். அனைத்து மாற்றங்களையும் அல்லது ஆர்டர் செய்வதைப் பற்றிய கவலைகளையும் கண்காணிக்க ஒரு குறிப்பிட்ட தரவுத்தள தீர்வு தேவையில்லை, ஒரே பிரச்சனை என்னவென்றால், அனைத்து நிகழ்வுகளையும் மீண்டும் இயக்க, நிறுவனத்தின் உண்மையான நிலையைப் பெறுவது அவசியம். முடிவுரை இந்த கட்டுரையில், விநியோகிக்கப்பட்ட அமைப்புகளில் நம்பகமான செய்திகளை உருவாக்குவதற்கான பல அணுகுமுறைகளை மதிப்பாய்வு செய்தோம். இந்த குணாதிசயங்களைக் கொண்ட அமைப்புகளை உருவாக்கும்போது நாம் கருத்தில் கொள்ளக்கூடிய பல பரிந்துரைகள் உள்ளன நெட்வொர்க் தோல்வி தவிர்க்க முடியாதது என்பதால் எப்பொழுதும் திறமையற்ற நுகர்வோரை உருவாக்குங்கள். உத்தரவாதத் தேவைகள் பற்றிய தெளிவான புரிதலுடன் கவனமாகப் பயன்படுத்தவும். , முதல்-உள்ளூர்-உறுதி-பின்-வெளியீடு என்பதை அணுகுமுறையை ஒருபோதும் பயன்படுத்த வேண்டாம், ஏனெனில் இது உங்கள் கணினியில் கடுமையான தரவு முரண்பாட்டிற்கு வழிவகுக்கும். முதல்-வெளியீடு-பின்னர்-உள்ளூர்-கமிட் தற்போதுள்ள தரவுத்தள தேர்வு முடிவு மாறலாம் அல்லது தொழில்நுட்ப உத்தி சிக்கலுக்கான சிறந்த சேமிப்பக தீர்வைத் தேர்ந்தெடுப்பதைக் குறிக்கிறது என்றால் - போன்ற தரவுத்தள தீர்வுகளுடன் பிணைப்பதன் மூலம் பகிரப்பட்ட நூலகங்களை உருவாக்க வேண்டாம். CDC குறைந்தபட்சம் ஒரு முறை உத்தரவாதத்தை அடைவதற்கான நிலையான தீர்வாக அணுகுமுறையைப் பயன்படுத்தவும். பரிவர்த்தனை அவுட்பாக்ஸ் No-SQL தரவுத்தளங்கள் மேம்படுத்தப்படும்போது அணுகுமுறையைப் பயன்படுத்தவும். உங்களை நீங்களே கேட்டுக்கொள்ளுங்கள் என்ற அடுத்த முறை, பரிவர்த்தனை அவுட்பாக்ஸை செயல்படுத்துவதற்கான நடைமுறை உதாரணத்தைப் பார்ப்போம். பார்க்கவும் நீ!