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

தொழில்நுட்ப தேர்வு

அது அவ்வளவு மோசமானதா? தனி ரெடிஸ் (standalone redis) 1 மாஸ்டர் மற்றும் N அடிமைகளின் கட்டமைப்பில் உள்ளதா? நான் ஏன் அதை வழக்கொழிந்த தொழில்நுட்பம் என்று அழைக்கிறேன்?

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

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

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

விருப்பங்கள் என்ன?

• மிகவும் விலையுயர்ந்த மற்றும் பணக்கார தீர்வு Redis-Enterprise ஆகும். இது முழு தொழில்நுட்ப ஆதரவுடன் ஒரு பெட்டி தீர்வு. தொழில்நுட்பக் கண்ணோட்டத்தில் இது சிறந்ததாகத் தோன்றினாலும், கருத்தியல் காரணங்களுக்காக அது நமக்குப் பொருந்தவில்லை.
• ரெடிஸ்-கிளஸ்டர். பெட்டிக்கு வெளியே மாஸ்டர் ஃபெயில்ஓவர் மற்றும் ஷார்டிங்கிற்கான ஆதரவு உள்ளது. இடைமுகம் வழக்கமான பதிப்பிலிருந்து கிட்டத்தட்ட வேறுபட்டதல்ல. இது நம்பிக்கைக்குரியதாகத் தெரிகிறது, ஆபத்துகளைப் பற்றி பின்னர் பேசுவோம்.
• Tarantool, Memcache, Aerospike மற்றும் பல. இந்த கருவிகள் அனைத்தும் கிட்டத்தட்ட ஒரே காரியத்தைச் செய்கின்றன. ஆனால் ஒவ்வொன்றும் அதன் சொந்த குறைபாடுகளைக் கொண்டுள்ளன. எல்லா முட்டைகளையும் ஒரே கூடையில் வைக்க வேண்டாம் என்று முடிவு செய்தோம். நாங்கள் மற்ற பணிகளுக்கு Memcache மற்றும் Tarantool ஐப் பயன்படுத்துகிறோம், மேலும் முன்னோக்கிப் பார்க்கும்போது, ​​எங்கள் நடைமுறையில் அவற்றுடன் அதிகமான சிக்கல்கள் இருந்தன என்று நான் கூறுவேன்.

பயன்பாட்டின் பிரத்தியேகங்கள்

ரெடிஸ் மூலம் வரலாற்று ரீதியாக என்னென்ன பிரச்சனைகளை தீர்த்துள்ளோம், என்ன செயல்பாடுகளை பயன்படுத்தினோம் என்பதைப் பார்ப்போம்:

• 2GIS போன்ற தொலைநிலை சேவைகளுக்கான கோரிக்கைகளுக்கு முன் தற்காலிக சேமிப்பு | கோலாங்
  

  MGET MSET அமைக்கவும் "டிபியைத் தேர்ந்தெடு"

• MYSQL க்கு முன் கேச் | PHP
  

  அமைக்கவும் MGET MSET ஸ்கேன் "சாவி மூலம் பேட்டர்ன்" "தேர்வு DB"

• அமர்வுகள் மற்றும் இயக்கி ஒருங்கிணைப்புகளுடன் பணிபுரியும் சேவைக்கான முக்கிய சேமிப்பு | கோலாங்
  

  அமை MGET MSET "டிபியைத் தேர்ந்தெடு" "ஜியோ விசையைச் சேர்" "ஜியோ விசையைப் பெறு" ஸ்கேன்

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

முறை
விளக்கம்
ரெடிஸ்-கிளஸ்டரின் அம்சங்கள்
முடிவு

அமைக்க
எழுது/வாசிப்பு விசை

MGET MSET
பல விசைகளை எழுதவும்/படிக்கவும்
விசைகள் வெவ்வேறு முனைகளில் இருக்கும். ஆயத்த நூலகங்கள் ஒரு முனைக்குள் மட்டுமே பல செயல்பாடுகளைச் செய்ய முடியும்
MGET ஐ N GET செயல்பாடுகளின் பைப்லைனுடன் மாற்றவும்

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

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

ஜியோ
ஜியோக்கியுடன் செயல்பாடுகள்
ஜியோக்கி துண்டிக்கப்படவில்லை

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

ரெடிஸ் vs ரெடிஸ்-கிளஸ்டர்

ஒரு கிளஸ்டருக்கு மாறும்போது நாம் எதை இழக்கிறோம், எதைப் பெறுகிறோம்?

• குறைபாடுகள்: பல தரவுத்தளங்களின் செயல்பாட்டை இழக்கிறோம்.
  • தர்க்கரீதியாக தொடர்பில்லாத தரவை ஒரு கிளஸ்டரில் சேமிக்க விரும்பினால், முன்னொட்டு வடிவில் ஊன்றுகோல்களை உருவாக்க வேண்டும்.
  • SCAN, DBSIZE, CLEAR DB போன்ற அனைத்து "அடிப்படை" செயல்பாடுகளையும் இழக்கிறோம்.
  • பல-செயல்பாடுகளை செயல்படுத்துவது மிகவும் கடினமாகிவிட்டது, ஏனெனில் இதற்கு பல முனைகளுக்கான அணுகல் தேவைப்படலாம்.
• நன்மைகள்:
  • மாஸ்டர் ஃபெயில்ஓவர் வடிவத்தில் தவறு சகிப்புத்தன்மை.
  • ரெடிஸ் பக்கத்தில் ஷார்டிங்.
  • அணு மற்றும் வேலையில்லா நேரம் இல்லாமல் முனைகளுக்கு இடையில் தரவை மாற்றவும்.
  • வேலையில்லா நேரம் இல்லாமல் திறன் மற்றும் சுமைகளைச் சேர்க்கவும் மற்றும் மறுபகிர்வு செய்யவும்.

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

நகர்த்த தயாராகிறது

நகர்த்துவதற்கான தேவைகளுடன் ஆரம்பிக்கலாம்:

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

கிளஸ்டர் பராமரிப்பு

நகர்த்துவதற்கு சற்று முன், நாம் கிளஸ்டரை ஆதரிக்க முடியுமா என்பதைப் பற்றி சிந்திக்க வேண்டும்:

• விளக்கப்படங்கள். CPU சுமை, நினைவகப் பயன்பாடு, கிளையண்டுகளின் எண்ணிக்கை, GET, SET, AUTH செயல்பாடுகள் போன்றவற்றை வரைபடமாக்க, நாங்கள் Prometheus மற்றும் Grafana ஐப் பயன்படுத்துகிறோம்.
• நிபுணத்துவம். நாளை உங்கள் பொறுப்பின் கீழ் ஒரு பெரிய கிளஸ்டர் இருக்கும் என்று கற்பனை செய்து பாருங்கள். உடைந்தால், உங்களைத் தவிர வேறு யாராலும் சரி செய்ய முடியாது. அவர் மெதுவாகச் செல்ல ஆரம்பித்தால், எல்லோரும் உங்களை நோக்கி ஓடுவார்கள். நீங்கள் ஆதாரங்களைச் சேர்க்க அல்லது சுமைகளை மறுபகிர்வு செய்ய விரும்பினால், உங்களிடம் திரும்பவும். 25 வயதில் சாம்பல் நிறமாக மாறாமல் இருக்க, இந்த நிகழ்வுகளை வழங்குவது மற்றும் சில செயல்களின் கீழ் தொழில்நுட்பம் எவ்வாறு செயல்படும் என்பதை முன்கூட்டியே சரிபார்க்க அறிவுறுத்தப்படுகிறது. "நிபுணத்துவம்" பிரிவில் இதைப் பற்றி மேலும் விரிவாகப் பேசலாம்.
• கண்காணிப்பு மற்றும் எச்சரிக்கைகள். ஒரு கிளஸ்டர் உடைந்தால், அதைப் பற்றி நீங்கள் முதலில் தெரிந்துகொள்ள வேண்டும். எல்லா முனைகளும் க்ளஸ்டரின் நிலையைப் பற்றிய ஒரே தகவலைத் தரும் (ஆம், அது வித்தியாசமாக நடக்கும்) என்ற அறிவிப்புக்கு இங்கே நாங்கள் மட்டுப்படுத்தப்பட்டுள்ளோம். ரெடிஸ் கிளையன்ட் சேவைகளின் விழிப்பூட்டல்கள் மூலம் மற்ற சிக்கல்களை விரைவாகக் கவனிக்க முடியும்.

கடக்கும்

நாம் எப்படி நகர்த்துவோம்:

• முதலில், கிளஸ்டருடன் வேலை செய்ய நீங்கள் ஒரு நூலகத்தைத் தயாரிக்க வேண்டும். Go பதிப்பின் அடிப்படையாக go-redis எடுத்து அதை நமக்கு ஏற்றவாறு கொஞ்சம் மாற்றிக்கொண்டோம். நாங்கள் குழாய்கள் மூலம் பல முறைகளை செயல்படுத்தினோம், மேலும் கோரிக்கைகளை மீண்டும் செய்வதற்கான விதிகளை சிறிது சரி செய்தோம். PHP பதிப்பில் அதிக சிக்கல்கள் இருந்தன, ஆனால் நாங்கள் இறுதியில் php-redis இல் குடியேறினோம். அவர்கள் சமீபத்தில் கிளஸ்டர் ஆதரவை அறிமுகப்படுத்தினர், இது எங்கள் கருத்துப்படி நன்றாக இருக்கிறது.
• அடுத்து நீங்கள் கிளஸ்டரையே வரிசைப்படுத்த வேண்டும். இது உள்ளமைவு கோப்பின் அடிப்படையில் இரண்டு கட்டளைகளில் உண்மையில் செய்யப்படுகிறது. அமைப்பை இன்னும் விரிவாக கீழே விவாதிப்போம்.
• படிப்படியாக நகர்த்துவதற்கு, உலர் பயன்முறையைப் பயன்படுத்துகிறோம். ஒரே இடைமுகத்துடன் லைப்ரரியின் இரண்டு பதிப்புகள் எங்களிடம் இருப்பதால் (ஒன்று வழக்கமான பதிப்பிற்கு, மற்றொன்று கிளஸ்டருக்கு), ஒரு தனிப் பதிப்பில் வேலை செய்யும் ஒரு ரேப்பரை உருவாக்குவதற்கு எதுவும் செலவாகாது, மேலும் அனைத்து கோரிக்கைகளையும் கிளஸ்டருக்கு இணையாக நகலெடுக்கும். பதில்களை ஒப்பிட்டு, பதிவுகளில் உள்ள முரண்பாடுகளை எழுதவும் (நம்முடைய விஷயத்தில் NewRelic இல்). இதனால், வெளியீட்டின் போது கிளஸ்டர் பதிப்பு உடைந்தாலும், எங்கள் உற்பத்தி பாதிக்கப்படாது.
• உலர் பயன்முறையில் கிளஸ்டரை உருட்டினால், பதில் முரண்பாடுகளின் வரைபடத்தை நாம் அமைதியாகப் பார்க்கலாம். பிழை விகிதம் மெதுவாக ஆனால் நிச்சயமாக சில சிறிய மாறிலியை நோக்கி நகர்ந்தால், எல்லாம் நன்றாக இருக்கும். ஏன் இன்னும் முரண்பாடுகள் உள்ளன? தனி பதிப்பில் பதிவு செய்வது கிளஸ்டரை விட சற்று முன்னதாகவே நிகழ்கிறது, மேலும் மைக்ரோலாக் காரணமாக, தரவு வேறுபடலாம். முரண்பாடு பதிவுகளைப் பார்ப்பது மட்டுமே எஞ்சியுள்ளது, மேலும் அவை அனைத்தும் பதிவின் அணுமின்மையால் விளக்கப்பட்டால், நாம் தொடரலாம்.
• இப்போது நீங்கள் உலர் பயன்முறையை எதிர் திசையில் மாற்றலாம். நாங்கள் கிளஸ்டரிலிருந்து எழுதுவோம் மற்றும் படிப்போம், மேலும் அதை ஒரு தனி பதிப்பாக நகலெடுப்போம். எதற்காக? அடுத்த வாரத்தில் நான் கிளஸ்டரின் வேலையை கவனிக்க விரும்புகிறேன். உச்ச சுமைகளில் சிக்கல்கள் இருப்பதாக திடீரென்று மாறிவிட்டால், அல்லது நாங்கள் எதையாவது கணக்கில் எடுத்துக்கொள்ளவில்லை என்றால், எப்பொழுதும் பழைய குறியீடு மற்றும் தற்போதைய தரவுக்கு அவசரநிலை திரும்பப் பெறுவோம், உலர் பயன்முறைக்கு நன்றி.
• உலர் பயன்முறையை முடக்குவது மற்றும் தனி பதிப்பை அகற்றுவது மட்டுமே மீதமுள்ளது.

பரிசோதனை

முதலில், கிளஸ்டர் வடிவமைப்பு பற்றி சுருக்கமாக.

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

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

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

இப்போது செய்யக்கூடிய செயல்பாடுகளைப் பற்றி பேசலாம்.

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

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

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

கட்டமைப்பு

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

• நேரம் முடிந்தது 0
  செயலற்ற இணைப்புகள் மூடப்பட்ட நேரம் (வினாடிகளில்). 0 - மூட வேண்டாம்
  எங்களுடைய ஒவ்வொரு நூலகத்திலும் இணைப்புகளைச் சரியாக மூட முடியவில்லை. இந்த அமைப்பை முடக்குவதன் மூலம், வாடிக்கையாளர்களின் எண்ணிக்கையில் வரம்பை அடையும் அபாயம் உள்ளது. மறுபுறம், அத்தகைய சிக்கல் இருந்தால், இழந்த இணைப்புகளை தானாக நிறுத்துவது அதை மறைக்கும், மேலும் நாம் கவனிக்காமல் இருக்கலாம். கூடுதலாக, தொடர் இணைப்புகளைப் பயன்படுத்தும் போது இந்த அமைப்பை நீங்கள் இயக்கக்கூடாது.
• xy & பிற்சேர்க்கை ஆம் மட்டும் சேமி
  RDB ஸ்னாப்ஷாட்டைச் சேமிக்கிறது.
  RDB/AOF சிக்கல்களை கீழே விரிவாக விவாதிப்போம்.
• ஸ்டாப்-ரைட்ஸ்-ஆன்-பிஜிசேவ்-எரர் இல்லை & ஸ்லேவ்-சர்வ்-ஸ்டால்-டேட்டா ஆம்
  இயக்கப்பட்டால், RDB ஸ்னாப்ஷாட் உடைந்தால், மாஸ்டர் மாற்ற கோரிக்கைகளை ஏற்றுக்கொள்வதை நிறுத்துவார். எஜமானருடனான தொடர்பு துண்டிக்கப்பட்டால், அடிமை கோரிக்கைகளுக்கு தொடர்ந்து பதிலளிக்கலாம் (ஆம்). அல்லது பதிலளிப்பதை நிறுத்திவிடும் (இல்லை)
  ரெடிஸ் பூசணிக்காயாக மாறும் சூழ்நிலையில் நாங்கள் மகிழ்ச்சியடையவில்லை.
• repl-ping-slave-period 5
  இந்த காலகட்டத்திற்குப் பிறகு, மாஸ்டர் உடைந்துவிட்டார் என்று நாங்கள் கவலைப்படத் தொடங்குவோம், தோல்வியுற்ற நடைமுறையை மேற்கொள்ள வேண்டிய நேரம் இது.
  தவறான நேர்மறைகளுக்கும் தோல்வியைத் தூண்டுவதற்கும் இடையில் நீங்கள் கைமுறையாக சமநிலையைக் கண்டறிய வேண்டும். எங்கள் நடைமுறையில் இது 5 வினாடிகள்.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  தோல்வியுற்ற பிரதிக்காக இவ்வளவு தரவை ஒரு பஃபரில் சேமிக்க முடியும். இடையகம் தீர்ந்துவிட்டால், நீங்கள் முழுமையாக ஒத்திசைக்க வேண்டும்.
  அதிக மதிப்பை அமைப்பது நல்லது என்று பயிற்சி கூறுகிறது. ஒரு பிரதி தாமதமாகத் தொடங்குவதற்கு ஏராளமான காரணங்கள் உள்ளன. அது பின்தங்கியிருந்தால், பெரும்பாலும் உங்கள் மாஸ்டர் ஏற்கனவே சமாளிக்க சிரமப்படுகிறார், மேலும் முழு ஒத்திசைவு கடைசி வைக்கோலாக இருக்கும்.
• அதிகபட்ச வாடிக்கையாளர் 10000
  ஒரு முறை வாடிக்கையாளர்களின் அதிகபட்ச எண்ணிக்கை.
  எங்கள் அனுபவத்தில், அதிக மதிப்பை அமைப்பது நல்லது. ரெடிஸ் 10k இணைப்புகளை நன்றாக கையாளுகிறது. கணினியில் போதுமான சாக்கெட்டுகள் உள்ளன என்பதை உறுதிப்படுத்தவும்.
• maxmemory-policy volatile-ttl
  கிடைக்கக்கூடிய நினைவக வரம்பை எட்டும்போது விசைகள் நீக்கப்படும் விதி.
  இங்கே முக்கியமானது விதி அல்ல, ஆனால் இது எப்படி நடக்கும் என்பதைப் புரிந்துகொள்வது. நினைவக வரம்பை எட்டும்போது சாதாரணமாக வேலை செய்யும் திறனுக்காக ரெடிஸைப் பாராட்டலாம்.

RDB மற்றும் AOF சிக்கல்கள்

Redis தானே RAM இல் அனைத்து தகவல்களையும் சேமித்து வைத்தாலும், வட்டில் தரவைச் சேமிப்பதற்கான வழிமுறையும் உள்ளது. இன்னும் துல்லியமாக, மூன்று வழிமுறைகள்:

• RDB-ஸ்னாப்ஷாட் - எல்லா தரவின் முழுமையான ஸ்னாப்ஷாட். SAVE XY உள்ளமைவைப் பயன்படுத்தி அமைத்து, "குறைந்தபட்சம் Y விசைகள் மாறியிருந்தால் ஒவ்வொரு X வினாடிகளிலும் எல்லா தரவின் முழு ஸ்னாப்ஷாட்டைச் சேமிக்கவும்" என்று படிக்கவும்.
• இணைக்க மட்டும் கோப்பு - அவை செய்யப்படும் வரிசையில் செயல்பாடுகளின் பட்டியல். ஒவ்வொரு X வினாடிகளிலும் அல்லது ஒவ்வொரு Y செயல்பாடுகளிலும் புதிய உள்வரும் செயல்பாடுகளைச் சேர்க்கிறது.
• RDB மற்றும் AOF ஆகியவை முந்தைய இரண்டின் கலவையாகும்.

எல்லா முறைகளும் அவற்றின் நன்மைகள் மற்றும் தீமைகள் உள்ளன, அவை அனைத்தையும் நான் பட்டியலிட மாட்டேன், என் கருத்துப்படி, வெளிப்படையாக இல்லாத புள்ளிகளுக்கு நான் கவனத்தை ஈர்க்கிறேன்.

முதலில், RDB ஸ்னாப்ஷாட்டைச் சேமிக்க, FORKஐ அழைக்க வேண்டும். நிறைய தரவு இருந்தால், சில மில்லி விநாடிகள் முதல் ஒரு நொடி வரை அனைத்து ரெடிஸ்களையும் இது தொங்கவிடலாம். கூடுதலாக, கணினி அத்தகைய ஸ்னாப்ஷாட்டுக்கு நினைவகத்தை ஒதுக்க வேண்டும், இது தருக்க கணினியில் ரேம் இரட்டை விநியோகத்தை வைத்திருக்க வேண்டிய அவசியத்திற்கு வழிவகுக்கிறது: ரெடிஸுக்கு 8 ஜிபி ஒதுக்கப்பட்டால், மெய்நிகர் கணினியில் 16 ஜிபி இருக்க வேண்டும் அது.

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

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

முடிவுக்கு

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

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