செய்தி தரகர்களைப் புரிந்துகொள்வது. ActiveMQ மற்றும் Kafka மூலம் செய்தி அனுப்பும் இயக்கவியல் கற்றல். அத்தியாயம் 3. காஃப்கா

ஒரு சிறிய புத்தகத்தின் மொழிபெயர்ப்பின் தொடர்ச்சி:
செய்தி தரகர்களைப் புரிந்துகொள்வது
ஆசிரியர்: Jakub Korab, வெளியீட்டாளர்: O'Reilly Media, Inc., வெளியிடப்பட்ட தேதி: ஜூன் 2017, ISBN: 9781492049296.

முந்தைய மொழிபெயர்க்கப்பட்ட பகுதி: செய்தி தரகர்களைப் புரிந்துகொள்வது. ActiveMQ மற்றும் Kafka மூலம் செய்தி அனுப்பும் இயக்கவியல் கற்றல். அத்தியாயம் 1 அறிமுகம்

அத்தியாயம் 3

காஃப்கா

காஃப்கா லிங்க்ட்இன் மூலம் உருவாக்கப்பட்டது, பாரம்பரிய செய்தி தரகர்களின் சில வரம்புகளைப் பெறவும், வெவ்வேறு புள்ளி-க்கு-புள்ளி தொடர்புகளுக்கு பல செய்தி தரகர்களை அமைப்பதைத் தவிர்க்கவும், இது இந்தப் புத்தகத்தில் பக்கம் 28 இல் "ஸ்கேலிங் அப் அண்ட் அவுட்" என்பதன் கீழ் விவரிக்கப்பட்டுள்ளது. பக்கம் கிளிக்குகள் மற்றும் அணுகல் பதிவுகள் போன்ற மிகப் பெரிய அளவிலான தரவை ஒருவழியாக உட்செலுத்துவதை லிங்க்ட்இன் பெரும்பாலும் நம்பியிருக்கிறது. உண்மையில், காஃப்கா இருப்பதற்கான காரணம், யுனிவர்சல் டேட்டா பைப்லைன் விவரிக்கும் வகையான செய்தியிடல் கட்டமைப்பைப் பெறுவதுதான்.

இந்த இறுதி இலக்கைக் கருத்தில் கொண்டு, பிற தேவைகள் இயல்பாகவே எழுந்தன. காஃப்கா செய்ய வேண்டியது:

• மிக வேகமாக இருங்கள்
• செய்திகளுடன் பணிபுரியும் போது அதிக அலைவரிசையை வழங்கவும்
• வெளியீட்டாளர்-சந்தாதாரர் மற்றும் பாயிண்ட்-டு-பாயிண்ட் மாடல்களை ஆதரிக்கவும்
• நுகர்வோரைச் சேர்ப்பதில் வேகத்தைக் குறைக்காதீர்கள். எடுத்துக்காட்டாக, இலக்கில் உள்ள நுகர்வோரின் எண்ணிக்கை அதிகரிக்கும் போது ActiveMQ இல் வரிசை மற்றும் தலைப்பு இரண்டின் செயல்திறன் குறைகிறது.
• கிடைமட்டமாக அளவிடக்கூடியதாக இருங்கள்; செய்திகளைத் தொடரும் ஒரு தரகர் அதிகபட்ச வட்டு வேகத்தில் மட்டுமே அவ்வாறு செய்ய முடியும் என்றால், செயல்திறனை அதிகரிக்க ஒரு தரகர் நிகழ்வைத் தாண்டிச் செல்வது அர்த்தமுள்ளதாக இருக்கும்.
• செய்திகளைச் சேமித்து மீண்டும் பெறுவதற்கான அணுகலைக் கட்டுப்படுத்துங்கள்

இவை அனைத்தையும் அடைய, வாடிக்கையாளர் மற்றும் செய்தியிடல் தரகர்களின் பாத்திரங்கள் மற்றும் பொறுப்புகளை மறுவரையறை செய்யும் ஒரு கட்டிடக்கலையை காஃப்கா ஏற்றுக்கொண்டார். JMS மாதிரியானது மிகவும் தரகர் சார்ந்ததாக உள்ளது, அங்கு செய்திகளை விநியோகிக்க தரகர் பொறுப்பு மற்றும் வாடிக்கையாளர்கள் செய்திகளை அனுப்புவது மற்றும் பெறுவது பற்றி மட்டுமே கவலைப்பட வேண்டும். மறுபுறம், காஃப்கா, வாடிக்கையாளர்களை மையமாகக் கொண்டது, வாடிக்கையாளர்களுக்கு மிகவும் விரைவான மற்றும் அளவிடக்கூடிய தரகருக்கு ஈடாக, வாடிக்கையாளர்களுக்கு தொடர்புடைய செய்திகளை நியாயமான விநியோகம் போன்ற பாரம்பரிய தரகரின் பல அம்சங்களை வாடிக்கையாளர் எடுத்துக்கொள்கிறார். பாரம்பரிய செய்தியிடல் அமைப்புகளுடன் பணிபுரியும் நபர்களுக்கு, காஃப்காவுடன் பணிபுரிய மனதில் அடிப்படை மாற்றம் தேவைப்படுகிறது.
இந்த பொறியியல் திசையானது, ஒரு வழக்கமான தரகருடன் ஒப்பிடும்போது, ​​பல அளவு ஆர்டர்களால் செயல்திறனை அதிகரிக்கும் திறன் கொண்ட செய்தியிடல் உள்கட்டமைப்பை உருவாக்க வழிவகுத்தது. நாம் பார்ப்பது போல, இந்த அணுகுமுறை வர்த்தக பரிமாற்றங்களுடன் வருகிறது, அதாவது சில வகையான பணிச்சுமைகள் மற்றும் நிறுவப்பட்ட மென்பொருளுக்கு காஃப்கா பொருத்தமானது அல்ல.

ஒருங்கிணைந்த இலக்கு மாதிரி

மேலே விவரிக்கப்பட்ட தேவைகளைப் பூர்த்தி செய்ய, காஃப்கா ஒரு வகையான இலக்கின் கீழ் வெளியிட-சந்தா மற்றும் புள்ளி-க்கு-புள்ளி செய்திகளை ஒருங்கிணைத்துள்ளது - தலைப்பு. செய்தியிடல் அமைப்புகளுடன் பணிபுரிந்தவர்களுக்கு இது குழப்பத்தை ஏற்படுத்துகிறது, அங்கு "தலைப்பு" என்ற சொல் ஒலிபரப்பு பொறிமுறையைக் குறிக்கிறது, அதில் இருந்து (தலைப்பிலிருந்து) வாசிப்பு நீடித்து நிலைக்க முடியாது. இந்தப் புத்தகத்தின் அறிமுகத்தில் வரையறுக்கப்பட்டுள்ளபடி, காஃப்கா தலைப்புகள் ஒரு கலப்பின இலக்கு வகையாகக் கருதப்பட வேண்டும்.

இந்த அத்தியாயத்தின் எஞ்சிய பகுதிக்கு, நாம் வெளிப்படையாக வேறுவிதமாகக் கூறாவிட்டால், "தலைப்பு" என்ற சொல் காஃப்கா தலைப்பைக் குறிக்கும்.

தலைப்புகள் எவ்வாறு செயல்படுகின்றன மற்றும் அவை என்ன உத்தரவாதங்களை வழங்குகின்றன என்பதை முழுமையாக புரிந்து கொள்ள, காஃப்காவில் அவை எவ்வாறு செயல்படுத்தப்படுகின்றன என்பதை நாம் முதலில் பார்க்க வேண்டும்.
காஃப்காவில் உள்ள ஒவ்வொரு தலைப்புக்கும் அதன் சொந்த பதிவு உள்ளது.
காஃப்காவிற்கு செய்திகளை அனுப்பும் தயாரிப்பாளர்கள் இந்த பதிவிற்கு எழுதுகிறார்கள், மேலும் நுகர்வோர் தொடர்ந்து முன்னேறும் சுட்டிகளைப் பயன்படுத்தி பதிவிலிருந்து படிக்கிறார்கள். அவ்வப்போது, ​​காஃப்கா பதிவின் பழமையான பகுதிகளை நீக்குகிறது, அந்த பகுதிகளில் உள்ள செய்திகள் படிக்கப்பட்டாலும் இல்லாவிட்டாலும். காஃப்காவின் வடிவமைப்பின் மையப் பகுதி என்னவென்றால், செய்திகள் படிக்கப்படுகிறதா இல்லையா என்பதைப் பற்றி தரகர் கவலைப்படுவதில்லை - அது வாடிக்கையாளரின் பொறுப்பு.

"பதிவு" மற்றும் "சுட்டி" என்ற சொற்கள் தோன்றவில்லை காஃப்கா ஆவணங்கள். இந்த நன்கு அறியப்பட்ட சொற்கள் புரிந்து கொள்ள உதவுவதற்காக இங்கே பயன்படுத்தப்படுகின்றன.

இந்த மாதிரி ActiveMQ இலிருந்து முற்றிலும் வேறுபட்டது, அங்கு அனைத்து வரிசைகளிலிருந்தும் செய்திகள் ஒரே பதிவில் சேமிக்கப்படும், மேலும் தரகர் செய்திகளைப் படித்த பிறகு நீக்கப்பட்டதாகக் குறிக்கிறார்.
இப்போது கொஞ்சம் ஆழமாக தோண்டி, தலைப்பு பதிவை இன்னும் விரிவாகப் பார்ப்போம்.
காஃப்கா பதிவு பல பகிர்வுகளைக் கொண்டுள்ளது (படம் 3-1) ஒவ்வொரு பகிர்விலும் கண்டிப்பான வரிசையை காஃப்கா உத்தரவாதம் செய்கிறது. அதாவது ஒரு குறிப்பிட்ட வரிசையில் பகிர்வுக்கு எழுதப்பட்ட செய்திகள் அதே வரிசையில் படிக்கப்படும். ஒவ்வொரு பகிர்வும் ரோலிங் பதிவு கோப்பாக செயல்படுத்தப்படுகிறது ஒரு துணைக்குழு (துணைத்தொகுப்பு) அதன் தயாரிப்பாளர்களால் தலைப்புக்கு அனுப்பப்பட்ட அனைத்து செய்திகளின். உருவாக்கப்பட்ட தலைப்பில், முன்னிருப்பாக, ஒரு பகிர்வு உள்ளது. பகிர்வுகளின் யோசனை கிடைமட்ட அளவிடுதலுக்கான காஃப்காவின் மைய யோசனையாகும்.

படம் 3-1. காஃப்கா பகிர்வுகள்

ஒரு தயாரிப்பாளர் ஒரு காஃப்கா தலைப்புக்கு ஒரு செய்தியை அனுப்பும்போது, ​​எந்தப் பிரிவிற்கு செய்தியை அனுப்ப வேண்டும் என்பதை அது தீர்மானிக்கிறது. இதைப் பற்றி பின்னர் விரிவாகப் பார்ப்போம்.

செய்திகளைப் படித்தல்

செய்திகளைப் படிக்க விரும்பும் கிளையன்ட் பெயரிடப்பட்ட சுட்டியை நிர்வகிக்கிறது நுகர்வோர் குழு, இது சுட்டிக்காட்டுகிறது ஆஃப்செட் பகிர்வில் உள்ள செய்திகள். ஆஃப்செட் என்பது ஒரு பகிர்வின் தொடக்கத்தில் 0 இல் தொடங்கும் ஒரு அதிகரிக்கும் நிலை. இந்த நுகர்வோர் குழு, பயனர் வரையறுக்கப்பட்ட group_id வழியாக API இல் குறிப்பிடப்பட்டுள்ளது ஒரு தருக்க நுகர்வோர் அல்லது அமைப்பு.

பெரும்பாலான செய்தியிடல் அமைப்புகள் செய்திகளை இணையாகச் செயலாக்க பல நிகழ்வுகள் மற்றும் நூல்களைப் பயன்படுத்தி இலக்கிலிருந்து தரவைப் படிக்கின்றன. எனவே, பொதுவாக ஒரே நுகர்வோர் குழுவைப் பகிர்ந்து கொள்ளும் பல நுகர்வோர் நிகழ்வுகள் இருக்கும்.

வாசிப்பின் சிக்கலை பின்வருமாறு குறிப்பிடலாம்:

• தலைப்பு பல பகிர்வுகளைக் கொண்டுள்ளது
• பல நுகர்வோர் குழுக்கள் ஒரே நேரத்தில் ஒரு தலைப்பைப் பயன்படுத்தலாம்
• நுகர்வோர் குழு பல தனித்தனி நிகழ்வுகளைக் கொண்டிருக்கலாம்

இது அற்பமானதல்ல பல-பல பிரச்சனை. நுகர்வோர் குழுக்கள், நுகர்வோர் நிகழ்வுகள் மற்றும் பகிர்வுகளுக்கு இடையேயான உறவுகளை காஃப்கா எவ்வாறு கையாளுகிறது என்பதைப் புரிந்து கொள்ள, படிப்படியாக மிகவும் சிக்கலான வாசிப்பு காட்சிகளின் தொடரைப் பார்ப்போம்.

நுகர்வோர் மற்றும் நுகர்வோர் குழுக்கள்

ஒரு பிரிவைக் கொண்ட தலைப்பை ஆரம்பப் புள்ளியாக எடுத்துக் கொள்வோம் (படம் 3-2).

படம் 3-2. பகிர்விலிருந்து நுகர்வோர் படிக்கிறார்

ஒரு நுகர்வோர் நிகழ்வானது அதன் சொந்த குழு_ஐடியுடன் இந்தத் தலைப்புடன் இணைந்தால், அதற்கு ஒரு வாசிப்புப் பகிர்வு மற்றும் அந்தப் பகிர்வில் ஒரு ஆஃப்செட் ஒதுக்கப்படும். இந்த ஆஃப்செட்டின் நிலை, கிளையண்டில் மிக சமீபத்திய நிலை (புதிய செய்தி) அல்லது முந்தைய நிலை (பழைய செய்தி)க்கான சுட்டியாக உள்ளமைக்கப்படுகிறது. நுகர்வோர் தலைப்பில் இருந்து செய்திகளை (வாக்கெடுப்புகள்) கோருகிறார், இதனால் அவை பதிவிலிருந்து வரிசையாகப் படிக்கப்படும்.
ஆஃப்செட் நிலை தொடர்ந்து காஃப்காவுக்குத் திரும்பவும் உள் தலைப்பில் செய்திகளாகச் சேமிக்கப்படும் _consumer_offsets. வழக்கமான தரகர் போலல்லாமல், படித்த செய்திகள் இன்னும் நீக்கப்படவில்லை, மேலும் ஏற்கனவே பார்த்த செய்திகளை மீண்டும் செயலாக்க கிளையன்ட் ஆஃப்செட்டை ரிவைண்ட் செய்யலாம்.

இரண்டாவது தருக்க நுகர்வோர் வேறொரு group_id ஐப் பயன்படுத்தி இணைக்கும் போது, ​​அது முதலில் இருந்து சுயாதீனமான இரண்டாவது சுட்டியை நிர்வகிக்கிறது (படம் 3-3) எனவே, ஒரு காஃப்கா தலைப்பு ஒரு நுகர்வோர் இருக்கும் வரிசையைப் போலவும், பல நுகர்வோர் குழுசேரும் ஒரு சாதாரண வெளியீட்டு-சந்தா (pub-sub) தலைப்பைப் போலவும் செயல்படுகிறது, கூடுதல் நன்மையுடன் அனைத்து செய்திகளும் சேமிக்கப்பட்டு பல முறை செயலாக்கப்படும்.

படம் 3-3. வெவ்வேறு நுகர்வோர் குழுக்களில் உள்ள இரண்டு நுகர்வோர் ஒரே பகிர்விலிருந்து படிக்கிறார்கள்

நுகர்வோர் குழுவில் உள்ள நுகர்வோர்

ஒரு நுகர்வோர் நிகழ்வு ஒரு பகிர்விலிருந்து தரவைப் படிக்கும் போது, ​​அது முந்தைய பிரிவில் விவரிக்கப்பட்டுள்ளபடி சுட்டிக்காட்டி மற்றும் செயலாக்க செய்திகளின் முழு கட்டுப்பாட்டையும் கொண்டுள்ளது.
நுகர்வோரின் பல நிகழ்வுகள் ஒரே குழு_ஐடியுடன் ஒரு பிரிவைக் கொண்ட தலைப்புடன் இணைக்கப்பட்டிருந்தால், கடைசியாக இணைக்கப்பட்ட நிகழ்வு சுட்டிக்காட்டி மீது கட்டுப்பாட்டைக் கொடுக்கப்படும், மேலும் அந்த தருணத்திலிருந்து அது அனைத்து செய்திகளையும் பெறும் (படம் 3-4).

படம் 3-4. ஒரே நுகர்வோர் குழுவில் உள்ள இரண்டு நுகர்வோர் ஒரே பகிர்வில் இருந்து படிக்கின்றனர்

இந்த செயலாக்க முறை, இதில் நுகர்வோர் நிகழ்வுகளின் எண்ணிக்கை பகிர்வுகளின் எண்ணிக்கையை மீறுகிறது, இது ஒரு வகையான பிரத்தியேக நுகர்வோர் என்று கருதலாம். உங்கள் நுகர்வோர் நிகழ்வுகளின் "செயலில்-செயலற்ற" (அல்லது "சூடான-சூடான") கிளஸ்டரிங் தேவைப்பட்டால் இது பயனுள்ளதாக இருக்கும், இருப்பினும் பல நுகர்வோரை இணையாக இயக்குவது ("ஆக்டிவ்-ஆக்டிவ்" அல்லது "ஹாட்-ஹாட்") மிகவும் பொதுவானது காத்திருப்பில்.

ஒரு சாதாரண JMS வரிசை எவ்வாறு செயல்படுகிறது என்பதை ஒப்பிடும்போது மேலே விவரிக்கப்பட்ட இந்த செய்தி விநியோக நடத்தை ஆச்சரியமாக இருக்கும். இந்த மாதிரியில், வரிசையில் அனுப்பப்படும் செய்திகள் இரண்டு நுகர்வோர் இடையே சமமாக விநியோகிக்கப்படும்.

பெரும்பாலும், நாங்கள் பல நுகர்வோர் நிகழ்வுகளை உருவாக்கும்போது, ​​செய்திகளை இணையாகச் செயலாக்கவோ அல்லது வாசிப்பின் வேகத்தை அதிகரிக்கவோ அல்லது வாசிப்புச் செயல்பாட்டின் நிலைத்தன்மையை அதிகரிக்கவோ இதைச் செய்கிறோம். ஒரு நேரத்தில் ஒரு நுகர்வோர் நிகழ்வு மட்டுமே ஒரு பகிர்விலிருந்து தரவைப் படிக்க முடியும் என்பதால், காஃப்காவில் இது எவ்வாறு அடையப்படுகிறது?

இதைச் செய்வதற்கான ஒரு வழி, ஒரு நுகர்வோர் நிகழ்வைப் பயன்படுத்தி அனைத்து செய்திகளையும் படித்து அவற்றை நூல் பூலுக்கு அனுப்புவது. இந்த அணுகுமுறை செயலாக்க செயல்திறனை அதிகரிக்கும் அதே வேளையில், இது நுகர்வோர் தர்க்கத்தின் சிக்கலை அதிகரிக்கிறது மற்றும் வாசிப்பு முறையின் வலிமையை அதிகரிக்க எதுவும் செய்யாது. மின் செயலிழப்பு அல்லது இதே போன்ற நிகழ்வு காரணமாக நுகர்வோரின் ஒரு நகல் குறைந்துவிட்டால், கழித்தல் நிறுத்தப்படும்.

காஃப்காவில் இந்தப் பிரச்சனையைத் தீர்ப்பதற்கான நியதி வழி பிОமேலும் பகிர்வுகள்.

பிரித்தல்

ஒற்றை தரகர் நிகழ்வின் அலைவரிசைக்கு அப்பால் ஒரு தலைப்பை வாசிப்பதற்கும் அளவிடுவதற்கும் பகிர்வுகள் முக்கிய வழிமுறையாகும். இதை நன்கு புரிந்து கொள்ள, இரண்டு பகிர்வுகளுடன் ஒரு தலைப்பு இருக்கும் மற்றும் ஒரு நுகர்வோர் இந்த தலைப்பில் சந்தா செலுத்தும் சூழ்நிலையை கருத்தில் கொள்வோம் (படம் 3-5).

படம் 3-5. ஒரு நுகர்வோர் பல பகிர்வுகளிலிருந்து படிக்கிறார்

இந்த சூழ்நிலையில், நுகர்வோருக்கு இரண்டு பகிர்வுகளிலும் அதன் group_id உடன் தொடர்புடைய சுட்டிகள் மீது கட்டுப்பாடு கொடுக்கப்பட்டு இரண்டு பகிர்வுகளிலிருந்தும் செய்திகளைப் படிக்கத் தொடங்கும்.
அதே group_idக்கான கூடுதல் நுகர்வோர் இந்தத் தலைப்பில் சேர்க்கப்படும்போது, ​​காஃப்கா பகிர்வுகளில் ஒன்றை முதல் முதல் இரண்டாவது நுகர்வோருக்கு மறு ஒதுக்கீடு செய்கிறது. அதன் பிறகு, நுகர்வோரின் ஒவ்வொரு நிகழ்வும் தலைப்பின் ஒரு பிரிவிலிருந்து படிக்கப்படும் (படம் 3-6).

செய்திகள் 20 த்ரெட்களில் இணையாக செயலாக்கப்படுவதை உறுதிசெய்ய, உங்களுக்கு குறைந்தது 20 பகிர்வுகள் தேவை. குறைவான பகிர்வுகள் இருந்தால், பிரத்தியேக நுகர்வோர் பற்றிய விவாதத்தில் முன்பு விவரிக்கப்பட்டபடி, வேலை செய்ய எதுவும் இல்லாத நுகர்வோர் உங்களிடம் இருப்பார்கள்.

படம் 3-6. ஒரே நுகர்வோர் குழுவில் உள்ள இரண்டு நுகர்வோர் வெவ்வேறு பகிர்வுகளிலிருந்து படிக்கின்றனர்

JMS வரிசையை பராமரிக்க தேவையான செய்தி விநியோகத்துடன் ஒப்பிடும்போது இந்த திட்டம் காஃப்கா தரகரின் சிக்கலை வெகுவாகக் குறைக்கிறது. இங்கே நீங்கள் பின்வரும் புள்ளிகளைப் பற்றி கவலைப்படத் தேவையில்லை:

• ரவுண்ட்-ராபின் ஒதுக்கீடு, ப்ரீஃபெட்ச் பஃபர்களின் தற்போதைய திறன் அல்லது முந்தைய செய்திகளின் அடிப்படையில் (JMS செய்தி குழுக்களைப் பொறுத்தவரை) எந்த நுகர்வோர் அடுத்த செய்தியைப் பெற வேண்டும்.
• எந்தெந்த நுகர்வோருக்கு எந்தச் செய்திகள் அனுப்பப்படுகின்றன மற்றும் தோல்வியுற்றால் அவை மீண்டும் வழங்கப்பட வேண்டுமா.

காஃப்கா தரகர் செய்ய வேண்டியதெல்லாம், நுகர்வோர் கோரும் போது, ​​வரிசையாக செய்திகளை அனுப்ப வேண்டும்.

இருப்பினும், சரிபார்ப்பை இணைப்பதற்கான தேவைகள் மற்றும் தோல்வியுற்ற செய்திகளை மீண்டும் அனுப்புவதற்கான தேவைகள் மறைந்துவிடாது - அவற்றுக்கான பொறுப்பு வெறுமனே தரகரிடமிருந்து வாடிக்கையாளருக்கு செல்கிறது. உங்கள் குறியீட்டில் அவை கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டும் என்பதே இதன் பொருள்.

செய்திகளை அனுப்புகிறது

எந்தப் பிரிவிற்கு செய்தி அனுப்புவது என்பதை முடிவு செய்வது அந்தச் செய்தியின் தயாரிப்பாளரின் பொறுப்பு. இது செய்யப்படும் பொறிமுறையைப் புரிந்து கொள்ள, முதலில் நாம் உண்மையில் எதை அனுப்புகிறோம் என்பதைக் கருத்தில் கொள்ள வேண்டும்.

ஜேஎம்எஸ்ஸில் மெட்டாடேட்டா (தலைப்புகள் மற்றும் பண்புகள்) மற்றும் பேலோட் (பேலோட்) கொண்ட ஒரு மெசேஜ் அமைப்பைப் பயன்படுத்துகிறோம், காஃப்காவில் செய்தி ஜோடி "முக்கிய மதிப்பு". செய்தி பேலோட் ஒரு மதிப்பாக அனுப்பப்படுகிறது. விசை, மறுபுறம், முக்கியமாக பகிர்வுக்குப் பயன்படுத்தப்படுகிறது மற்றும் கொண்டிருக்க வேண்டும் வணிக தர்க்கம் குறிப்பிட்ட விசைதொடர்புடைய செய்திகளை அதே பகிர்வில் வைக்க.

அத்தியாயம் 2 இல், ஒரு நுகர்வோர் மூலம் தொடர்புடைய நிகழ்வுகள் செயல்படுத்தப்பட வேண்டிய ஆன்லைன் பந்தய சூழ்நிலையைப் பற்றி நாங்கள் விவாதித்தோம்:

1. பயனர் கணக்கு கட்டமைக்கப்பட்டுள்ளது.
2. கணக்கில் பணம் வரவு வைக்கப்படுகிறது.
3. கணக்கில் இருந்து பணத்தை எடுக்க ஒரு பந்தயம் செய்யப்படுகிறது.

ஒவ்வொரு நிகழ்வும் ஒரு தலைப்பில் இடுகையிடப்பட்ட செய்தியாக இருந்தால், இயல்பான திறவுகோல் கணக்கு ஐடியாக இருக்கும்.
Kafka Producer API ஐப் பயன்படுத்தி ஒரு செய்தி அனுப்பப்படும் போது, ​​அது ஒரு பகிர்வு செயல்பாட்டிற்கு அனுப்பப்படும், இது செய்தி மற்றும் காஃப்கா கிளஸ்டரின் தற்போதைய நிலை ஆகியவற்றைக் கொண்டு, செய்தி அனுப்பப்பட வேண்டிய பகிர்வின் ஐடியை வழங்குகிறது. இந்த அம்சம் ஜாவாவில் பார்ட்டிஷனர் இடைமுகம் மூலம் செயல்படுத்தப்படுகிறது.

இந்த இடைமுகம் இதுபோல் தெரிகிறது:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

பார்டிஷனர் செயல்படுத்தல் பகிர்வை தீர்மானிக்க விசையின் மீது இயல்புநிலை பொது-நோக்க ஹாஷிங் அல்காரிதம் அல்லது விசை குறிப்பிடப்படவில்லை எனில் ரவுண்ட்-ராபின் பயன்படுத்துகிறது. இந்த இயல்புநிலை மதிப்பு பெரும்பாலான சந்தர்ப்பங்களில் நன்றாக வேலை செய்கிறது. இருப்பினும், எதிர்காலத்தில் நீங்கள் சொந்தமாக எழுத விரும்புவீர்கள்.

உங்கள் சொந்த பகிர்வு உத்தியை எழுதுதல்

செய்தி பேலோடுடன் மெட்டாடேட்டாவை அனுப்ப விரும்பும் உதாரணத்தைப் பார்ப்போம். எங்கள் எடுத்துக்காட்டில் உள்ள பேலோட் என்பது கேம் கணக்கில் டெபாசிட் செய்வதற்கான அறிவுறுத்தலாகும். ஒரு அறிவுறுத்தல் என்பது பரிமாற்றத்தில் மாற்றப்பட மாட்டோம் என்று நாங்கள் உத்தரவாதம் அளிக்க விரும்புகிறோம், மேலும் நம்பகமான அப்ஸ்ட்ரீம் அமைப்பு மட்டுமே அந்த அறிவுறுத்தலைத் தொடங்க முடியும் என்பதை உறுதிப்படுத்த விரும்புகிறோம். இந்த வழக்கில், அனுப்புதல் மற்றும் பெறுதல் அமைப்புகள் செய்தியை அங்கீகரிக்க கையொப்பத்தைப் பயன்படுத்துவதை ஒப்புக்கொள்கின்றன.
சாதாரண JMS இல், "செய்தி கையொப்பம்" பண்பை வரையறுத்து அதை செய்தியில் சேர்ப்போம். இருப்பினும், காஃப்கா நமக்கு மெட்டாடேட்டாவை அனுப்புவதற்கான பொறிமுறையை வழங்கவில்லை, ஒரு விசை மற்றும் மதிப்பை மட்டுமே.

மதிப்பானது வங்கி பரிமாற்ற பேலோட் என்பதால், அதன் நேர்மையை நாம் பாதுகாக்க வேண்டும், விசையில் பயன்படுத்த வேண்டிய தரவு கட்டமைப்பை வரையறுப்பதைத் தவிர வேறு வழியில்லை. ஒரு கணக்குடன் தொடர்புடைய அனைத்து செய்திகளும் வரிசையாக செயலாக்கப்பட வேண்டும் என்பதால், பகிர்வதற்கான கணக்கு ஐடி தேவை என்று வைத்துக்கொள்வோம், பின்வரும் JSON கட்டமைப்பைக் கொண்டு வருவோம்:

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

பேலோடைப் பொறுத்து கையொப்பத்தின் மதிப்பு மாறுபடும் என்பதால், பார்ட்டிஷனர் இடைமுகத்தின் இயல்புநிலை ஹாஷிங் உத்தி நம்பகத்தன்மையுடன் தொடர்புடைய செய்திகளை குழுவாக்காது. எனவே, இந்த விசையை பாகுபடுத்தி கணக்கு ஐடி மதிப்பை பிரிக்கும் நமது சொந்த உத்தியை நாம் எழுத வேண்டும்.

கடையில் உள்ள செய்திகளின் ஊழலைக் கண்டறிவதற்கான செக்சம்களை காஃப்கா கொண்டுள்ளது மற்றும் முழு பாதுகாப்பு அம்சங்களையும் கொண்டுள்ளது. அப்படியிருந்தும், மேலே குறிப்பிட்டது போன்ற தொழில் சார்ந்த தேவைகள் சில நேரங்களில் தோன்றும்.

பயனரின் பகிர்வு உத்தியானது அனைத்து தொடர்புடைய செய்திகளும் ஒரே பகிர்வில் முடிவடைவதை உறுதி செய்ய வேண்டும். இது எளிமையானதாகத் தோன்றினாலும், தொடர்புடைய செய்திகளை வரிசைப்படுத்துவதன் முக்கியத்துவம் மற்றும் ஒரு தலைப்பில் உள்ள பகிர்வுகளின் எண்ணிக்கை எவ்வளவு நிலையானது என்பதன் மூலம் தேவை சிக்கலானதாக இருக்கலாம்.

ஒரு தலைப்பில் உள்ள பகிர்வுகளின் எண்ணிக்கை காலப்போக்கில் மாறலாம், ஏனெனில் போக்குவரத்து ஆரம்ப எதிர்பார்ப்புகளுக்கு அப்பால் சென்றால் அவை சேர்க்கப்படலாம். இவ்வாறு, செய்தி விசைகள் அவை முதலில் அனுப்பப்பட்ட பகிர்வுடன் தொடர்புபடுத்தப்படலாம், இது தயாரிப்பாளர் நிகழ்வுகளுக்கு இடையில் பகிரப்படும் மாநிலத்தின் ஒரு பகுதியைக் குறிக்கிறது.

கருத்தில் கொள்ள வேண்டிய மற்றொரு காரணி, பகிர்வுகளில் செய்திகளின் சீரான விநியோகம் ஆகும். பொதுவாக, செய்திகள் முழுவதும் விசைகள் சமமாக விநியோகிக்கப்படுவதில்லை, மேலும் ஹாஷ் செயல்பாடுகள் ஒரு சிறிய தொகுப்பு விசைகளுக்கு செய்திகளின் நியாயமான விநியோகத்திற்கு உத்தரவாதம் அளிக்காது.
நீங்கள் செய்திகளைப் பிரிக்கத் தேர்வுசெய்தாலும், பிரிப்பானையே மீண்டும் பயன்படுத்த வேண்டியிருக்கும் என்பதை கவனத்தில் கொள்ள வேண்டும்.

வெவ்வேறு புவியியல் இடங்களில் காஃப்கா க்ளஸ்டர்களுக்கு இடையேயான தரவை நகலெடுப்பதற்கான தேவையைக் கவனியுங்கள். இந்த நோக்கத்திற்காக, காஃப்கா MirrorMaker எனப்படும் கட்டளை வரி கருவியுடன் வருகிறது, இது ஒரு கிளஸ்டரிலிருந்து செய்திகளைப் படிக்கவும் அவற்றை மற்றொன்றுக்கு மாற்றவும் பயன்படுகிறது.

மிரர்மேக்கர், க்ளஸ்டர்களுக்கு இடையே நகலெடுக்கும் போது, ​​செய்திகளுக்கு இடையே தொடர்புடைய வரிசையை பராமரிக்க, பிரதி செய்யப்பட்ட தலைப்பின் விசைகளை புரிந்து கொள்ள வேண்டும், ஏனெனில் அந்த தலைப்பிற்கான பகிர்வுகளின் எண்ணிக்கை இரண்டு கிளஸ்டர்களில் ஒரே மாதிரியாக இருக்காது.

தனிப்பயன் பகிர்வு உத்திகள் ஒப்பீட்டளவில் அரிதானவை, ஏனெனில் இயல்புநிலை ஹாஷிங் அல்லது ரவுண்ட் ராபின் பெரும்பாலான காட்சிகளில் நன்றாக வேலை செய்கிறது. இருப்பினும், உங்களுக்கு வலுவான வரிசைப்படுத்துதல் உத்தரவாதங்கள் தேவைப்பட்டால் அல்லது பேலோடுகளிலிருந்து மெட்டாடேட்டாவைப் பிரித்தெடுக்க வேண்டும் என்றால், பகிர்வு என்பது நீங்கள் கவனமாகப் பார்க்க வேண்டிய ஒன்று.

பாரம்பரிய தரகரின் சில பொறுப்புகளை வாடிக்கையாளருக்கு மாற்றுவதன் மூலம் காஃப்காவின் அளவிடுதல் மற்றும் செயல்திறன் நன்மைகள் வருகின்றன. இந்த வழக்கில், இணையாக பணிபுரியும் பல நுகர்வோர் மத்தியில் சாத்தியமான தொடர்புடைய செய்திகளை விநியோகிக்க ஒரு முடிவு எடுக்கப்படுகிறது.

JMS தரகர்களும் அத்தகைய தேவைகளை சமாளிக்க வேண்டும். சுவாரஸ்யமாக, அதே நுகர்வோருக்கு தொடர்புடைய செய்திகளை அனுப்புவதற்கான பொறிமுறையானது, JMS செய்தி குழுக்கள் மூலம் செயல்படுத்தப்படுகிறது (ஸ்டிக்கி லோட் பேலன்சிங் (SLB) உத்தியின் மாறுபாடு), அனுப்புநர் செய்திகளை தொடர்புடையதாகக் குறிக்க வேண்டும். JMS ஐப் பொறுத்தவரை, பல நுகர்வோரில் ஒருவருக்கு இந்த தொடர்புடைய செய்திகளின் குழுவை அனுப்புவதற்கும், நுகர்வோர் தவறிவிட்டால் குழுவின் உரிமையை மாற்றுவதற்கும் தரகர் பொறுப்பு.

தயாரிப்பாளர் ஒப்பந்தங்கள்

செய்திகளை அனுப்பும்போது பார்டிஷனிங் மட்டும் கருத்தில் கொள்ள வேண்டியதில்லை. Java API இல் உள்ள தயாரிப்பாளர் வகுப்பின் அனுப்பு() முறைகளைப் பார்ப்போம்:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

இரண்டு முறைகளும் எதிர்காலத்தைத் திருப்பித் தருகின்றன என்பதை உடனடியாகக் கவனிக்க வேண்டும், இது அனுப்புதல் செயல்பாடு உடனடியாகச் செய்யப்படவில்லை என்பதைக் குறிக்கிறது. இதன் விளைவாக, ஒவ்வொரு செயலில் உள்ள பகிர்வுக்கும் அனுப்பும் இடையகத்திற்கு ஒரு செய்தி (தயாரிப்பாளர் பதிவு) எழுதப்பட்டு, காஃப்கா கிளையன்ட் லைப்ரரியில் பின்னணி நூலாக தரகருக்கு அனுப்பப்படுகிறது. இது விஷயங்களை நம்பமுடியாத அளவிற்கு வேகமாகச் செய்யும் அதே வேளையில், அனுபவமற்ற பயன்பாடு அதன் செயல்முறை நிறுத்தப்பட்டால் செய்திகளை இழக்க நேரிடும்.

எப்போதும் போல், செயல்திறன் செலவில் அனுப்பும் செயல்பாட்டை மிகவும் நம்பகமானதாக மாற்ற ஒரு வழி உள்ளது. இந்த இடையகத்தின் அளவை 0 ஆக அமைக்கலாம், மேலும் அனுப்பும் அப்ளிகேஷன் த்ரெட், தரகருக்கு செய்தி பரிமாற்றம் முடிவடையும் வரை காத்திருக்க வேண்டிய கட்டாயம், பின்வருமாறு:

RecordMetadata metadata = producer.send(record).get();

செய்திகளைப் படிப்பது பற்றி மேலும்

செய்திகளைப் படிப்பதில் கூடுதல் சிக்கல்கள் உள்ளன, அவை யூகிக்கப்பட வேண்டும். JMS API போலல்லாமல், ஒரு செய்திக்கு பதிலளிக்கும் வகையில் ஒரு செய்தி கேட்பவரை இயக்க முடியும் நுகர்வோர் காஃப்கா கருத்துக் கணிப்புகள் மட்டுமே. முறையை இன்னும் விரிவாகப் பார்ப்போம் கருத்து கணிப்பு()இந்த நோக்கத்திற்காக பயன்படுத்தப்படுகிறது:

ConsumerRecords < K, V > poll(long timeout);

முறையின் வருவாய் மதிப்பு என்பது பல பொருள்களைக் கொண்ட கொள்கலன் அமைப்பாகும் நுகர்வோர் பதிவு சாத்தியமான பல பகிர்வுகளிலிருந்து. நுகர்வோர் பதிவு அது பெறப்பட்ட பகிர்வு போன்ற தொடர்புடைய மெட்டாடேட்டாவுடன் ஒரு முக்கிய-மதிப்பு ஜோடிக்கான ஹோல்டர் பொருளாகும்.

அத்தியாயம் 2 இல் விவாதிக்கப்பட்டபடி, செய்திகள் வெற்றிகரமாக அல்லது தோல்வியுற்ற பிறகு, எடுத்துக்காட்டாக, கிளையன்ட் செய்தியைச் செயல்படுத்த முடியாவிட்டால் அல்லது அது நிறுத்தப்பட்டால், செய்திகளுக்கு என்ன நடக்கும் என்பதை நாம் மனதில் கொள்ள வேண்டும். JMS இல், இது ஒப்புகை முறை மூலம் கையாளப்பட்டது. தரகர் வெற்றிகரமாக செயலாக்கப்பட்ட செய்தியை நீக்குவார் அல்லது மூல அல்லது போலியான செய்தியை மீண்டும் வழங்குவார் (பரிவர்த்தனைகள் பயன்படுத்தப்பட்டதாகக் கொள்ளலாம்).
காஃப்கா மிகவும் வித்தியாசமாக வேலை செய்கிறார். சரிபார்த்த பிறகு தரகரில் செய்திகள் நீக்கப்படாது, தோல்வியில் என்ன நடக்கிறது என்பது சரிபார்ப்பு குறியீட்டின் பொறுப்பாகும்.

நாங்கள் கூறியது போல், நுகர்வோர் குழு பதிவில் உள்ள ஆஃப்செட்டுடன் தொடர்புடையது. இந்த ஆஃப்செட்டுடன் தொடர்புடைய பதிவு நிலை அடுத்த செய்திக்கு பதிலளிக்கும் வகையில் வெளியிடப்படும் கருத்து கணிப்பு(). இந்த ஆஃப்செட் அதிகரிக்கும் காலகட்டம் வாசிப்புக்கு தீர்க்கமானது.

முன்னர் விவாதிக்கப்பட்ட வாசிப்பு மாதிரிக்குத் திரும்புகையில், செய்தி செயலாக்கம் மூன்று நிலைகளைக் கொண்டுள்ளது:

1. படிப்பதற்கு ஒரு செய்தியை மீட்டெடுக்கவும்.
2. செய்தியை செயலாக்கவும்.
3. செய்தியை உறுதிப்படுத்தவும்.

காஃப்கா நுகர்வோர் ஒரு உள்ளமைவு விருப்பத்துடன் வருகிறது enable.auto.commit. இது அடிக்கடி பயன்படுத்தப்படும் இயல்புநிலை அமைப்பாகும், இது "தானியங்கு" என்ற வார்த்தையைக் கொண்டிருக்கும் அமைப்புகளில் பொதுவானது.

காஃப்கா 0.10க்கு முன், இந்த விருப்பத்தைப் பயன்படுத்தும் கிளையன்ட் அடுத்த அழைப்பில் கடைசியாகப் படித்த செய்தியின் ஆஃப்செட்டை அனுப்புவார். கருத்து கணிப்பு() செயலாக்கத்திற்குப் பிறகு. இதன் பொருள், ஏற்கனவே பெறப்பட்ட எந்த செய்திகளையும் கிளையன்ட் ஏற்கனவே செயலாக்கியிருந்தால், ஆனால் எதிர்பாராதவிதமாக அழைப்பதற்கு முன் அழிக்கப்பட்டிருந்தால், அவை மீண்டும் செயலாக்கப்படும். கருத்து கணிப்பு(). ஒரு செய்தியை எத்தனை முறை படிக்கப்பட்டது என்பது குறித்து தரகர் எந்த நிலையையும் வைத்திருக்காததால், அந்தச் செய்தியை மீட்டெடுக்கும் அடுத்த நுகர்வோருக்கு மோசமான எதுவும் நடந்ததாகத் தெரியாது. இந்த நடத்தை போலி பரிவர்த்தனையாக இருந்தது. செய்தி வெற்றிகரமாக செயலாக்கப்பட்டால் மட்டுமே ஆஃப்செட் உறுதியானது, ஆனால் கிளையன்ட் நிறுத்தப்பட்டால், தரகர் அதே செய்தியை மற்றொரு கிளையண்டிற்கு மீண்டும் அனுப்புவார். இந்த நடத்தை செய்தி விநியோக உத்தரவாதத்துடன் ஒத்துப்போனது "ஒரு முறையாவது".

காஃப்கா 0.10 இல், கிளையன்ட் குறியீடு மாற்றப்பட்டது, அதனால் கட்டமைக்கப்பட்ட கிளையன்ட் லைப்ரரி மூலம் கமிட் அவ்வப்போது தூண்டப்படும். auto.commit.interval.ms. இந்த நடத்தை JMS AUTO_ACKNOWLEDGE மற்றும் DUPS_OK_ACKNOWLEDGE முறைகளுக்கு இடையில் உள்ளது. தன்னியக்கத்தைப் பயன்படுத்தும் போது, ​​செய்திகள் உண்மையில் செயலாக்கப்பட்டதா என்பதைப் பொருட்படுத்தாமல் செய்யப்படலாம் - இது மெதுவான நுகர்வோர் விஷயத்தில் நிகழலாம். ஒரு நுகர்வோர் கைவிடப்பட்டால், அடுத்த நுகர்வோர் உறுதியான நிலையில் இருந்து செய்திகளைப் பெறுவார்கள், இது தவறவிட்ட செய்திக்கு வழிவகுக்கும். இந்த வழக்கில், காஃப்கா செய்திகளை இழக்கவில்லை, வாசிப்பு குறியீடு அவற்றைச் செயல்படுத்தவில்லை.

இந்த பயன்முறை பதிப்பு 0.9 இல் உள்ள அதே வாக்குறுதியைக் கொண்டுள்ளது: செய்திகளை செயலாக்க முடியும், ஆனால் அது தோல்வியுற்றால், ஆஃப்செட் செய்யப்படாமல் போகலாம், இதனால் டெலிவரி இரட்டிப்பாகும். செயல்படுத்தும் போது அதிக செய்திகளைப் பெறுவீர்கள் கருத்து கணிப்பு(), மேலும் இந்த பிரச்சனை.

பக்கம் 21 இல் "வரிசையிலிருந்து செய்திகளைப் படித்தல்" இல் விவாதிக்கப்பட்டதைப் போல, தோல்வி முறைகள் கணக்கில் எடுத்துக் கொள்ளப்பட்டால், செய்தியிடல் அமைப்பில் ஒரு முறை செய்தியை வழங்குவது போன்ற எதுவும் இல்லை.

காஃப்காவில், ஆஃப்செட் (ஆஃப்செட்) செய்ய இரண்டு வழிகள் உள்ளன: தானாக மற்றும் கைமுறையாக. இரண்டு சந்தர்ப்பங்களிலும், செய்தி செயலாக்கப்பட்டாலும், உறுதிமொழிக்கு முன் தோல்வியுற்றாலும், செய்திகளை பல முறை செயலாக்க முடியும். பின்னணியில் உறுதியானது நிகழ்ந்து, அதைச் செயலாக்குவதற்கு முன்பே உங்கள் குறியீடு நிறைவுசெய்யப்பட்டிருந்தால் (ஒருவேளை காஃப்கா 0.9 மற்றும் அதற்கு முந்தையது) செய்தியைச் செயலாக்க வேண்டாம் என்று நீங்கள் தேர்வுசெய்யலாம்.

அளவுருவை அமைப்பதன் மூலம் காஃப்கா நுகர்வோர் ஏபிஐயில் கைமுறையாக ஆஃப்செட் கமிட் செயல்முறையை நீங்கள் கட்டுப்படுத்தலாம் enable.auto.commit பின்வரும் முறைகளில் ஒன்றை தவறாகவும் வெளிப்படையாகவும் அழைக்கவும்:

void commitSync();
void commitAsync();

"குறைந்தது ஒரு முறை" என்ற செய்தியைச் செயல்படுத்த விரும்பினால், நீங்கள் ஆஃப்செட்டை கைமுறையாகச் செய்ய வேண்டும் கமிட்சின்க்()செய்திகளைச் செயலாக்கிய உடனேயே இந்தக் கட்டளையை இயக்குவதன் மூலம்.

இந்த முறைகள் செய்திகளை செயலாக்குவதற்கு முன் ஒப்புக்கொள்ள அனுமதிக்காது, ஆனால் அவை பரிவர்த்தனையின் தோற்றத்தைக் கொடுக்கும் போது சாத்தியமான செயலாக்க தாமதங்களை அகற்ற எதுவும் செய்யாது. காஃப்காவில் பரிவர்த்தனைகள் எதுவும் இல்லை. வாடிக்கையாளருக்கு பின்வருவனவற்றைச் செய்யும் திறன் இல்லை:

• போலியான செய்தியைத் தானாகப் பின்வாங்கும். சிக்கல் நிறைந்த பேலோடுகள் மற்றும் பின்தளத்தில் செயலிழப்பால் ஏற்படும் விதிவிலக்குகளை நுகர்வோர் தாங்களாகவே கையாள வேண்டும், ஏனெனில் அவர்கள் செய்திகளை மீண்டும் வழங்குவதற்கு தரகரை நம்ப முடியாது.
• ஒரு அணு இயக்கத்தில் பல தலைப்புகளுக்கு செய்திகளை அனுப்பவும். நாம் விரைவில் பார்ப்பது போல, வெவ்வேறு தலைப்புகள் மற்றும் பகிர்வுகளின் மீதான கட்டுப்பாடு காஃப்கா கிளஸ்டரில் உள்ள வெவ்வேறு இயந்திரங்களில் இருக்கும், அவை அனுப்பப்படும்போது பரிவர்த்தனைகளை ஒருங்கிணைக்க முடியாது. இதை எழுதும் நேரத்தில், KIP-98 மூலம் இதைச் சாத்தியமாக்க சில வேலைகள் செய்யப்பட்டுள்ளன.
• ஒரு தலைப்பில் இருந்து ஒரு செய்தியைப் படிப்பதை மற்றொரு தலைப்புக்கு அனுப்புவதை இணைக்கவும். மீண்டும், காஃப்காவின் கட்டிடக்கலை ஒரு பேருந்தாக இயங்கும் பல சுயாதீன இயந்திரங்களைச் சார்ந்துள்ளது, இதை மறைக்க எந்த முயற்சியும் எடுக்கப்படவில்லை. எடுத்துக்காட்டாக, நீங்கள் இணைக்க அனுமதிக்கும் API கூறுகள் எதுவும் இல்லை நுகர்வோர் и தயாரிப்பாளர் ஒரு பரிவர்த்தனையில். JMS இல், இது பொருளால் வழங்கப்படுகிறது அமர்வுஅதிலிருந்து உருவாக்கப்படுகின்றன செய்தி தயாரிப்பாளர்கள் и செய்தி நுகர்வோர்.

பரிவர்த்தனைகளை நம்பியிருக்க முடியாவிட்டால், பாரம்பரிய செய்தியிடல் அமைப்புகளால் வழங்கப்படும் சொற்பொருளை எவ்வாறு வழங்குவது?

நுகர்வோர் செயலிழப்பின் போது, ​​​​செய்தி செயலாக்கப்படுவதற்கு முன்பு நுகர்வோரின் ஆஃப்செட் அதிகரிக்கும் வாய்ப்பு இருந்தால், அதன் நுகர்வோர் குழு ஒரு பகிர்வை ஒதுக்கும்போது செய்தியைத் தவறவிட்டதா என்பதை நுகர்வோர் அறிந்து கொள்ள முடியாது. எனவே ஆஃப்செட்டை முந்தைய நிலைக்கு மாற்றுவது ஒரு உத்தி. காஃப்கா நுகர்வோர் API இதற்கு பின்வரும் முறைகளை வழங்குகிறது:

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

முறை தேடுங்கள்() முறையுடன் பயன்படுத்தலாம்
ஆஃப்செட் ஃபார் டைம்ஸ்(வரைபடம் தேடலுக்கு நேர முத்திரை) கடந்த காலத்தின் சில குறிப்பிட்ட புள்ளியில் ஒரு நிலைக்குத் திரும்புவதற்கு.

மறைமுகமாக, இந்த அணுகுமுறையைப் பயன்படுத்தினால், முன்பு செயலாக்கப்பட்ட சில செய்திகள் மீண்டும் படிக்கப்பட்டு செயலாக்கப்படும் வாய்ப்பு அதிகம். இதைத் தவிர்க்க, அத்தியாயம் 4-ல் விவரிக்கப்பட்டுள்ளபடி, முன்பு பார்த்த செய்திகளைக் கண்காணிக்கவும், நகல்களை அகற்றவும், ஐடிம்போடென்ட் ரீடிங்கைப் பயன்படுத்தலாம்.

மாற்றாக, செய்தி இழப்பு அல்லது நகல் ஏற்றுக்கொள்ளப்படும் வரை உங்கள் நுகர்வோர் குறியீட்டை எளிமையாக வைத்திருக்க முடியும். பதிவு நிகழ்வுகளைக் கையாளுதல், அளவீடுகள், கிளிக் கண்காணிப்பு போன்றவற்றைப் பொதுவாகப் பயன்படுத்தப்படும் பயன்பாட்டு நிகழ்வுகளைப் பார்க்கும்போது, ​​தனிப்பட்ட செய்திகளின் இழப்பு சுற்றியுள்ள பயன்பாடுகளில் குறிப்பிடத்தக்க தாக்கத்தை ஏற்படுத்த வாய்ப்பில்லை என்பதை நாங்கள் உணர்கிறோம். இதுபோன்ற சந்தர்ப்பங்களில், இயல்புநிலை மதிப்புகள் முற்றிலும் ஏற்றுக்கொள்ளத்தக்கவை. மறுபுறம், உங்கள் விண்ணப்பம் பணம் அனுப்ப வேண்டும் என்றால், நீங்கள் ஒவ்வொரு தனிப்பட்ட செய்தியையும் கவனமாகக் கவனிக்க வேண்டும். இது அனைத்தும் சூழலைப் பொறுத்தது.

தனிப்பட்ட அவதானிப்புகள் செய்திகளின் தீவிரம் அதிகரிக்கும் போது, ​​ஒவ்வொரு தனிப்பட்ட செய்தியின் மதிப்பும் குறைகிறது என்பதைக் காட்டுகிறது. ஒருங்கிணைக்கப்பட்ட வடிவத்தில் பார்க்கும் போது பெரிய செய்திகள் மதிப்புமிக்கதாக இருக்கும்.

அதிக கிடைக்கும் தன்மை

அதிக கிடைக்கும் தன்மைக்கான காஃப்காவின் அணுகுமுறை ActiveMQ இன் அணுகுமுறையிலிருந்து மிகவும் வேறுபட்டது. அனைத்து தரகர் நிகழ்வுகளும் ஒரே நேரத்தில் செய்திகளைப் பெற்று விநியோகிக்கும் ஸ்கேல்-அவுட் கிளஸ்டர்களைச் சுற்றி காஃப்கா வடிவமைக்கப்பட்டுள்ளது.

ஒரு காஃப்கா கிளஸ்டர் வெவ்வேறு சேவையகங்களில் இயங்கும் பல தரகர் நிகழ்வுகளைக் கொண்டுள்ளது. காஃப்கா சாதாரண தனித்த வன்பொருளில் இயங்கும் வகையில் வடிவமைக்கப்பட்டுள்ளது, அங்கு ஒவ்வொரு முனையும் அதன் சொந்த பிரத்யேக சேமிப்பகத்தைக் கொண்டுள்ளது. நெட்வொர்க் இணைக்கப்பட்ட சேமிப்பகத்தைப் (SAN) பயன்படுத்துவது பரிந்துரைக்கப்படவில்லை, ஏனெனில் பல கம்ப்யூட் முனைகள் நேரத்துக்குப் போட்டியிடலாம்.Ыஇ சேமிப்பு இடைவெளிகள் மற்றும் மோதல்களை உருவாக்குதல்.

காஃப்கா தான் எப்போதும் அமைப்பு. பல பெரிய காஃப்கா பயனர்கள் தங்கள் க்ளஸ்டர்களை ஒருபோதும் மூடுவதில்லை, மேலும் மென்பொருள் எப்போதும் தொடர்ச்சியான மறுதொடக்கத்துடன் புதுப்பிக்கப்படும். செய்திகள் மற்றும் தரகர்களுக்கிடையேயான தொடர்புகளுக்கு முந்தைய பதிப்போடு இணக்கத்தன்மைக்கு உத்தரவாதம் அளிப்பதன் மூலம் இது அடையப்படுகிறது.

சர்வர் கிளஸ்டருடன் இணைக்கப்பட்ட தரகர்கள் மிருகக்காட்சிசாலை காவலர், இது ஒரு கட்டமைப்பு தரவு பதிவேடாக செயல்படுகிறது மற்றும் ஒவ்வொரு தரகரின் பாத்திரங்களையும் ஒருங்கிணைக்கப் பயன்படுகிறது. ZooKeeper என்பது ஒரு விநியோகிக்கப்பட்ட அமைப்பாகும், இது நிறுவுவதன் மூலம் தகவலைப் பிரதியெடுப்பதன் மூலம் அதிக கிடைப்பதை வழங்குகிறது கோரம்.

அடிப்படை வழக்கில், ஒரு தலைப்பு பின்வரும் பண்புகளுடன் காஃப்கா கிளஸ்டரில் உருவாக்கப்படுகிறது:

• பகிர்வுகளின் எண்ணிக்கை. முன்னர் விவாதிக்கப்பட்டபடி, இங்கே பயன்படுத்தப்படும் சரியான மதிப்பு இணையான வாசிப்பின் விரும்பிய அளவைப் பொறுத்தது.
• இந்த பகிர்வுக்கான பதிவுகளை கிளஸ்டரில் எத்தனை தரகர் நிகழ்வுகள் கொண்டிருக்க வேண்டும் என்பதை பிரதி காரணி (காரணி) தீர்மானிக்கிறது.

ஒருங்கிணைப்பிற்காக ZooKeepers ஐப் பயன்படுத்தி, கிளஸ்டரில் உள்ள தரகர்களிடையே புதிய பகிர்வுகளை நியாயமான முறையில் விநியோகிக்க காஃப்கா முயற்சிக்கிறது. இது ஒரு கட்டுப்படுத்தியாக செயல்படும் ஒரு நிகழ்வால் செய்யப்படுகிறது.

இயக்க நேரத்தில் ஒவ்வொரு தலைப்பு பகிர்வுக்கும் கட்டுப்படுத்தி ஒரு தரகருக்கு பாத்திரங்களை ஒதுக்குங்கள் தலைவர் (தலைவர், மாஸ்டர், வழங்குபவர்) மற்றும் பின்பற்றுபவர்கள் (பின்தொடர்பவர்கள், அடிமைகள், கீழ்படிந்தவர்கள்). இந்த பிரிவின் தலைவராக செயல்படும் தரகர், தயாரிப்பாளர்களால் அனுப்பப்படும் அனைத்து செய்திகளையும் பெறுவதற்கும், நுகர்வோருக்கு செய்திகளை விநியோகிக்கும் பொறுப்பாகும். தலைப்புப் பகிர்வுக்கு செய்திகள் அனுப்பப்படும்போது, ​​அந்தப் பகிர்வுக்குப் பின்தொடர்பவர்களாகச் செயல்படும் அனைத்து தரகர் முனைகளுக்கும் அவை நகலெடுக்கப்படும். ஒரு பகிர்வுக்கான பதிவுகளைக் கொண்ட ஒவ்வொரு முனையும் அழைக்கப்படுகிறது பிரதி. ஒரு தரகர் சில பகிர்வுகளுக்கு தலைவராகவும் மற்றவர்களுக்கு பின்தொடர்பவராகவும் செயல்பட முடியும்.

தலைவர் வைத்திருக்கும் அனைத்து செய்திகளையும் கொண்ட பின்தொடர்பவர் அழைக்கப்படுகிறார் ஒத்திசைக்கப்பட்ட பிரதி (ஒத்திசைக்கப்பட்ட நிலையில் உள்ள ஒரு பிரதி, ஒத்திசைவு பிரதி). ஒரு பிரிவின் தலைவராகச் செயல்படும் ஒரு தரகர் வீழ்ச்சியடைந்தால், புதுப்பித்த அல்லது அந்தப் பகிர்வுக்கு ஒத்திசைக்கப்பட்ட எந்தவொரு தரகரும் தலைமைப் பொறுப்பை ஏற்க முடியும். இது நம்பமுடியாத நிலையான வடிவமைப்பு.

தயாரிப்பாளர் கட்டமைப்பின் ஒரு பகுதி அளவுருவாகும் ஆக்ஸ், விண்ணப்பத் தொடரிழை அனுப்புவதற்கு முன், ஒரு செய்தியின் ரசீதை எத்தனை பிரதிகள் ஒப்புக்கொள்ள வேண்டும் (ஒப்புக்கொள்ள வேண்டும்) என்பதை இது தீர்மானிக்கிறது: 0, 1 அல்லது அனைத்தும். என அமைத்தால் அனைத்து, பின்னர் ஒரு செய்தியைப் பெறும்போது, ​​தலைப்பு அமைப்பால் வரையறுக்கப்பட்ட பல குறிப்புகளிலிருந்து (தன்னையும் சேர்த்து) பதிவின் உறுதிப்படுத்தல்களை (ஒப்புகைகள்) பெற்றவுடன், தலைவர் மீண்டும் தயாரிப்பாளருக்கு ஒரு உறுதிப்படுத்தலை அனுப்புவார். min.insync.replicas (இயல்புநிலை 1). செய்தியை வெற்றிகரமாக நகலெடுக்க முடியாவிட்டால், தயாரிப்பாளர் ஒரு விண்ணப்ப விதிவிலக்கு (NotEnoughReplicas அல்லது NotEnoughReplicasAfterAppend).

ஒரு பொதுவான கட்டமைப்பு 3 (1 தலைவர், ஒரு பகிர்வுக்கு 2 பின்தொடர்பவர்கள்) மற்றும் அளவுருவின் பிரதி காரணியுடன் ஒரு தலைப்பை உருவாக்குகிறது min.insync.replicas 2 ஆக அமைக்கப்பட்டுள்ளது. இந்த வழக்கில், கிளையன்ட் பயன்பாடுகளை பாதிக்காமல் தலைப்பு பகிர்வை நிர்வகிக்கும் தரகர்களில் ஒருவரை கிளஸ்டர் அனுமதிக்கும்.

செயல்திறன் மற்றும் நம்பகத்தன்மைக்கு இடையே ஏற்கனவே பழக்கமான பரிமாற்றத்திற்கு இது நம்மை மீண்டும் கொண்டு வருகிறது. பின்தொடர்பவர்களிடமிருந்து உறுதிப்படுத்தல்களுக்கான (ஒப்புகைகள்) கூடுதல் காத்திருப்பு நேரத்தின் செலவில் பிரதி நிகழ்கிறது. இருப்பினும், இது இணையாக இயங்குவதால், குறைந்தபட்சம் மூன்று முனைகளுக்கு நகலெடுப்பது இரண்டின் அதே செயல்திறனைக் கொண்டுள்ளது (நெட்வொர்க் அலைவரிசை பயன்பாட்டின் அதிகரிப்பைப் புறக்கணிக்கிறது).

இந்த நகலெடுக்கும் திட்டத்தைப் பயன்படுத்துவதன் மூலம், செயல்பாட்டின் மூலம் ஒவ்வொரு செய்தியையும் வட்டில் எழுத வேண்டிய அவசியத்தை காஃப்கா புத்திசாலித்தனமாக தவிர்க்கிறார். ஒத்திசை (). தயாரிப்பாளரால் அனுப்பப்படும் ஒவ்வொரு செய்தியும் பகிர்வு பதிவில் எழுதப்படும், ஆனால் அத்தியாயம் 2 இல் விவாதிக்கப்பட்டபடி, ஒரு கோப்பில் எழுதுவது முதலில் இயக்க முறைமையின் இடையகத்தில் செய்யப்படுகிறது. இந்தச் செய்தி மற்றொரு காஃப்கா நிகழ்விற்குப் பிரதியெடுத்து, அதன் நினைவகத்தில் இருந்தால், தலைவரின் இழப்பு என்பது அந்தச் செய்தியை இழந்துவிட்டது என்று அர்த்தமல்ல - அது ஒரு ஒத்திசைக்கப்பட்ட பிரதியால் எடுத்துக்கொள்ளப்படலாம்.
அறுவை சிகிச்சை செய்ய மறுப்பது ஒத்திசை () காஃப்காவால் செய்திகளை நினைவகத்தில் எழுதுவது போல் வேகமாகப் பெற முடியும். மாறாக, எவ்வளவு காலம் நினைவகத்தை வட்டில் பாய்ச்சுவதைத் தவிர்க்க முடியுமோ அவ்வளவு சிறந்தது. இந்த காரணத்திற்காக, காஃப்கா தரகர்களுக்கு 64 ஜிபி அல்லது அதற்கு மேற்பட்ட நினைவகம் ஒதுக்கப்படுவது அசாதாரணமானது அல்ல. இந்த நினைவக பயன்பாடு என்பது ஒரு காஃப்கா நிகழ்வானது பாரம்பரிய செய்தி தரகரை விட பல ஆயிரம் மடங்கு வேகத்தில் எளிதாக இயங்கும்.

செயல்பாட்டைப் பயன்படுத்துவதற்கு காஃப்காவையும் கட்டமைக்க முடியும் ஒத்திசை () செய்தி தொகுப்புகளுக்கு. காஃப்காவில் உள்ள அனைத்தும் தொகுப்பு சார்ந்தவை என்பதால், இது உண்மையில் பல பயன்பாட்டு நிகழ்வுகளுக்கு நன்றாக வேலை செய்கிறது மற்றும் மிகவும் வலுவான உத்தரவாதங்கள் தேவைப்படும் பயனர்களுக்கு இது ஒரு பயனுள்ள கருவியாகும். காஃப்காவின் தூய செயல்திறனின் பெரும்பகுதி தரகருக்கு பாக்கெட்டுகளாக அனுப்பப்படும் செய்திகளிலிருந்து வருகிறது, மேலும் இந்தச் செய்திகள் தரகரிடமிருந்து தொடர்ச்சியான தொகுதிகளைப் பயன்படுத்தி வாசிக்கப்படுகின்றன. பூஜ்ஜிய நகல் செயல்பாடுகள் (ஒரு நினைவக பகுதியிலிருந்து மற்றொரு இடத்திற்கு தரவை நகலெடுக்கும் பணி செய்யப்படாத செயல்பாடுகள்). பிந்தையது ஒரு பெரிய செயல்திறன் மற்றும் வள ஆதாயம் மற்றும் பகிர்வு திட்டத்தை வரையறுக்கும் ஒரு அடிப்படை பதிவு தரவு கட்டமைப்பைப் பயன்படுத்துவதன் மூலம் மட்டுமே சாத்தியமாகும்.

ஒரு காஃப்கா ப்ரோக்கரை விட காஃப்கா கிளஸ்டரில் மிகச் சிறந்த செயல்திறன் சாத்தியமாகும், ஏனெனில் தலைப்புப் பகிர்வுகள் பல தனி இயந்திரங்களில் அளவிட முடியும்.

முடிவுகளை

இந்த அத்தியாயத்தில், வாடிக்கையாளர்களுக்கும் தரகர்களுக்கும் இடையேயான உறவை எப்படி காஃப்கா கட்டிடக்கலை மறுவடிவமைத்து நம்பமுடியாத அளவிற்கு வலுவான செய்தியிடல் பைப்லைனை வழங்குகிறது, வழக்கமான மெசேஜ் புரோக்கரை விட பல மடங்கு அதிகமான செயல்திறனுடன். இதை அடைவதற்கு இது பயன்படுத்தும் செயல்பாடுகளை நாங்கள் விவாதித்தோம் மற்றும் இந்த செயல்பாட்டை வழங்கும் பயன்பாடுகளின் கட்டமைப்பை சுருக்கமாகப் பார்த்தோம். அடுத்த அத்தியாயத்தில், செய்தியிடல் அடிப்படையிலான பயன்பாடுகள் தீர்க்க வேண்டிய பொதுவான சிக்கல்களைப் பார்ப்போம் மற்றும் அவற்றைக் கையாள்வதற்கான உத்திகளைப் பற்றி விவாதிப்போம். பொதுவாக மெசேஜிங் தொழில்நுட்பங்களைப் பற்றி எப்படிப் பேசுவது என்பதைக் கோடிட்டுக் காட்டுவதன் மூலம் அத்தியாயத்தை முடிப்போம், எனவே உங்கள் பயன்பாட்டு நிகழ்வுகளுக்கு அவற்றின் பொருத்தத்தை நீங்கள் மதிப்பீடு செய்யலாம்.

முந்தைய மொழிபெயர்க்கப்பட்ட பகுதி: செய்தி தரகர்களைப் புரிந்துகொள்வது. ActiveMQ மற்றும் Kafka மூலம் செய்தி அனுப்பும் இயக்கவியல் கற்றல். அத்தியாயம் 1

மொழிபெயர்ப்பு முடிந்தது: tele.gg/middle_java

தொடர வேண்டும் ...

பதிவு செய்த பயனர்கள் மட்டுமே கணக்கெடுப்பில் பங்கேற்க முடியும். உள்நுழையவும், தயவு செய்து.

உங்கள் நிறுவனத்தில் காஃப்கா பயன்படுத்தப்படுகிறதா?

• ஆம்

• இல்லை

• முன்பு பயன்படுத்தப்பட்டது, இப்போது இல்லை

• பயன்படுத்த திட்டமிட்டுள்ளோம்

38 பயனர்கள் வாக்களித்தனர். 8 பயனர்கள் வாக்களிக்கவில்லை.

ஆதாரம்: www.habr.com