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

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

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

இந்தப் பயன்பாட்டில் வீடியோ ஹைலைட்களும் உள்ளன, இது போட்டிகளின் முக்கிய தருணங்களை (கோல்கள், சண்டைகள், ஷூட்அவுட்கள் போன்றவை) பார்க்க உங்களை அனுமதிக்கிறது. முழு ஒளிபரப்பையும் நீங்கள் பார்க்க விரும்பவில்லை என்றால், ஹைலைட்ஸை மட்டுமே நீங்கள் பார்க்க முடியும்.
வளர்ச்சியில் என்ன பயன்படுத்தப்பட்டது?
முக்கிய பகுதி Go-வில் எழுதப்பட்டது. மொபைல் வாடிக்கையாளர்கள் தொடர்பு கொண்ட API Go-வில் எழுதப்பட்டது. மொபைல் சாதனங்களுக்கு புஷ் அறிவிப்புகளை அனுப்புவதற்கான சேவையும் Go-வில் எழுதப்பட்டது. எங்களுடைய சொந்த ORM-ஐயும் எழுத வேண்டியிருந்தது, அதைப் பற்றி நாம் எப்போதாவது பேசலாம். மேலும் சில சிறிய சேவைகள் Go-வில் எழுதப்பட்டன: எடிட்டர்களுக்கான அளவை மாற்றுதல் மற்றும் பட பதிவேற்றம்...
எங்கள் தரவுத்தளமாக PostgreSQL ஐப் பயன்படுத்தினோம். எடிட்டர் இடைமுகம் ActiveAdmin ஜெம்மைப் பயன்படுத்தி ரூபி ஆன் ரெயில்ஸில் எழுதப்பட்டது. புள்ளிவிவர வழங்குநரிடமிருந்து புள்ளிவிவர இறக்குமதியாளரும் ரூபியில் எழுதப்பட்டது.
கணினி API சோதனைகளுக்கு, நாங்கள் பைத்தானின் யூனிட் டெஸ்டைப் பயன்படுத்தினோம். Memcached என்பது API கட்டண கோரிக்கைகளைத் தடுக்கப் பயன்படுகிறது, Chef என்பது உள்ளமைவுக் கட்டுப்பாட்டிற்குப் பயன்படுத்தப்படுகிறது, Zabbix என்பது உள் கணினி புள்ளிவிவரங்களைச் சேகரித்து கண்காணிக்கப் பயன்படுகிறது, Graylog2 என்பது பதிவு சேகரிப்புக்குப் பயன்படுத்தப்படுகிறது, மேலும் Slate என்பது வாடிக்கையாளர்களுக்கான API ஆவணமாகும்.

நெறிமுறை தேர்வு
நாங்கள் எதிர்கொண்ட முதல் சிக்கல், பின்வரும் புள்ளிகளின் அடிப்படையில், மொபைல் கிளையண்டுகளுடனான பின்தள தொடர்புக்கான நெறிமுறையைத் தேர்ந்தெடுப்பதாகும்...
- மிக முக்கியமான தேவை என்னவென்றால், வாடிக்கையாளர் தரவு நிகழ்நேரத்தில் புதுப்பிக்கப்பட வேண்டும். இதன் பொருள் ஒளிபரப்பைப் பார்க்கும் அனைவரும் கிட்டத்தட்ட உடனடியாக புதுப்பிப்புகளைப் பெற வேண்டும்.
- எளிமைக்காக, கிளையன்ட்களுடன் ஒத்திசைக்கப்பட்ட தரவு நீக்கப்படாது, ஆனால் சிறப்புக் கொடிகளைப் பயன்படுத்தி மறைக்கப்படும் என்று நாங்கள் கருதுகிறோம்.
- அனைத்து அரிய கோரிக்கைகளும் (புள்ளிவிவரங்கள், குழுப் பட்டியல்கள், குழுப் புள்ளிவிவரங்கள் போன்றவை) வழக்கமான GET கோரிக்கைகள் மூலம் பெறப்படுகின்றன.
- கூடுதலாக, இந்த அமைப்பு ஒரே நேரத்தில் 100 பயனர்களை எளிதாகக் கையாள வேண்டியிருந்தது.
இதன் அடிப்படையில், எங்களுக்கு இரண்டு நெறிமுறை விருப்பங்கள் இருந்தன:
- வெப்சாக்கெட்டுகள். ஆனால் கிளையண்டிலிருந்து சர்வருக்கு சேனல்கள் எங்களுக்குத் தேவையில்லை. சர்வரிலிருந்து கிளையண்டிற்கு புதுப்பிப்புகளை மட்டுமே அனுப்ப வேண்டியிருந்தது, எனவே வெப்சாக்கெட் மிகையானது.
- சர்வர்-சென்ட் ஈவென்ட்ஸ் (SSE) சரியாகப் பொருந்தியது! இது மிகவும் எளிமையானது மற்றும் அடிப்படையில் நமக்குத் தேவையான அனைத்தையும் பூர்த்தி செய்கிறது.
சர்வர் அனுப்பிய நிகழ்வுகள்
இது எப்படி வேலை செய்கிறது என்பது பற்றி சில வார்த்தைகள்...
இது ஒரு HTTP இணைப்பின் மூலம் செயல்படுகிறது. கிளையன்ட் ஒரு கோரிக்கையை அனுப்புகிறது, சேவையகம் Content-Type: text/event-stream உடன் பதிலளிக்கிறது மற்றும் கிளையண்டுடனான இணைப்பை மூடாது, ஆனால் இணைப்பிற்கு தரவை எழுதுவதைத் தொடர்கிறது:

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

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

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

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

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

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

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

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

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

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

அணுகலுக்காக Keepalived ஐ இயக்கும் இரண்டு முன்பக்கங்கள் எங்களிடம் உள்ளன, எனவே தேவைப்பட்டால் ஒரு முன்பக்கத்தை மற்றொன்றை மாற்றலாம். எங்களிடம் CMS இன் இரண்டு பிரதிகள் உள்ளன.
புள்ளிவிவர இறக்குமதியாளரும் இருக்கிறார். அவ்வப்போது தரவை காப்புப் பிரதி எடுக்கும் DB ஸ்லேவ் உள்ளது. வாடிக்கையாளர்களுக்கு புஷ் அறிவிப்புகளை அனுப்பும் பயன்பாடான Pigeon Pusher, Zabbix, Graylog2 மற்றும் Chef ஆகிய உள்கட்டமைப்பு கூறுகளும் உள்ளன.
உண்மையில், இந்த உள்கட்டமைப்பு தேவையற்றது, ஏனென்றால் 100 பயனர்களுக்கு குறைவான சேவையகங்களுடன் சேவை செய்ய முடியும். ஆனால் எங்களிடம் வன்பொருள் இருந்தது - நாங்கள் அதைப் பயன்படுத்தினோம் (அது சாத்தியம் என்று எங்களுக்குச் சொல்லப்பட்டது - ஏன் கூடாது).
கோவின் நன்மைகள்
இந்த பயன்பாட்டில் பணிபுரிந்த பிறகு, Go இன் பின்வரும் வெளிப்படையான நன்மைகள் தெளிவாகத் தெரிந்தன.
- ஒரு சிறந்த HTTP நூலகம். இது பெட்டியிலிருந்து வெளியே நிறைய உருவாக்க உங்களை அனுமதிக்கிறது.
- கூடுதலாக, வாடிக்கையாளர்களுக்கு அறிவிப்புகளை அனுப்புவதற்கான ஒரு பொறிமுறையை மிக எளிதாக செயல்படுத்த சேனல்கள் எங்களுக்கு அனுமதித்தன.
- ரேஸ் டிடெக்டர் என்பது பல முக்கியமான பிழைகளை (ஸ்டேஜிங் உள்கட்டமைப்பு) நீக்க எங்களுக்கு அனுமதித்த ஒரு அற்புதமான அம்சமாகும். ஸ்டேஜிங்கில் இயங்கும் அனைத்தும் ரேஸ் விசையுடன் இயங்கி தொகுக்கப்படுகின்றன; எனவே, நமக்கு என்ன சாத்தியமான சிக்கல்கள் இருக்கலாம் என்பதைக் காண ஸ்டேஜிங் உள்கட்டமைப்பைப் பயன்படுத்தலாம்.
- மொழியின் மினிமலிசம் மற்றும் எளிமை.

நாங்கள் டெவலப்பர்களைத் தேடுகிறோம்! யாராவது ஆர்வமாக இருந்தால், தயவுசெய்து எங்களுடன் சேருங்கள்.
உங்கள் கேள்விகள்
பார்வையாளர் கேள்வி (இனிமேல் "பார்வையாளர் கேள்வி" என்று குறிப்பிடப்படுகிறது): ரசிகர்-வெளியேற்றம் தொடர்பான ஒரு முக்கியமான விஷயத்தை நீங்கள் தவறவிட்டீர்கள் என்று நினைக்கிறேன். நீங்கள் ஒரு வாடிக்கையாளருக்கு ஒரு பதிலை அனுப்பும்போது, அவர்கள் அதைப் படிக்க விரும்பவில்லை என்றால் அவர்களைத் தடுக்கிறீர்கள் என்று நான் சரியாகப் புரிந்துகொள்கிறேனா?
செல்வி: "இல்லை, நாங்கள் தடுக்கப்படவில்லை. முதலாவதாக, Nginx-க்குப் பின்னால் எல்லாம் இருக்கிறது, எனவே மெதுவான கிளையண்டுகளுடன் எந்தப் பிரச்சினையும் இல்லை. இரண்டாவதாக, கிளையண்டிற்கு ஒரு இடையகத்துடன் ஒரு சேனல் உள்ளது - நாம் அடிப்படையில் நூறு புதுப்பிப்புகளை அங்கே சேமிக்க முடியும்... சேனலுக்கு எழுத முடியாவிட்டால், அது அதை நீக்குகிறது. சேனல் தடுக்கப்பட்டிருப்பதைக் கண்டால், சேனலை மூடுவோம், அவ்வளவுதான் - ஏதேனும் சிக்கல்கள் ஏற்பட்டால் கிளையன்ட் மீண்டும் இணைப்பார். எனவே, கொள்கையளவில், இங்கே எந்தத் தடையும் இல்லை."
IN: – அடையாளங்காட்டி அட்டவணைக்குப் பதிலாக, உடனடியாக Listen/Notifyக்கு ஒரு பதிவை அனுப்ப முடியவில்லையா?
செல்வி: – Listen/Notify அனுப்பும் ஒரு முன் ஏற்றத்திற்கு 8 பைட்டுகள் வரம்பைக் கொண்டுள்ளது. கொள்கையளவில், நாம் ஒரு சிறிய அளவிலான தரவைக் கையாளும் போது அதை அனுப்ப முடியும், ஆனால் இந்த வழியில் இது மிகவும் நம்பகமானது என்று நான் நினைக்கிறேன். வரம்புகள் PostgreSQL இல் உள்ளன.
IN: – வாடிக்கையாளர்கள் தாங்கள் ஆர்வமில்லாத போட்டிகள் குறித்த புதுப்பிப்புகளைப் பெறுகிறார்களா?
செல்வி: – பொதுவாக, ஆம். பொதுவாக, இரண்டு அல்லது மூன்று பொருத்தங்கள் ஒரே நேரத்தில் இயங்கும், அதுவும் கூட, அது மிகவும் அரிதானது. ஒரு கிளையன்ட் எதையாவது பார்த்துக் கொண்டிருந்தால், அவர்கள் வழக்கமாக தற்போது விளையாடும் போட்டியைப் பார்த்துக் கொண்டிருப்பார்கள். பின்னர், கிளையண்டிடம் இந்த புதுப்பிப்புகள் அனைத்தும் சேமிக்கப்படும் ஒரு உள்ளூர் தரவுத்தளம் உள்ளது, மேலும் இணைய இணைப்பு இல்லாவிட்டாலும், கிளையன்ட் அவர்கள் புதுப்பிப்புகளைக் கொண்ட அனைத்து கடந்த பொருத்தங்களையும் பார்க்கலாம். அடிப்படையில், சேவையகத்தில் உள்ள எங்கள் தரவுத்தளத்தை கிளையண்டின் உள்ளூர் தரவுத்தளத்துடன் ஒத்திசைக்கிறோம், எனவே அது ஆஃப்லைனில் வேலை செய்ய முடியும்.
IN: – நீங்கள் ஏன் உங்கள் சொந்த ORM ஐ உருவாக்கினீர்கள்?
அலெக்ஸி ("ஸ்மோட்ரி+" இன் டெவலப்பர்களில் ஒருவர்): – அந்த நேரத்தில் (இது ஒரு வருடம் முன்பு), இப்போது இருப்பதை விட குறைவான ORMகள் இருந்தன, அப்போது அவை நிறைய இருந்தன. தற்போதுள்ள அனைத்து ORMகளிலும், எனக்கு மிகவும் பிடிக்காதது என்னவென்றால், அவற்றில் பெரும்பாலானவை வெற்று இடைமுகங்களில் இயங்குகின்றன. அதாவது, இந்த ORMகளில் உள்ள முறைகள் எதையும் ஏற்றுக்கொள்ளத் தயாராக உள்ளன: ஒரு கட்டமைப்பு, ஒரு கட்டமைப்பிற்கான சுட்டிக்காட்டி, ஒரு எண், முற்றிலும் பொருத்தமற்ற எதையும்...
எங்கள் ORM தரவு மாதிரியை அடிப்படையாகக் கொண்டு கட்டமைப்புகளை உருவாக்குகிறது. எனவே, அனைத்து முறைகளும் உறுதியானவை, பிரதிபலிப்பைப் பயன்படுத்த வேண்டாம், முதலியன. அவை கட்டமைப்புகளை ஏற்றுக்கொண்டு வழங்கப்பட்ட கட்டமைப்புகளைப் பயன்படுத்த எதிர்பார்க்கின்றன.
IN: - எத்தனை பேர் பங்கேற்றனர்?
செல்வி: – ஆரம்ப கட்டத்தில் இரண்டு பேர் ஈடுபட்டிருந்தனர். நாங்கள் ஜூன் மாதத்தில் தொடங்கினோம், முக்கிய பகுதி (முதல் பதிப்பு) ஆகஸ்ட் மாதத்திற்குள் தயாராக இருந்தது. வெளியீடு செப்டம்பரில் இருந்தது.
IN: – நீங்கள் SSE-ஐ விவரிக்கும் இடத்தில், நீங்கள் காலக்கெடுவைப் பயன்படுத்துவதில்லை. அது ஏன்?
செல்வி: "உண்மையைச் சொல்வதானால், SSE இன்னும் ஒரு HTML5 நெறிமுறைதான்: எனக்குத் தெரிந்தவரை, SSE தரநிலை உலாவிகளுடன் தொடர்புகொள்வதற்காக வடிவமைக்கப்பட்டுள்ளது. உலாவிகளை மீண்டும் இணைக்க அனுமதிக்கும் கூடுதல் அம்சங்கள் இதில் உள்ளன (மற்றும் பல), ஆனால் எந்தவொரு இணைப்பையும் தகவல் மீட்டெடுப்பு தர்க்கத்தையும் செயல்படுத்தக்கூடிய கிளையண்டுகள் எங்களிடம் இருந்ததால் அவை எங்களுக்குத் தேவையில்லை. நாங்கள் SSE ஐ உருவாக்கவில்லை, மாறாக SSE போன்ற ஒன்றை உருவாக்கினோம். இது நெறிமுறை அல்ல."
எந்த அவசியமும் இல்லை. எனக்குத் தெரிந்தவரை, வாடிக்கையாளர்கள் இணைப்பு பொறிமுறையை புதிதாக செயல்படுத்தினர். அவர்கள் அடிப்படையில் அதைப் பொருட்படுத்தவில்லை.
IN: - நீங்கள் என்ன கூடுதல் பயன்பாடுகளைப் பயன்படுத்தினீர்கள்?
செல்வி: – நிலையான பாணியைப் பராமரிக்க நாங்கள் கோவெட் மற்றும் கோலிண்ட்டை மிக விரிவாகப் பயன்படுத்தினோம், அதே போல் gofmt-ஐயும் பயன்படுத்தினோம். வேறு எதையும் நாங்கள் பயன்படுத்தவில்லை.
IN: – அதை பிழைத்திருத்தம் செய்ய நீங்கள் எதைப் பயன்படுத்தினீர்கள்?
செல்வி: – பிழைத்திருத்தம் பெரும்பாலும் சோதனைகள் மூலம் செய்யப்பட்டது. நாங்கள் எந்த பிழைத்திருத்திகளையோ அல்லது GOPயையோ பயன்படுத்தவில்லை.
IN: – பப்ளிஷ் செயல்பாடு செயல்படுத்தப்படும் ஸ்லைடைத் திருப்பி அனுப்ப முடியுமா? ஒற்றை எழுத்து மாறி பெயர்கள் குழப்பமாக உள்ளதா?
செல்வி: "இல்லை. அவை மிகவும் குறுகிய நோக்கத்தைக் கொண்டுள்ளன. இங்கே தவிர வேறு எங்கும் அவை பயன்படுத்தப்படவில்லை (இந்த வகுப்பின் உள் பகுதிகளுக்குள் தவிர), மேலும் இது மிகவும் கச்சிதமானது - இது 7 வரிகளை மட்டுமே எடுக்கும்."
IN: – எப்படியோ அது இன்னும் உள்ளுணர்வாக உணரவில்லை…
செல்வி: "இல்லை, இல்லை, இது உண்மையான குறியீடு! இது பாணியைப் பற்றிய விஷயம் அல்ல. இது மிகவும் பயனுள்ள, மிகச் சிறிய வகுப்பு - வகுப்பினுள் மூன்று புலங்கள் மட்டுமே..."

செல்வி: – பொதுவாக, வாடிக்கையாளர்களுடன் ஒத்திசைக்கப்பட்ட அனைத்து தரவுகளும் (பருவகால போட்டிகள், வீரர்கள்) மாறாமல் உள்ளன. தோராயமாகச் சொன்னால், போட்டி மாற்றங்கள் தேவைப்படும் மற்றொரு விளையாட்டை நாங்கள் உருவாக்கினால், புதிய வாடிக்கையாளர் பதிப்பில் எல்லாவற்றையும் கணக்கில் எடுத்துக்கொள்வோம், மேலும் பழைய பதிப்புகள் தடை செய்யப்படும்.
IN: – சார்பு மேலாண்மைக்கு ஏதேனும் மூன்றாம் தரப்பு தொகுப்புகள் உள்ளதா?
செல்வி: – நாங்கள் கோ டெப்பைப் பயன்படுத்தினோம்.
IN: – அறிக்கையின் தலைப்பில் வீடியோ பற்றி ஏதோ குறிப்பிடப்பட்டுள்ளது, ஆனால் அறிக்கையில் வீடியோ பற்றி எதுவும் குறிப்பிடப்படவில்லை.
செல்வி: "இல்லை, என்னுடைய திரியில் வீடியோக்கள் பற்றி எதுவும் இல்லை. அது "வாட்ச்+" என்று அழைக்கப்படுகிறது - அதுதான் செயலியின் பெயர்."
IN: - நீங்க வாடிக்கையாளர்களுக்கு ஸ்ட்ரீம் பண்றதா சொன்னீங்களா?..
செல்வி: "நாங்கள் வீடியோ ஸ்ட்ரீமிங்கில் ஈடுபடவில்லை. அது முழுக்க முழுக்க மெகாஃபோனால் கையாளப்பட்டது. ஆம், அந்த செயலி மெகாஃபோனுடையது என்று நான் சொல்லவில்லை."
செல்வி: – Go – அனைத்து தரவையும் அனுப்புவதற்கு – மதிப்பெண்கள், போட்டி நிகழ்வுகள், புள்ளிவிவரங்கள்… Go என்பது பயன்பாட்டின் முழு பின்னணியாகும். பயனர் போட்டியைப் பார்க்க, பிளேயருக்கு எந்த இணைப்பைப் பயன்படுத்த வேண்டும் என்பதை கிளையன்ட் எங்கிருந்தோ தெரிந்து கொள்ள வேண்டும். ஏற்கனவே தயாரிக்கப்பட்ட வீடியோக்கள் மற்றும் ஸ்ட்ரீம்களுக்கான இணைப்புகள் எங்களிடம் உள்ளன.

சில விளம்பரங்கள் 🙂
எங்களுடன் தங்கியதற்கு நன்றி. எங்கள் கட்டுரைகளை விரும்புகிறீர்களா? மேலும் சுவாரஸ்யமான உள்ளடக்கத்தைப் பார்க்க வேண்டுமா? ஒரு ஆர்டரை வைப்பதன் மூலம் அல்லது நண்பர்களுக்கு பரிந்துரை செய்வதன் மூலம் எங்களை ஆதரிக்கவும், , நுழைவு-நிலை சேவையகங்களின் தனித்துவமான அனலாக், இது உங்களுக்காக எங்களால் கண்டுபிடிக்கப்பட்டது: (RAID1 மற்றும் RAID10 உடன் கிடைக்கும், 24 கோர்கள் வரை மற்றும் 40GB DDR4 வரை).
ஆம்ஸ்டர்டாமில் உள்ள Equinix Tier IV தரவு மையத்தில் Dell R730xd 2 மடங்கு மலிவானதா? இங்கே மட்டும் நெதர்லாந்தில்! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 முதல்! பற்றி படிக்கவும்
ஆதாரம்: www.habr.com
