🥇 கட்டிடக்கலை மற்றும் VKontakte இல் வேலை பற்றிய கேள்விகள்

VKontakte ஐ உருவாக்கிய வரலாறு விக்கிபீடியாவில் உள்ளது; இது பாவெல் அவர்களால் சொல்லப்பட்டது. எல்லோருக்கும் அவளை ஏற்கனவே தெரியும் என்று தெரிகிறது. HighLoad++ Pavel இல் உள்ள தளத்தின் உட்புறங்கள், கட்டிடக்கலை மற்றும் அமைப்பு பற்றி 2010 இல் என்னிடம் கூறினார். அதன்பிறகு பல சேவையகங்கள் கசிந்துள்ளன, எனவே நாங்கள் தகவலைப் புதுப்பிப்போம்: நாங்கள் அதை பிரித்து, உட்புறங்களை வெளியே எடுத்து, எடைபோட்டு, தொழில்நுட்பக் கண்ணோட்டத்தில் VK சாதனத்தைப் பார்ப்போம்.

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

நான்கு ஆண்டுகளுக்கும் மேலாக நான் பின்தளம் தொடர்பான அனைத்து வகையான பணிகளையும் கையாண்டு வருகிறேன்.

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

இந்த நேரத்தில், தளத்தின் பல கூறுகளில் எனக்கு ஒரு கை இருந்தது. இந்த அனுபவத்தைப் பகிர்ந்து கொள்ள விரும்புகிறேன்.

பொது கட்டிடக்கலை

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

முன் சேவையகம்

முன் சேவையகம் HTTPS, RTMP மற்றும் WSS வழியாக கோரிக்கைகளை ஏற்றுக்கொள்கிறது.

HTTPS ஆதரவு - இவை தளத்தின் முக்கிய மற்றும் மொபைல் வலை பதிப்புகளுக்கான கோரிக்கைகள்: vk.com மற்றும் m.vk.com மற்றும் எங்கள் API இன் பிற அதிகாரப்பூர்வ மற்றும் அதிகாரப்பூர்வமற்ற கிளையண்டுகள்: மொபைல் கிளையண்டுகள், தூதர்கள். எங்களுக்கு வரவேற்பு உள்ளது RTMP-தனியான முன் சேவையகங்களுடன் நேரடி ஒளிபரப்பிற்கான போக்குவரத்து மற்றும் WSS- ஸ்ட்ரீமிங் APIக்கான இணைப்புகள்.

சேவையகங்களில் HTTPS மற்றும் WSS க்கு இது மதிப்புள்ளது Nginx. RTMP ஒளிபரப்புகளுக்கு, நாங்கள் சமீபத்தில் எங்கள் சொந்த தீர்வுக்கு மாறினோம் கிவ், ஆனால் அது அறிக்கையின் எல்லைக்கு அப்பாற்பட்டது. தவறு சகிப்புத்தன்மைக்கு, இந்த சேவையகங்கள் பொதுவான ஐபி முகவரிகளை விளம்பரப்படுத்துகின்றன மற்றும் குழுக்களாக செயல்படுகின்றன, இதனால் சேவையகங்களில் ஏதேனும் சிக்கல் இருந்தால், பயனர் கோரிக்கைகள் இழக்கப்படாது. HTTPS மற்றும் WSS க்கு, இதே சேவையகங்கள் CPU சுமையின் ஒரு பகுதியை தாங்களாகவே எடுத்துக்கொள்வதற்காக போக்குவரத்தை குறியாக்கம் செய்கின்றன.

நாங்கள் WSS மற்றும் RTMP பற்றி மேலும் பேச மாட்டோம், ஆனால் நிலையான HTTPS கோரிக்கைகளைப் பற்றி மட்டுமே பேசுவோம், அவை பொதுவாக வலைத் திட்டத்துடன் தொடர்புடையவை.

பின்தளத்தில்

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

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

சுமை விநியோகம்

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

மெட்ரிக் சேகரிப்பு மற்றும் மறுசீரமைப்பு

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

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

உள்ளடக்க சேவையகம்

CS அல்லது Content Server என்பது ஒரு சேமிப்பகம். CS என்பது கோப்புகளைச் சேமிக்கும் மற்றும் பதிவேற்றப்பட்ட கோப்புகள் மற்றும் அனைத்து வகையான பின்னணி ஒத்திசைவு பணிகளைச் செயல்படுத்தும் ஒரு சேவையகம் ஆகும்.

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

pu/pp

நீங்கள் VK இல் நெட்வொர்க் தாவலைத் திறந்தால், நீங்கள் pu/pp ஐப் பார்த்தீர்கள்.

பு/பிபி என்றால் என்ன? நாம் ஒரு சேவையகத்தை ஒன்றன் பின் ஒன்றாக மூடினால், மூடப்பட்ட சர்வரில் கோப்பைப் பதிவேற்றுவதற்கும் பதிவிறக்குவதற்கும் இரண்டு விருப்பங்கள் உள்ளன: நேரடியாக மூலம் http://cs100500.userapi.com/path அல்லது இடைநிலை சேவையகம் வழியாக - http://pu.vk.com/c100500/path.

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

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

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

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

இந்த விஷயத்தில் சர்ச்சைக்குரிய விஷயம் வாடிக்கையாளர் குறைவான இணைப்புகளை வைத்திருக்கிறார். பல இயந்திரங்களுக்கு ஒரே ஐபி இருந்தால் - ஒரே ஹோஸ்டுடன்: pu.vk.com அல்லது pp.vk.com, கிளையன்ட் உலாவி ஒரு ஹோஸ்டுக்கு ஒரே நேரத்தில் கோரிக்கைகளின் எண்ணிக்கையில் வரம்பைக் கொண்டுள்ளது. ஆனால் எங்கும் நிறைந்த HTTP/2 காலத்தில், இது இனி அவ்வளவு பொருத்தமாக இருக்காது என்று நான் நம்புகிறேன்.

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

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

சூரியன்

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

pp க்கு சில சிக்கல்கள் இருந்தன. ஒரு குழுவிற்கு ஒரு ஐபி - பயனற்ற கேச். பல இயற்பியல் சேவையகங்கள் பொதுவான ஐபி முகவரியைப் பகிர்ந்து கொள்கின்றன, மேலும் கோரிக்கை எந்த சேவையகத்திற்குச் செல்லும் என்பதைக் கட்டுப்படுத்த வழி இல்லை. எனவே, ஒரே கோப்பிற்கு வெவ்வேறு பயனர்கள் வந்தால், இந்த சேவையகங்களில் தற்காலிக சேமிப்பு இருந்தால், கோப்பு ஒவ்வொரு சேவையகத்தின் தற்காலிக சேமிப்பிலும் முடிவடைகிறது. இது மிகவும் திறமையற்ற திட்டம், ஆனால் எதுவும் செய்ய முடியவில்லை.

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

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

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

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

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

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

உள்ளே இருந்து சூரியன்

nginx இல் ரிவர்ஸ் ப்ராக்ஸி, RAM இல் அல்லது வேகமான Optane/NVMe வட்டுகளில் கேச். உதாரணமாக: http://sun4-2.userapi.com/c100500/path - நான்காவது பிராந்தியமான இரண்டாவது சேவையகக் குழுவில் அமைந்துள்ள "சூரியனுக்கான" இணைப்பு. இது 100500 சர்வரில் இருக்கும் பாதை கோப்பை மூடுகிறது.

கவர்

எங்கள் கட்டடக்கலை திட்டத்தில் மேலும் ஒரு முனையைச் சேர்க்கிறோம் - கேச்சிங் சூழல்.

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

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

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

இது எப்படி வேலை செய்கிறது?

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

அதே நேரத்தில், பேய்கள் - பிராந்தியங்களில் உள்ள சேவைகள் - அவ்வப்போது API க்கு வந்து கூறுகின்றன: “நான் அப்படிப்பட்ட ஒரு தற்காலிக சேமிப்பு, இன்னும் என்னிடம் இல்லாத எனது பிராந்தியத்தில் மிகவும் பிரபலமான கோப்புகளின் பட்டியலை எனக்குக் கொடுங்கள். ” API மதிப்பீட்டின்படி வரிசைப்படுத்தப்பட்ட கோப்புகளின் தொகுப்பை வழங்குகிறது, டீமான் அவற்றைப் பதிவிறக்குகிறது, அவற்றை பிராந்தியங்களுக்கு எடுத்துச் சென்று அங்கிருந்து கோப்புகளை வழங்குகிறது. கேச்களில் இருந்து pu/pp மற்றும் Sun ஆகியவற்றுக்கு இடையே உள்ள அடிப்படை வேறுபாடு இதுதான்: இந்த கோப்பு தற்காலிக சேமிப்பில் இல்லாவிட்டாலும், அவை உடனடியாக கோப்பைத் தாங்களாகவே தருகின்றன, மேலும் கேச் முதலில் கோப்பைத் தானே பதிவிறக்கம் செய்து, பின்னர் அதைத் திரும்பக் கொடுக்கத் தொடங்குகிறது.

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

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

பொதுவான கட்டிடக்கலையைப் பார்த்தோம்.

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

இந்த வரைபடத்தில் என்ன இல்லை? நிச்சயமாக, நாம் தரவைச் சேமிக்கும் தரவுத்தளங்கள்.

தரவுத்தளங்கள் அல்லது இயந்திரங்கள்

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

இது தேவையான நடவடிக்கை. இது நடந்தது, ஏனெனில் 2008-2009 இல், VK பிரபலத்தில் வெடிக்கும் வளர்ச்சியைப் பெற்றபோது, திட்டம் முழுமையாக MySQL மற்றும் Memcache இல் வேலை செய்தது மற்றும் சிக்கல்கள் இருந்தன. MySQL செயலிழக்க மற்றும் சிதைந்த கோப்புகளை விரும்புகிறது, அதன் பிறகு அது மீட்கப்படாது, மேலும் Memcache படிப்படியாக செயல்திறன் குறைந்து, மறுதொடக்கம் செய்யப்பட வேண்டியிருந்தது.

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

தீர்வு வெற்றிகரமாக இருந்தது. இதை செய்ய ஒரு வாய்ப்பு இருந்தது, அதே போல் ஒரு தீவிர தேவையும் இருந்தது, ஏனென்றால் அந்த நேரத்தில் அளவிடுவதற்கான மற்ற வழிகள் இல்லை. தரவுத்தளங்கள் எதுவும் இல்லை, NoSQL இன்னும் இல்லை, MySQL, Memcache, PostrgreSQL மட்டுமே இருந்தன - அவ்வளவுதான்.

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

இயந்திரங்களின் வகைகள்

குழு சில இயந்திரங்களை எழுதியது. அவற்றில் சில இதோ: நண்பர், குறிப்புகள், படம், ipdb, கடிதங்கள், பட்டியல்கள், பதிவுகள், memcached, meowdb, news, nostradamus, புகைப்படம், பிளேலிஸ்ட்கள், pmemcached, சாண்ட்பாக்ஸ், தேடல், சேமிப்பு, விருப்பங்கள், பணிகள், …

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

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

கொத்துகள்

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

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

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

RPC ப்ராக்ஸி

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

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

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

குறிப்பிட்ட செயலாக்கங்கள்

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

இன்னும் அங்கொன்றும் இங்கொன்றுமாக இருக்கும் MySQL க்கு, நாங்கள் db-proxy ஐப் பயன்படுத்துகிறோம், மேலும் ClickHouse க்கு - கிட்டன்ஹவுஸ்.

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

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

அனைத்து இயந்திரங்களும் செயல்படும் TL-திட்டத்தின் எடுத்துக்காட்டு.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

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

TCP/UDP... UDPக்கு மேல் RPC?

TL திட்டத்தின் மேல் இயங்கும் என்ஜின் கோரிக்கைகளை செயல்படுத்துவதற்கான RPC நெறிமுறை எங்களிடம் உள்ளது. இவை அனைத்தும் TCP/UDP இணைப்பில் வேலை செய்யும். TCP புரிகிறது, ஆனால் UDP ஏன் அடிக்கடி தேவைப்படுகிறது?

UDP உதவுகிறது சேவையகங்களுக்கு இடையில் அதிக எண்ணிக்கையிலான இணைப்புகளின் சிக்கலைத் தவிர்க்கவும். ஒவ்வொரு சர்வரிலும் RPC ப்ராக்ஸி இருந்தால், பொதுவாக, அது எந்த எஞ்சினுக்கும் செல்ல முடியும் என்றால், ஒரு சர்வருக்கு பல்லாயிரக்கணக்கான TCP இணைப்புகள் இருக்கும். ஒரு சுமை உள்ளது, ஆனால் அது பயனற்றது. UDP விஷயத்தில் இந்தப் பிரச்சனை இல்லை.

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

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

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

நிலையான தரவு சேமிப்பு

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

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

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

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

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

ஸ்னாப்ஷாட் உருவாக்கப்பட்ட நேரத்தில் இருந்த நிலையையும் பின்லாக்கின் அளவையும் படிக்கும்.

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

தரவு நகல்

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

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

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

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

RPC ப்ராக்ஸியில் தரவு பகிர்வு

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

எளிமையான திட்டம் ஃபர்ஸ்ட் இன்ட் - கோரிக்கையில் முதல் எண்.

get(photo100_500) => 100 % N.

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

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

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

hash(photo100_500) => 3539886280 % N

ஹாஷ், பிரிவின் மீதி மற்றும் ஷார்ட் எண் ஆகியவற்றையும் பெறுகிறோம்.

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

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

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

பதிவுகள்

நாம் பல வழிகளில் பதிவுகளை எழுதுகிறோம். மிகவும் வெளிப்படையான மற்றும் எளிமையான ஒன்று பதிவுகளை memcache இல் எழுதவும்.

ring-buffer: prefix.idx = line

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

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

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

இயந்திரம் மிகவும் பழையது, ஏற்கனவே 6-7 ஆண்டுகள் பழமையான கொத்துகள் உள்ளன. நாங்கள் தீர்க்க முயற்சிக்கும் சிக்கல்கள் உள்ளன, எடுத்துக்காட்டாக, பதிவுகளை சேமிக்க கிளிக்ஹவுஸை தீவிரமாகப் பயன்படுத்தத் தொடங்கினோம்.

ClickHouse இல் பதிவுகளை சேகரிக்கிறது

இந்த வரைபடம் நாம் எஞ்சின்களில் எவ்வாறு செல்கிறோம் என்பதைக் காட்டுகிறது.

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

கிளிக்ஹவுஸுடன் சில இயந்திரங்களை மாற்றவும்;
ClickHouse ஐ அணுக முடியாத RPC ப்ராக்ஸியை, RPC வழியாக சில தீர்வுகளுடன் மாற்றவும்.

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

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

சில நேரங்களில் நாங்கள் RPC திட்டத்தை தரமற்ற தீர்வுகளில் செயல்படுத்த விரும்பவில்லை, எடுத்துக்காட்டாக, nginx இல். எனவே, KittenHouse UDP வழியாக பதிவுகளைப் பெறும் திறனைக் கொண்டுள்ளது.

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

கண்காணிப்பு

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

கணினி அளவீடுகள்

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

தயாரிப்பு அளவீடுகள்

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

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

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

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

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

தேவைப்பட்டால், பதிவுகள் சேகரிப்பாளர்களுக்கு நேரடியாக எழுதலாம்.

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

அடுத்து, பதிவுகள் சேகரிப்பாளர்கள் புள்ளிவிவரங்களை ஒன்றிணைக்கிறார்கள் meowDB - இது எங்கள் தரவுத்தளமாகும், இது அளவீடுகளையும் சேமிக்க முடியும்.

பின்னர் குறியீட்டிலிருந்து பைனரி “SQLக்கு அருகில்” தேர்வுகளை செய்யலாம்.

சோதனை

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

கிட்டன்ஹவுஸ் மூலம் பதிவுகளை எழுதும் திட்டம் எங்களிடம் இருந்தது.

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

memcache, stats-demon மற்றும் logs-collectors தரவுத்தளத்துடன் கூடிய திட்டம் இதனுடன் மாற்றப்பட்டது.

இங்கே குறியீட்டிலிருந்து ஒரு அனுப்புதல் உள்ளது, இது StatsHouse இல் உள்நாட்டில் எழுதப்பட்டுள்ளது.
StatsHouse UDP அளவீடுகளை எழுதுகிறது, ஏற்கனவே SQL இன்செர்ட்டுகளாக மாற்றப்பட்டு, தொகுப்பாக KittenHouse ஆக மாற்றப்பட்டுள்ளது.
KittenHouse அவர்களை ClickHouse க்கு அனுப்புகிறது.
நாம் அவற்றைப் படிக்க விரும்பினால், StatsHouse ஐத் தவிர்த்து - வழக்கமான SQL ஐப் பயன்படுத்தி ClickHouse இலிருந்து நேரடியாகப் படிக்கிறோம்.

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

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

வரிசைப்படுத்த

முதலில், PHP வரிசைப்படுத்தலைப் பார்ப்போம். நாங்கள் உருவாகி வருகிறோம் Git: பயன்படுத்த GitLab и TeamCity வரிசைப்படுத்தலுக்கு. வளர்ச்சிக் கிளைகள் முதன்மைக் கிளையில் இணைக்கப்படுகின்றன, சோதனைக்கான மாஸ்டரில் இருந்து அவை நிலைப்படுத்தல் மற்றும் உற்பத்தியில் இருந்து இணைக்கப்படுகின்றன.

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

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

அடிப்படையில் பைனரிகளாக இருக்கும் எங்கள் என்ஜின்களுக்கு, திட்டம் மிகவும் ஒத்திருக்கிறது:

git மாஸ்டர் கிளை;
பைனரி இன் .deb;
பதிப்பு binlog copyfastக்கு எழுதப்பட்டுள்ளது;
சேவையகங்களுக்கு நகலெடுக்கப்பட்டது;
சர்வர் ஒரு புதிய .dep வெளியே இழுக்கிறது;
dpkg -i;
புதிய பதிப்பிற்கு அழகான மறுதொடக்கம்.

வித்தியாசம் என்னவென்றால், எங்கள் பைனரி காப்பகங்களில் தொகுக்கப்பட்டுள்ளது .deb, மற்றும் அவர்கள் வெளியேற்றும் போது dpkg -i கணினியில் வைக்கப்படுகின்றன. ஏன் kPHP பைனரியாகவும், என்ஜின்கள் dpkg ஆகவும் பயன்படுத்தப்படுகின்றன? அது அப்படியே நடந்தது. இது வேலை செய்கிறது - அதைத் தொடாதே.

பயனுள்ள இணைப்புகள்:

அன்டன் கிர்யுஷ்கின் அறிக்கை "Vkontakte கணினி நிர்வாகி. எப்படி?" காப்பிஃபாஸ்ட் மற்றும் கிசுகிசு பற்றிய விவரங்களுடன்.
யூரி நஸ்ரெட்டினோவ் அறிக்கை "பல்லாயிரக்கணக்கான சேவையகங்களில் இருந்து VK எப்படி CLickHouse இல் தரவைச் செருகுகிறது".
எனது அறிக்கை "VKontakte இன் உதாரணத்தைப் பயன்படுத்தி வளர்ந்து வரும் திட்டத்தின் கட்டிடக்கலை", ஆனால் வளர்ச்சிக் கண்ணோட்டத்தில், வன்பொருள் அல்ல.

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

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

VKontakte இன் கட்டிடக்கலை மற்றும் வேலை பற்றிய கேள்விகள்