ஹே ஹப்ர்!

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

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

கிடைமட்ட அளவிடுதல்

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

எடுத்துக்காட்டாக, நான் சுருக்க கிளவுட் கோப்பு சேமிப்பகத்தை எடுத்துக்கொள்கிறேன், அதாவது OwnCloud, OneDrive மற்றும் பலவற்றின் சில அனலாக்.

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

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

CQRS

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

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

1. வாடிக்கையாளர் சேவையகத்திற்கு ஒரு கோரிக்கையை அனுப்பினார்.
2. சேவையகம் நீண்ட செயலாக்க நேரத்தை தொடங்கியது.
3. சர்வர் முடிவுடன் கிளையண்டிற்கு பதிலளித்தது.

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

1. வாடிக்கையாளர் புதுப்பிப்புகளுக்கு குழுசேர்ந்துள்ளார்.
2. வாடிக்கையாளர் சேவையகத்திற்கு ஒரு கோரிக்கையை அனுப்பினார்.
3. சேவையகம் "கோரிக்கை ஏற்கப்பட்டது" என்று பதிலளித்தது.
4. சேவையகம் "1" புள்ளியிலிருந்து சேனல் மூலம் முடிவுடன் பதிலளித்தது.

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

சுவாரஸ்யமாக, உள்வரும் செய்திகளைச் செயலாக்குவதற்கான குறியீடு கிளையண்டால் தாக்கப்பட்ட நிகழ்வுகள் மற்றும் பிற வாடிக்கையாளர்களின் நிகழ்வுகள் உட்பட மற்ற நிகழ்வுகளுக்கு ஒரே மாதிரியாக (100% அல்ல) மாறும்.

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

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

நிகழ்வு ஆதாரம்

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

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

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

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

இந்த அணுகுமுறையின் முக்கிய அம்சங்கள்:

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

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

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

இரண்டு பயனர்களுக்கு வரைபடம் இப்படி இருக்கும் (வெவ்வேறு பயனர்களுக்கான சேவைகள் வெவ்வேறு வண்ணங்களில் குறிக்கப்படுகின்றன):

அத்தகைய கலவையிலிருந்து போனஸ்:

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

இருப்பினும், தீமைகள் உடனடியாகத் தெரியும்:

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

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

அதன் விளைவாக:

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

கூர்மையானது

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

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

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

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

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

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

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

நிலையான உள்ளடக்க ஹோஸ்டிங்

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

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

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

• சேவையகம் ஒரு பதிவிறக்க URL ஐ வழங்குகிறது. இது file_id + விசை வடிவத்தில் இருக்கலாம், இதில் விசை என்பது ஒரு மினி-டிஜிட்டல் கையொப்பமாகும், இது அடுத்த XNUMX மணிநேரத்திற்கு ஆதாரத்தை அணுகுவதற்கான உரிமையை வழங்குகிறது.
• கோப்பு பின்வரும் விருப்பங்களுடன் எளிய nginx மூலம் விநியோகிக்கப்படுகிறது:
  • உள்ளடக்க கேச்சிங். இந்த சேவையானது ஒரு தனி சர்வரில் அமைந்திருப்பதால், சமீபத்திய பதிவிறக்கம் செய்யப்பட்ட அனைத்து கோப்புகளையும் வட்டில் சேமிக்கும் திறனுடன் எதிர்காலத்திற்கான ஒரு இருப்பை நாமே விட்டுவிட்டோம்.
  • இணைப்பை உருவாக்கும் நேரத்தில் விசையைச் சரிபார்க்கிறது
• விருப்பத்தேர்வு: ஸ்ட்ரீமிங் உள்ளடக்க செயலாக்கம். எடுத்துக்காட்டாக, சேவையில் உள்ள எல்லா கோப்புகளையும் சுருக்கினால், இந்த தொகுதியில் நேரடியாக அன்சிப்பிங் செய்யலாம். இதன் விளைவாக: IO செயல்பாடுகள் அவை சார்ந்த இடத்தில் செய்யப்படுகின்றன. ஜாவாவில் உள்ள ஒரு காப்பகமானது கூடுதல் நினைவகத்தை எளிதாக ஒதுக்கும், ஆனால் வணிக தர்க்கத்துடன் ஒரு சேவையை ரஸ்ட்/சி++ நிபந்தனைகளில் மீண்டும் எழுதுவதும் பயனற்றதாக இருக்கலாம். எங்கள் விஷயத்தில், வெவ்வேறு செயல்முறைகள் (அல்லது சேவைகள் கூட) பயன்படுத்தப்படுகின்றன, எனவே நாம் வணிக தர்க்கம் மற்றும் IO செயல்பாடுகளை மிகவும் திறம்பட பிரிக்கலாம்.

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

மற்றொரு உதாரணம் (வலுவூட்டலுக்கு): நீங்கள் Jenkins/TeamCity உடன் பணிபுரிந்திருந்தால், இரண்டு தீர்வுகளும் ஜாவாவில் எழுதப்பட்டுள்ளன என்பது உங்களுக்குத் தெரியும். இவை இரண்டும் ஒரு ஜாவா செயல்முறையாகும், இது பில்ட் ஆர்கெஸ்ட்ரேஷன் மற்றும் உள்ளடக்க மேலாண்மை இரண்டையும் கையாளுகிறது. குறிப்பாக, அவர்கள் இருவருக்கும் "சர்வரில் இருந்து ஒரு கோப்பு/கோப்புறையை மாற்றுதல்" போன்ற பணிகள் உள்ளன. உதாரணமாக: கலைப்பொருட்களை வழங்குதல், மூலக் குறியீட்டை மாற்றுதல் (முகவர் களஞ்சியத்திலிருந்து குறியீட்டை நேரடியாக பதிவிறக்கம் செய்யாதபோது, ​​ஆனால் சேவையகம் அவருக்காக அதைச் செய்யும் போது), பதிவுகளுக்கான அணுகல். இந்த பணிகள் அனைத்தும் அவற்றின் IO சுமையில் வேறுபடுகின்றன. அதாவது, சிக்கலான வணிக தர்க்கத்திற்குப் பொறுப்பான சேவையகம் அதே நேரத்தில் பெரிய அளவிலான தரவைத் திறம்பட செலுத்த முடியும். மிகவும் சுவாரஸ்யமான விஷயம் என்னவென்றால், அத்தகைய செயல்பாட்டை அதே திட்டத்தின்படி அதே nginx க்கு வழங்க முடியும் (தரவு விசை கோரிக்கையில் சேர்க்கப்பட வேண்டும் என்பதைத் தவிர).

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

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

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

முடிவுக்கு

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

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

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

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

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