காஃப்காவில் ஒத்திசைவற்ற API உடன் பணத்தைத் திரும்பப்பெறும் கருவி சேவையை மேம்படுத்துவதில் அனுபவம்

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

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

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

செயல்முறை பற்றி

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

நிகழ்வுகள் சார்ந்த API உடன் பணத்தைத் திரும்பப்பெறும் கருவி

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

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

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

எங்கள் உந்துதல்:

1. சட்டம் FZ-54 - சுருக்கமாகச் சொன்னால், ஒவ்வொரு பணப் பரிவர்த்தனையைப் பற்றியும், அது வருமானம் அல்லது ரசீது, ஒரு சில நிமிடங்களுக்குள் மிகக் குறுகிய SLA-க்குள் வரி அலுவலகத்திற்குப் புகாரளிக்க வேண்டும். நாங்கள், ஒரு இ-காமர்ஸ் நிறுவனமாக, நிறைய செயல்பாடுகளை மேற்கொள்கிறோம். தொழில்நுட்ப ரீதியாக, இது புதிய பொறுப்பு (அதனால் ஒரு புதிய சேவை) மற்றும் அனைத்து சம்பந்தப்பட்ட அமைப்புகளிலும் மேம்பாடுகள்.
2. BOB பிளவு BOB ஐ அதிக எண்ணிக்கையிலான முக்கிய அல்லாத பொறுப்புகளில் இருந்து விடுவித்து, அதன் ஒட்டுமொத்த சிக்கலைக் குறைக்கும் நிறுவனத்தின் உள் திட்டமாகும்.

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

BOB நிறைய பரிமாற்றங்களைக் கொண்டுள்ளது: கட்டண முறைகள், விநியோக அமைப்புகள், அறிவிப்பு அமைப்புகள் போன்றவை.

தொழில்நுட்ப ரீதியாக BOB:

• ~150k கோடுகள் குறியீடு + ~100k சோதனைகள்;
• php7.2 + Zend 1 & Symfony கூறுகள் 3;
• >100 APIகள் & ~50 வெளிச்செல்லும் ஒருங்கிணைப்புகள்;
• தங்கள் சொந்த வணிக தர்க்கத்துடன் 4 நாடுகள்.

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

திரும்பும் செயல்முறை

ஆரம்பத்தில், இரண்டு அமைப்புகள் செயல்பாட்டில் ஈடுபட்டுள்ளன: BOB மற்றும் கட்டணம். இப்போது மேலும் இரண்டு தோன்றும்:

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

இப்போது செயல்முறை இதுபோல் தெரிகிறது:

1. BOB பணத்தைத் திரும்பப் பெறுவதற்கான கோரிக்கையைப் பெறுகிறது.
2. BOB இந்த ரீஃபண்ட் டூல் பற்றி பேசுகிறது.
3. பணத்தைத் திரும்பப்பெறும் கருவி பணம் செலுத்துவதற்குச் சொல்கிறது: "பணத்தைத் திருப்பித் தரவும்."
4. பணம் செலுத்துதல் பணத்தை திருப்பித் தருகிறது.
5. பணத்தைத் திரும்பப்பெறும் கருவி மற்றும் BOB ஆகியவை நிலைகளை ஒன்றோடொன்று ஒத்திசைக்கின்றன, ஏனெனில் இப்போது அவை இரண்டும் தேவை. BOB க்கு UI, கணக்கியலுக்கான அறிக்கைகள் மற்றும் பொதுவாக அவ்வளவு எளிதாகப் பரிமாற்ற முடியாத தரவுகள் இருப்பதால், பணத்தைத் திரும்பப்பெறும் கருவிக்கு முழுமையாக மாற நாங்கள் இன்னும் தயாராக இல்லை. நீங்கள் இரண்டு நாற்காலிகளில் உட்கார வேண்டும்.
6. நிதியாக்கத்திற்கான கோரிக்கை நீங்கும்.

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

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

நிகழ்வுகளால் இயக்கப்படும் API என்றால் என்ன

இந்தக் கேள்விக்கான நல்ல பதில் மார்ட்டின் ஃபோலர் (GOTO 2017) அறிக்கையில் உள்ளது. "நிகழ்வு-உந்துதல் கட்டிடக்கலையின் பல அர்த்தங்கள்".

சுருக்கமாக நாம் என்ன செய்தோம்:

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

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

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

ஒத்திசைவு பரிமாற்றம்

ஒத்திசைவற்ற பரிமாற்றங்களுக்கு, PHP துறை பொதுவாக RabbitMQ ஐப் பயன்படுத்துகிறது. கோரிக்கைக்கான தரவை நாங்கள் சேகரித்தோம், அதை ஒரு வரிசையில் வைத்தோம், அதே சேவையின் நுகர்வோர் அதைப் படித்து அனுப்பினார் (அல்லது அனுப்பவில்லை). API க்காகவே, Lamoda தீவிரமாக Swagger ஐப் பயன்படுத்துகிறது. நாங்கள் APIயை வடிவமைத்து, ஸ்வாக்கரில் விவரிக்கிறோம் மற்றும் கிளையன்ட் மற்றும் சர்வர் குறியீட்டை உருவாக்குகிறோம். நாங்கள் சற்று மேம்படுத்தப்பட்ட JSON RPC 2.0 ஐயும் பயன்படுத்துகிறோம்.

சில இடங்களில் ESB பேருந்துகள் பயன்படுத்தப்படுகின்றன, சில ActiveMQ இல் வாழ்கின்றன, ஆனால், பொதுவாக, RabbitMQ - தரநிலை.

ஒத்திசைவு பரிமாற்றம் இருக்க வேண்டும்

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

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

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

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

நிகழ்வுகள் - பேருந்து

அல்லது நிகழ்வு பேருந்து. இது ஒரு நிலையற்ற http நுழைவாயில், இது பல முக்கிய பாத்திரங்களை வகிக்கிறது:

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

ஏன்

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

1:n+1 பரிமாற்றங்கள் (ஒன்று முதல் பல வரை)

புதிய நுகர்வோரை API உடன் இணைப்பதை காஃப்கா மிகவும் எளிதாக்குகிறது.

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

BOB இன் ஒரு பகுதியான refund-tool விஷயத்தில், அவற்றை காஃப்கா மூலம் ஒத்திசைத்து வைத்திருப்பது எங்களுக்கு வசதியானது. பணம் திரும்ப வந்ததாக பேமென்ட் கூறுகிறது: BOB, RT இதைப் பற்றி கண்டுபிடித்து, அவர்களின் நிலைகளை மாற்றியது, Fiscalization Service இதைப் பற்றி கண்டுபிடித்து ஒரு காசோலையை வழங்கியது.

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

தரவு உந்துதல்

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

பிரதி பதிவு

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

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

அடுத்து, காஃப்காவைப் பற்றி அறிமுகமில்லாதவர்களுக்கு, ஆவணத்தின் ஒரு சிறிய மறுபரிசீலனை (படமும் ஆவணத்தில் இருந்து)

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

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

அதன்படி, வெவ்வேறு தர்க்கங்களை செயல்படுத்தலாம். எடுத்துக்காட்டாக, வெவ்வேறு நாடுகளுக்கு 4 நிகழ்வுகளில் BOB உள்ளது - லமோடா ரஷ்யா, கஜகஸ்தான், உக்ரைன், பெலாரஸ் ஆகிய நாடுகளில் உள்ளது. அவை தனித்தனியாக பயன்படுத்தப்படுவதால், அவை சற்று வித்தியாசமான கட்டமைப்புகளையும் அவற்றின் சொந்த வணிக தர்க்கத்தையும் கொண்டுள்ளன. அது எந்த நாட்டைக் குறிக்கிறது என்பதை செய்தியில் குறிப்பிடுகிறோம். ஒவ்வொரு நாட்டிலும் உள்ள ஒவ்வொரு BOB நுகர்வோரும் வெவ்வேறு குரூப்ஐடியுடன் படிக்கிறார்கள், மேலும் அந்தச் செய்தி அவர்களுக்குப் பொருந்தவில்லை என்றால், அவர்கள் அதைத் தவிர்க்கிறார்கள், அதாவது. உடனடியாக ஆஃப்செட் +1 செய்கிறது. எங்கள் கட்டணச் சேவையால் அதே தலைப்பைப் படித்தால், அது ஒரு தனிக் குழுவுடன் செய்கிறது, எனவே ஆஃப்செட்கள் குறுக்கிடாது.

நிகழ்வு தேவைகள்:

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

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

லமோடாவில் காஃப்கா

எங்களிடம் மூன்று காஃப்கா நிறுவல்கள் உள்ளன:

1. பதிவுகள்;
2. R&D;
3. நிகழ்வுகள் - பேருந்து.

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

மேலே rps வரைபடம் உள்ளது. பணத்தைத் திரும்பப்பெறுதல் செயல்முறையானது டர்க்கைஸ் கோட்டால் குறிக்கப்பட்டுள்ளது (ஆம், X அச்சில் உள்ளது), மேலும் இளஞ்சிவப்பு கோடு உள்ளடக்க புதுப்பிப்பு செயல்முறையாகும்.

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

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

லமோடா நிகழ்வுகள் வழக்குகளைப் பயன்படுத்துகின்றன

பின்வரும் செயல்பாடுகளுக்கு நாங்கள் கட்டமைக்கப்பட்ட கட்டமைப்பைப் பயன்படுத்துகிறோம்:

• திரும்ப நிலை கண்காணிப்பு: சம்பந்தப்பட்ட அனைத்து அமைப்புகளிலிருந்தும் நடவடிக்கை மற்றும் நிலை கண்காணிப்பு. பணம் செலுத்துதல், நிலைகள், நிதியாக்கம், அறிவிப்புகள். இங்கே நாங்கள் அணுகுமுறையை சோதித்தோம், கருவிகளை உருவாக்கினோம், அனைத்து பிழைகளையும் சேகரித்தோம், ஆவணங்களை எழுதினோம் மற்றும் அதை எவ்வாறு பயன்படுத்துவது என்று எங்கள் சக ஊழியர்களிடம் கூறினோம்.
• தயாரிப்பு அட்டைகளைப் புதுப்பிக்கிறது: கட்டமைப்பு, மெட்டா-டேட்டா, பண்புகள். ஒரு அமைப்பு படிக்கிறது (இது காண்பிக்கும்), மற்றும் பல எழுதுகிறது.
• மின்னஞ்சல், புஷ் மற்றும் எஸ்எம்எஸ்: ஆர்டர் கலெக்ட் ஆனது, ஆர்டர் வந்துவிட்டது, ரிட்டர்ன் ஏற்கப்பட்டது, போன்றவை நிறைய உள்ளன.
• பங்கு, கிடங்கு புதுப்பித்தல் - பொருட்களின் அளவு புதுப்பித்தல், வெறும் எண்கள்: கிடங்கிற்கு வருகை, திரும்புதல். பொருட்களை முன்பதிவு செய்வதோடு தொடர்புடைய அனைத்து அமைப்புகளும் தற்போதைய தரவுகளுடன் செயல்படுவது அவசியம். தற்போது, ​​பங்கு புதுப்பித்தல் அமைப்பு மிகவும் சிக்கலானது; காஃப்கா அதை எளிதாக்கும்.
• தரவு பகுப்பாய்வு (R&D துறை), ML கருவிகள், பகுப்பாய்வு, புள்ளிவிவரங்கள். தகவல் வெளிப்படையாக இருக்க வேண்டும் என்று நாங்கள் விரும்புகிறோம் - காஃப்கா இதற்கு மிகவும் பொருத்தமானவர்.

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

வடிவமைப்பு சிக்கல்கள்

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

இவை ஒரே மாதிரியான பகுதிகளாகத் தெரிகிறது, ஆனால் BOB இல் உள்ள ஆர்டர் செயலாக்கம் மற்றும் ஷிப்பிங் சிஸ்டம் ஆகியவை வெவ்வேறு நிலைகளைக் கொண்டுள்ளன. எடுத்துக்காட்டாக, சில கூரியர் சேவைகள் இடைநிலை நிலைகளை அனுப்புவதில்லை, ஆனால் இறுதியானவை மட்டுமே: "வழங்கப்பட்டது" அல்லது "இழந்தது". மற்றவர்கள், மாறாக, பொருட்களின் இயக்கம் பற்றி மிக விரிவாக அறிக்கை செய்கிறார்கள். ஒவ்வொருவருக்கும் அவர்களின் சொந்த சரிபார்ப்பு விதிகள் உள்ளன: சிலருக்கு, மின்னஞ்சல் செல்லுபடியாகும், அதாவது அது செயலாக்கப்படும்; மற்றவர்களுக்கு இது செல்லுபடியாகாது, ஆனால் தொடர்புக்கான தொலைபேசி எண் இருப்பதால் ஆர்டர் இன்னும் செயலாக்கப்படும், மேலும் அத்தகைய ஆர்டர் செயலாக்கப்படாது என்று யாராவது கூறுவார்கள்.

தரவு ஸ்ட்ரீம்

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

ஒரு தலைப்பில் அல்லது வெவ்வேறு தலைப்புகளில்?

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

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

புதிய களமா அல்லது புதிய நிகழ்வா?

ஆனால் அதே நிகழ்வுகளைப் பயன்படுத்தினால், மற்றொரு சிக்கல் எழுகிறது. எடுத்துக்காட்டாக, அனைத்து விநியோக அமைப்புகளும் BOB உருவாக்கக்கூடிய DTOவை உருவாக்க முடியாது. நாங்கள் அவர்களுக்கு ஐடியை அனுப்புகிறோம், ஆனால் அவர்கள் அதைச் சேமிக்கவில்லை, ஏனெனில் அவர்களுக்கு இது தேவையில்லை, மேலும் நிகழ்வு-பஸ் செயல்முறையைத் தொடங்கும் பார்வையில், இந்த புலம் தேவைப்படுகிறது.

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

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

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

நிகழ்வு பதிப்பு

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

பகிர்வுகளின் உத்தரவாத வாசிப்பு வரிசை

காஃப்காவில் உள்ள தலைப்புகள் பகிர்வுகளாக பிரிக்கப்பட்டுள்ளன. நாங்கள் நிறுவனங்கள் மற்றும் பரிமாற்றங்களை வடிவமைக்கும் போது இது மிகவும் முக்கியமல்ல, ஆனால் அதை எவ்வாறு நுகர்வது மற்றும் அளவிடுவது என்பதை தீர்மானிக்கும் போது இது முக்கியமானது.

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

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

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

நிகழ்வுகள் vs கட்டளைகள்

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

ஆனால் வழக்கமாக, நீங்கள் நிகழ்வுகளை வடிவமைக்கும்போது, ​​​​அவற்றை வீணாக எழுத விரும்பவில்லை - யாராவது அவற்றைப் படிப்பார்கள் என்ற உண்மையை நீங்கள் நம்பியிருக்கிறீர்கள். ஏதாவது_நடந்தது (உருப்படி_ரத்துசெய்யப்பட்டது, திரும்பப்பெறப்பட்டது) என்று எழுதுவதற்கு அதிக ஆசை உள்ளது, ஆனால் ஏதாவது_செய்யப்பட வேண்டும். எடுத்துக்காட்டாக, உருப்படி திரும்பப் பெறத் தயாராக உள்ளது.

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

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

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

நுணுக்கங்களை

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

நாங்கள் அதைப் பற்றி அறிந்தோம், நாங்கள் அதை எண்ணினோம், இன்னும் அது நடந்தது. நிகழ்வுகள்-பஸ்ஸின் பார்வையில் இருந்து நிகழ்வு செல்லுபடியாகும் என்பதால் இது நடந்தது, பயன்பாட்டு வேலிடேட்டரின் பார்வையில் நிகழ்வு செல்லுபடியாகும், ஆனால் PostgreSQL இன் பார்வையில் இது செல்லுபடியாகாது, ஏனெனில் எங்கள் ஒரு அமைப்பில் UNSIGNED INT உடன் MySQL, மற்றும் புதிதாக எழுதப்பட்ட கணினியில் PostgreSQL ஐ INT உடன் இருந்தது. அவரது அளவு கொஞ்சம் சிறியது, மற்றும் ஐடி பொருந்தவில்லை. சிம்ஃபோனி விதிவிலக்காக இறந்தார். நாங்கள் நிச்சயமாக விதிவிலக்கைப் பிடித்தோம், ஏனெனில் நாங்கள் அதை நம்பியிருந்தோம், மேலும் இந்த ஆஃப்செட்டைச் செய்யப் போகிறோம், ஆனால் அதற்கு முன் சிக்கல் கவுண்டரை அதிகரிக்க விரும்பினோம், ஏனெனில் செய்தி தோல்வியுற்றது. இந்த திட்டத்தில் உள்ள கவுண்டர்கள் தரவுத்தளத்தில் உள்ளன, மேலும் சிம்ஃபோனி ஏற்கனவே தரவுத்தளத்துடன் தொடர்பை மூடியுள்ளது, மேலும் இரண்டாவது விதிவிலக்கு முழு செயல்முறையையும் ஈடுசெய்ய வாய்ப்பில்லாமல் கொன்றது.

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

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

மற்றொரு நுணுக்கம் - பிரதி பதிவு vs rdkafka.so - எங்கள் திட்டத்தின் பிரத்தியேகங்களுடன் தொடர்புடையது. நாங்கள் PHP ஐப் பயன்படுத்துகிறோம், மேலும் PHP இல், ஒரு விதியாக, அனைத்து நூலகங்களும் rdkafka.so களஞ்சியத்தின் மூலம் காஃப்காவுடன் தொடர்பு கொள்கின்றன, பின்னர் ஒருவித ரேப்பர் உள்ளது. ஒருவேளை இவை எங்கள் தனிப்பட்ட சிரமங்களாக இருக்கலாம், ஆனால் நாம் ஏற்கனவே படித்தவற்றின் ஒரு பகுதியை மீண்டும் படிப்பது அவ்வளவு எளிதானது அல்ல. பொதுவாக, மென்பொருள் சிக்கல்கள் இருந்தன.

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

கண்காணிப்பு

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

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

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

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

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

API பதில் இப்படித்தான் இருக்கும். இங்கே குழு bob-live-fifa, பகிர்வு refund.update.v1, நிலை சரி, லேக் 0 - இது போன்ற கடைசி இறுதி ஆஃப்செட்.

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

சுருக்கமாக, நிகழ்வுகளைப் பயன்படுத்துவது வசதியானது:

• பல அமைப்புகளுக்கு தகவல் தேவைப்படுகிறது;
• செயலாக்கத்தின் முடிவு முக்கியமல்ல;
• சில நிகழ்வுகள் அல்லது சிறிய நிகழ்வுகள் உள்ளன.

கட்டுரையில் ஒரு குறிப்பிட்ட தலைப்பு இருப்பதாகத் தோன்றுகிறது - காஃப்காவில் ஒத்திசைவற்ற ஏபிஐ, ஆனால் அது தொடர்பாக நான் ஒரே நேரத்தில் நிறைய விஷயங்களைப் பரிந்துரைக்க விரும்புகிறேன்.
முதலில், அடுத்தது ஹைலோட்++ நாங்கள் நவம்பர் வரை காத்திருக்க வேண்டும்; ஏப்ரல் மாதத்தில் செயின்ட் பீட்டர்ஸ்பர்க் பதிப்பு இருக்கும், ஜூன் மாதத்தில் நோவோசிபிர்ஸ்கில் அதிக சுமைகளைப் பற்றி பேசுவோம்.
இரண்டாவதாக, அறிக்கையின் ஆசிரியர், செர்ஜி ஜைகா, அறிவு மேலாண்மை குறித்த எங்கள் புதிய மாநாட்டின் திட்டக் குழுவில் உறுப்பினராக உள்ளார். KnowledgeConf. மாநாடு ஒரு நாள், ஏப்ரல் 26 அன்று நடைபெறும், ஆனால் அதன் வேலைத்திட்டம் மிகவும் தீவிரமானது.
அது மே மாதத்தில் இருக்கும் PHP ரஷ்யா и RIT++ (DevOpsConf உடன் சேர்க்கப்பட்டுள்ளது) - நீங்கள் அங்கு உங்கள் தலைப்பைப் பரிந்துரைக்கலாம், உங்கள் அனுபவத்தைப் பற்றி பேசலாம் மற்றும் உங்கள் அடைத்த கூம்புகளைப் பற்றி புகார் செய்யலாம்.

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