மிகைல் சலோசின். கோலாங் சந்திப்பு. Look+ பயன்பாட்டின் பின்தளத்தில் Go ஐப் பயன்படுத்துதல்

மிகைல் சலோசின் (இனி - எம்.எஸ்): - அனைவருக்கும் வணக்கம்! என் பெயர் மைக்கேல். நான் MC2 மென்பொருளில் பின்தள டெவலப்பராக பணிபுரிகிறேன், மேலும் Look+ மொபைல் பயன்பாட்டின் பின்தளத்தில் Go ஐப் பயன்படுத்துவதைப் பற்றி பேசுவேன்.

இங்கு யாருக்காவது ஹாக்கி பிடிக்குமா?

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

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

வளர்ச்சியில் நீங்கள் எதைப் பயன்படுத்தினீர்கள்?

முக்கிய பகுதி கோவில் எழுதப்பட்டது. மொபைல் கிளையண்ட்கள் தொடர்பு கொண்ட API Go இல் எழுதப்பட்டது. மொபைல் போன்களுக்கு புஷ் அறிவிப்புகளை அனுப்புவதற்கான சேவையும் Go இல் எழுதப்பட்டுள்ளது. எங்களுடைய சொந்த ORM ஐயும் எழுத வேண்டியிருந்தது, அதைப் பற்றி எப்போதாவது பேசலாம். சரி, சில சிறிய சேவைகள் Go இல் எழுதப்பட்டுள்ளன: எடிட்டர்களுக்கான படங்களை மறுஅளவிடுதல் மற்றும் ஏற்றுதல்...

PostgreSQLஐ தரவுத்தளமாகப் பயன்படுத்தினோம். ஆக்டிவ் அட்மின் ரத்தினத்தைப் பயன்படுத்தி ரூபி ஆன் ரெயில்ஸில் எடிட்டர் இடைமுகம் எழுதப்பட்டது. புள்ளிவிவர வழங்குநரிடமிருந்து புள்ளிவிவரங்களை இறக்குமதி செய்வது ரூபியில் எழுதப்பட்டுள்ளது.

கணினி API சோதனைகளுக்கு, நாங்கள் Python unittest ஐப் பயன்படுத்தினோம். Memcached ஆனது API கட்டண அழைப்புகளைத் தடுக்கப் பயன்படுகிறது, "செஃப்" என்பது உள்ளமைவைக் கட்டுப்படுத்தப் பயன்படுகிறது, Zabbix ஆனது உள் அமைப்பு புள்ளிவிவரங்களைச் சேகரித்து கண்காணிக்கப் பயன்படுகிறது. Graylog2 என்பது பதிவுகளை சேகரிப்பதற்காகும், ஸ்லேட் என்பது வாடிக்கையாளர்களுக்கான API ஆவணமாகும்.

நெறிமுறை தேர்வு

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

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

இதன் அடிப்படையில், எங்களிடம் இரண்டு நெறிமுறை விருப்பங்கள் இருந்தன:

1. வெப்சாக்கெட்டுகள். ஆனால் கிளையண்டிலிருந்து சர்வருக்கு சேனல்கள் தேவையில்லை. சேவையகத்திலிருந்து கிளையண்டிற்கு புதுப்பிப்புகளை மட்டுமே அனுப்ப வேண்டும், எனவே வெப்சாக்கெட் என்பது தேவையற்ற விருப்பமாகும்.
2. சர்வர் அனுப்பிய நிகழ்வுகள் (SSE) சரியாக வந்துள்ளன! இது மிகவும் எளிமையானது மற்றும் அடிப்படையில் நமக்கு தேவையான அனைத்தையும் பூர்த்தி செய்கிறது.

சர்வர் அனுப்பிய நிகழ்வுகள்

இது எப்படி வேலை செய்கிறது என்பது பற்றி சில வார்த்தைகள்...

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

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

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

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

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

நேரடி இணைப்பு எவ்வாறு சேவை செய்யப்படுகிறது?

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

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

இதன் விளைவாக, இப்போது எங்கள் பிங் புதுப்பிப்பு வரும் அதே சேனலில் இருந்து வருகிறது.

அதன்படி, 15 வினாடிகளுக்கு ஒரு முறை டிக் செய்யும் ஒரு டைமர் மட்டுமே உள்ளது.

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

புதுப்பிப்புகளை அனுப்புவதற்கான வழிமுறை

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

CMS ஐப் பயன்படுத்தி, தரவு தரவுத்தளத்தில் நுழைகிறது. இதற்குப் பிறகு, Listen/Notify பொறிமுறையைப் பயன்படுத்தி API சேவையகங்களுக்கு தரவுத்தளம் இதைப் பற்றி தெரிவிக்கிறது. API சேவையகங்கள் ஏற்கனவே இந்த தகவலை வாடிக்கையாளர்களுக்கு அனுப்பியுள்ளன. எனவே, எங்களிடம் அடிப்படையில் சில சேவையகங்கள் மட்டுமே தரவுத்தளத்துடன் இணைக்கப்பட்டுள்ளன, மேலும் தரவுத்தளத்தில் சிறப்பு சுமை எதுவும் இல்லை, ஏனெனில் கிளையன்ட் எந்த வகையிலும் தரவுத்தளத்துடன் நேரடியாக தொடர்பு கொள்ளவில்லை:

PostgreSQL: கேளுங்கள்/அறிவிக்கவும்

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

பதிவைச் செருகும்போது அல்லது மாற்றும்போது, ​​டேட்டா_அப்டேட்ஸ் சேனலில் அறிவிப்புச் செயல்பாட்டை அழைக்கிறோம், அதில் மாற்றப்பட்ட அல்லது செருகப்பட்ட பதிவின் டேபிளின் பெயரையும் அடையாளங்காட்டியையும் அனுப்புவோம்.

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

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

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

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

ஃபேன்-அவுட் எப்படி வேலை செய்கிறது?

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

Go இல் இது எவ்வாறு செயல்படுத்தப்படுகிறது:

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

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

சேனலை "கேட்பவர்களுக்கு" சேர்க்கும் சந்தா முறையும் உள்ளது:

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

கேள்வி: - இந்த சேனல் மூலம் என்ன பரவுகிறது?

செல்வி: - மாற்றப்பட்ட மாதிரி அல்லது பிங் அனுப்பப்படுகிறது (அடிப்படையில் ஒரு எண், முழு எண்).

செல்வி: - நீங்கள் எதையும் அனுப்பலாம், எந்த அமைப்பையும் அனுப்பலாம், வெளியிடலாம் - அது JSON ஆக மாறும், அவ்வளவுதான்.

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

உள்கட்டமைப்பு

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

அணுகலை மேம்படுத்துவதற்காக Keepalived உடன் இரண்டு முன் முனைகளை நிறுவியுள்ளோம், இதனால் ஏதாவது நடந்தால், ஒரு முன்பக்கம் மற்றொன்றை மாற்றும். மேலும் - CMS இன் இரண்டு பிரதிகள்.

புள்ளிவிவர இறக்குமதியாளரும் இருக்கிறார். ஒரு DB ஸ்லேவ் உள்ளது, அதில் இருந்து அவ்வப்போது காப்புப்பிரதிகள் செய்யப்படுகின்றன. Pigeon Pusher உள்ளது, இது வாடிக்கையாளர்களுக்கு புஷ் அறிவிப்புகளை அனுப்பும் ஒரு பயன்பாடு மற்றும் உள்கட்டமைப்பு விஷயங்கள்: Zabbix, Graylog2 மற்றும் Chef.

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

கோ நன்மை

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

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

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

உங்கள் கேள்விகள்

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

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

IN: - உடனடியாக ஒரு பதிவை Listen/Notify என்பதற்கு அனுப்பலாம், அடையாளங்காட்டி அட்டவணைக்கு அனுப்ப முடியாது?

செல்வி: - கேட்கவும்/அறிவிக்கவும் அது அனுப்பும் முன் ஏற்றத்தில் 8 ஆயிரம் பைட்டுகள் வரம்பு உள்ளது. கொள்கையளவில், நாங்கள் ஒரு சிறிய அளவிலான தரவைக் கையாள்வதில் இருந்தால் அனுப்ப முடியும், ஆனால் இந்த வழி [நாம் அதைச் செய்யும் முறை] மிகவும் நம்பகமானது என்று எனக்குத் தோன்றுகிறது. வரம்புகள் Postgres இல் உள்ளன.

IN: - வாடிக்கையாளர்கள் ஆர்வமில்லாத போட்டிகள் குறித்த புதுப்பிப்புகளைப் பெறுகிறார்களா?

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

IN: - நீங்கள் ஏன் உங்கள் சொந்த ORM ஐ உருவாக்கினீர்கள்?

அலெக்ஸி (லுக்+ டெவலப்பர்களில் ஒருவர்): – அந்த நேரத்தில் (அது ஒரு வருடத்திற்கு முன்பு) இப்போது இருந்ததை விட குறைவான ORMகள் இருந்தன, அவற்றில் நிறைய உள்ளன. பெரும்பாலான ORM களில் எனக்கு மிகவும் பிடித்த விஷயம் என்னவென்றால், அவற்றில் பெரும்பாலானவை வெற்று இடைமுகங்களில் இயங்குகின்றன. அதாவது, இந்த ORMகளில் உள்ள முறைகள் எதையும் எடுக்கத் தயாராக உள்ளன: ஒரு அமைப்பு, ஒரு கட்டமைப்பு சுட்டிக்காட்டி, ஒரு எண், முற்றிலும் பொருத்தமற்ற ஒன்று...

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

IN: - எத்தனை பேர் பங்கேற்றனர்?

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

IN: – நீங்கள் SSE விவரிக்கும் இடத்தில், நீங்கள் காலக்கெடுவைப் பயன்படுத்த மாட்டீர்கள். அது ஏன்?

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

IN: - நீங்கள் என்ன கூடுதல் பயன்பாடுகளைப் பயன்படுத்தினீர்கள்?

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

IN: - பிழைத்திருத்தத்திற்கு நீங்கள் எதைப் பயன்படுத்தினீர்கள்?

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

IN: - வெளியீட்டு செயல்பாடு செயல்படுத்தப்பட்ட ஸ்லைடைத் திருப்பி அனுப்ப முடியுமா? ஒற்றை எழுத்து மாறி பெயர்கள் உங்களை குழப்புகிறதா?

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

IN: - எப்படியோ அது இன்னும் உள்ளுணர்வு இல்லை ...

செல்வி: - இல்லை, இல்லை, இது ஒரு உண்மையான குறியீடு! இது பாணியைப் பற்றியது அல்ல. இது மிகவும் பயனுள்ள, மிகச் சிறிய வகுப்பு - வகுப்பிற்குள் 3 புலங்கள் மட்டுமே...

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

IN: – ஏதேனும் மூன்றாம் தரப்பு சார்பு மேலாண்மை தொகுப்புகள் உள்ளதா?

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

IN: – அறிக்கையின் தலைப்பில் வீடியோவைப் பற்றி ஏதோ இருந்தது, ஆனால் வீடியோவைப் பற்றிய அறிக்கையில் எதுவும் இல்லை.

செல்வி: - இல்லை, வீடியோவைப் பற்றிய தலைப்பில் என்னிடம் எதுவும் இல்லை. இது "லுக்+" என்று அழைக்கப்படுகிறது - இது பயன்பாட்டின் பெயர்.

IN: - இது வாடிக்கையாளர்களுக்கு ஸ்ட்ரீம் செய்யப்படுகிறது என்று சொன்னீர்களா?..

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

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

சில விளம்பரங்கள் 🙂

எங்களுடன் தங்கியதற்கு நன்றி. எங்கள் கட்டுரைகளை விரும்புகிறீர்களா? மேலும் சுவாரஸ்யமான உள்ளடக்கத்தைப் பார்க்க வேண்டுமா? ஒரு ஆர்டரை வைப்பதன் மூலம் அல்லது நண்பர்களுக்கு பரிந்துரை செய்வதன் மூலம் எங்களை ஆதரிக்கவும், $4.99 இலிருந்து டெவலப்பர்களுக்கான கிளவுட் VPS, நுழைவு-நிலை சேவையகங்களின் தனித்துவமான அனலாக், இது உங்களுக்காக எங்களால் கண்டுபிடிக்கப்பட்டது: VPS (KVM) E5-2697 v3 (6 கோர்கள்) 10GB DDR4 480GB SSD 1Gbps பற்றிய முழு உண்மை $19 அல்லது எப்படி ஒரு சர்வரைப் பகிர்வது? (RAID1 மற்றும் RAID10 உடன் கிடைக்கும், 24 கோர்கள் வரை மற்றும் 40GB DDR4 வரை).

ஆம்ஸ்டர்டாமில் உள்ள Equinix Tier IV தரவு மையத்தில் Dell R730xd 2 மடங்கு மலிவானதா? இங்கே மட்டும் 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 இலிருந்து நெதர்லாந்தில்! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 முதல்! பற்றி படிக்கவும் உள்கட்டமைப்பு நிறுவனத்தை எவ்வாறு உருவாக்குவது. ஒரு பைசாவிற்கு 730 யூரோக்கள் மதிப்புள்ள Dell R5xd E2650-4 v9000 சேவையகங்களைப் பயன்படுத்தும் வகுப்பு?

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