ከአሥር ዓመት በላይ ወደሚገኝ ምርት ስንመጣ፣ ጊዜ ያለፈባቸው ቴክኖሎጂዎች በውስጡ ማግኘታቸው ምንም አያስደንቅም። ነገር ግን በስድስት ወራት ውስጥ ጭነቱን 10 እጥፍ ከፍ ማድረግ ካለብዎት እና የመውደቅ ዋጋ በመቶዎች የሚቆጠሩ ጊዜ ይጨምራል? በዚህ አጋጣሚ አሪፍ ሃይሎድ ኢንጂነር ያስፈልግዎታል። ነገር ግን ገረድ በሌለበት ሁኔታ ችግሩን እንድፈታ አደራ ሰጡኝ። በአንቀጹ የመጀመሪያ ክፍል ከሬዲስ ወደ ሬዲስ-ክላስተር እንዴት እንደሄድን እነግርዎታለሁ ፣ እና በሁለተኛው ክፍል ክላስተር እንዴት መጠቀም እንደሚቻል እና በሚጠቀሙበት ጊዜ ምን ትኩረት መስጠት እንዳለበት ምክር እሰጣለሁ።

የቴክኖሎጂ ምርጫ

ያን ያህል መጥፎ ነው? Redis መለየት (ብቻ redis) በ 1 ማስተር እና ኤን ባሮች ውቅር? ለምንድነው ጊዜ ያለፈበት ቴክኖሎጂ የምለው?

አይ, Redis ያን ያህል መጥፎ አይደለም ... ነገር ግን, ችላ ሊባሉ የማይችሉ አንዳንድ ድክመቶች አሉ.

• በመጀመሪያ ፣ Redis ከዋና ውድቀት በኋላ የአደጋ ማገገሚያ ዘዴዎችን አይደግፍም። ይህንን ችግር ለመፍታት የቪ.አይ.ፒ.አይ.ፒ.ን ወደ አዲስ ጌታ በማስተላለፍ የአንዱን ባሪያ ሚና በመቀየር የቀረውን በመቀየር ውቅር ተጠቅመንበታል። ይህ ዘዴ ሠርቷል, ነገር ግን አስተማማኝ መፍትሄ ተብሎ ሊጠራ አይችልም. በመጀመሪያ, የውሸት ማንቂያዎች ተከስተዋል, እና ሁለተኛ, ሊወገድ የሚችል ነበር, እና ከቀዶ ጥገና በኋላ የፀደይቱን ኃይል ለመሙላት በእጅ የሚወሰዱ እርምጃዎች ያስፈልጋሉ.

• በሁለተኛ ደረጃ አንድ ጌታ ብቻ መኖሩ የሻርዲንግ ችግርን አስከትሏል. ብዙ ነፃ ስብስቦችን መፍጠር ነበረብን "1 ማስተር እና ኤን ባሪያዎች," ከዚያም በእጅ የውሂብ ጎታውን በእነዚህ ማሽኖች መካከል ማሰራጨት እና ነገ ከመረጃ ቋቱ ውስጥ አንዱ በጣም እንደማያብጥ እና ወደ ሌላ ምሳሌ እንዲዛወር ተስፋ እናደርጋለን.

ምን አማራጮች አሉ?

• በጣም ውድ እና የበለጸገ መፍትሔ Redis-Enterprise ነው. ይህ ሙሉ ቴክኒካዊ ድጋፍ ያለው በቦክስ የተሞላ መፍትሄ ነው። ምንም እንኳን ከቴክኒካዊ እይታ አንጻር ተስማሚ ቢመስልም, ለርዕዮተ-ዓለም ምክንያቶች አልተመቸንም.
• ሬዲስ-ክላስተር። ከሳጥኑ ውስጥ ለዋና አለመሳካት እና ሻርዲንግ ድጋፍ አለ። በይነገጹ ከመደበኛው ስሪት ፈጽሞ የተለየ አይደለም። ተስፋ ሰጭ ይመስላል, በኋላ ላይ ስለ ወጥመዶች እንነጋገራለን.
• Tarantool, Memcache, Aerospike እና ሌሎች. እነዚህ ሁሉ መሳሪያዎች በጣም ተመሳሳይ ነገር ያደርጋሉ. ግን እያንዳንዳቸው የራሳቸው ድክመቶች አሏቸው. ሁሉንም እንቁላሎቻችንን በአንድ ቅርጫት ውስጥ ላለማስቀመጥ ወሰንን. Memcache እና Tarantoolን ለሌሎች ተግባራት እንጠቀማለን, እና, ወደፊት ስንመለከት, በተግባራችን ከእነሱ ጋር ተጨማሪ ችግሮች እንደነበሩ እላለሁ.

የአጠቃቀም ዝርዝሮች

በሬዲስ ምን አይነት ችግሮችን በታሪክ እንደፈታናቸው እና በምን አይነት ተግባር እንደተጠቀምን እንይ፡-

• እንደ 2GIS ያሉ የርቀት አገልግሎቶችን ከመጠየቅ በፊት መሸጎጫ | ጎላንግ
  

  MGET MSET አዘጋጅ "DB ን ይምረጡ"

• ከ MYSQL በፊት መሸጎጫ | ፒኤችፒ
  

  አግኝ MGET MSET SCAN "ቁልፍ በስርአት" "DB ምረጥ"

• ከክፍለ-ጊዜዎች እና ከአሽከርካሪዎች መጋጠሚያዎች ጋር አብሮ ለመስራት ዋናው ማከማቻ | ጎላንግ
  

  MGET MSET አዘጋጅ "DB ምረጥ" "ጂኦ ቁልፍ አክል" "ጂኦ ቁልፍ አግኝ" ቅኝት አግኝ

እንደሚመለከቱት, ምንም ከፍተኛ ሂሳብ የለም. ታዲያ ምን ችግር አለው? እያንዳንዱን ዘዴ ለየብቻ እንመልከታቸው.

ዘዴ
መግለጫ
የ Redis-cluster ባህሪያት
ዉሳኔ

ያዘጋጁ
ቁልፍ ፃፍ/አንብብ

MGET MSET
ብዙ ቁልፎችን ፃፍ/አንብብ
ቁልፎቹ በተለያዩ አንጓዎች ላይ ይሆናሉ. ዝግጁ የሆኑ ቤተ-ፍርግሞች በአንድ መስቀለኛ መንገድ ውስጥ ብቻ ብዙ ስራዎችን ማከናወን ይችላሉ።
MGETን በN GET ኦፕሬሽኖች ቧንቧ ይተኩ

ዲቢን ይምረጡ
የምንሰራውን መሰረት ይምረጡ
ብዙ የውሂብ ጎታዎችን አይደግፍም።
ሁሉንም ነገር በአንድ የውሂብ ጎታ ውስጥ ያስቀምጡ. ቅድመ ቅጥያዎችን ወደ ቁልፎች ያክሉ

SCAN
በመረጃ ቋቱ ውስጥ ያሉትን ሁሉንም ቁልፎች ይሂዱ
አንድ የውሂብ ጎታ ስላለን በክላስተር ውስጥ ያሉትን ሁሉንም ቁልፎች ማለፍ በጣም ውድ ነው።
በአንድ ቁልፍ ውስጥ የማይለዋወጥ ነገርን ይያዙ እና በዚህ ቁልፍ ላይ HSCAN ያድርጉ። ወይም ሙሉ በሙሉ እምቢ ማለት

GEO
ክዋኔዎች ከጂኦኪ ጋር
ጂኦኪው አልተሰነጠቀም።

ቁልፍ በስርዓተ-ጥለት
በስርዓተ-ጥለት ቁልፍን በመፈለግ ላይ
አንድ የውሂብ ጎታ ስላለን በክላስተር ውስጥ ያሉትን ሁሉንም ቁልፎች እንፈልጋለን። እጅግ ውድ
እንደ SCAN ሁኔታ የማይለዋወጥን እምቢ ወይም አቆይ

Redis vs Redis-ክላስተር

ወደ ክላስተር ስንቀየር ምን እናጣለን እና ምን እናገኛለን?

• ጉዳቶች: የበርካታ የውሂብ ጎታዎችን ተግባራዊነት እናጣለን.
  • በአመክንዮ ያልተገናኘ መረጃን በአንድ ዘለላ ውስጥ ማከማቸት ከፈለግን በቅድመ ቅጥያ መልክ ክራንች መስራት አለብን።
  • እንደ SCAN፣ DBSIZE፣ CLEAR DB፣ ወዘተ ያሉ ሁሉንም የ"ቤዝ" ስራዎች እናጣለን።
  • የባለብዙ ኦፕሬሽን ስራዎችን ለመተግበር በጣም አስቸጋሪ ሆኗል ምክንያቱም ወደ በርካታ አንጓዎች መድረስን ሊጠይቅ ይችላል.
• Pluses:
  • በዋና አለመሳካት መልክ የስህተት መቻቻል።
  • በሬዲስ ጎን ላይ መጋራት።
  • በኖዶች መካከል በአቶሚክ እና ያለማቋረጥ ውሂብ ያስተላልፉ።
  • ያለማቋረጥ አቅም እና ጭነቶች ይጨምሩ እና እንደገና ያሰራጩ።

ከፍተኛ የስህተት መቻቻል ማቅረብ ካላስፈለገህ ወደ ክላስተር መሸጋገር ዋጋ የለውም፣ ምክንያቱም ቀላል ያልሆነ ተግባር ሊሆን ይችላል ብዬ እደምዳለሁ። ነገር ግን መጀመሪያ ላይ በተለየ ስሪት እና በክላስተር ስሪት መካከል ከመረጡ, ክላስተር መምረጥ አለብዎት, ምክንያቱም እሱ የከፋ አይደለም እና በተጨማሪም, አንዳንድ ራስ ምታትን ያስወግዳል.

ለመንቀሳቀስ በመዘጋጀት ላይ

ለመንቀሳቀስ በሚያስፈልጉት መስፈርቶች እንጀምር፡-

• እንከን የለሽ መሆን አለበት. ለ 5 ደቂቃዎች ሙሉ አገልግሎት ማቆም ለእኛ አይስማማንም.
• በተቻለ መጠን አስተማማኝ እና ቀስ በቀስ መሆን አለበት. በሁኔታው ላይ የተወሰነ ቁጥጥር እንዲኖረኝ እፈልጋለሁ. ሁሉንም ነገር በአንድ ጊዜ መጣል እና መልሶ መመለሻ ቁልፍ ላይ መጸለይ አንፈልግም።
• በሚንቀሳቀስበት ጊዜ አነስተኛ የውሂብ መጥፋት። በአቶሚክ መንቀሳቀስ በጣም ከባድ እንደሚሆን እንረዳለን፣ስለዚህ በመደበኛ እና በክላስተር ሬዲስ ውስጥ ባለው መረጃ መካከል የተወሰነ ማመሳሰልን እንፈቅዳለን።

የክላስተር ጥገና

ከመንቀሳቀሱ በፊት፣ ክላስተርን መደገፍ ስለምንችል ማሰብ አለብን፡-

• ገበታዎች የሲፒዩ ጭነትን፣ የማህደረ ትውስታ አጠቃቀምን፣ የደንበኞችን ብዛት፣ የGET፣ SET፣ AUTH ኦፕሬሽኖችን ወዘተ ለመቅረጽ ፕሮሜቴየስ እና ግራፋናን እንጠቀማለን።
• ባለሙያ። በነገው እለት በሃላፊነትህ ስር ትልቅ ስብስብ እንደሚኖርህ አስብ። ከተሰበረ ማንም ሊያስተካክለው አይችልም። እሱ ፍጥነት መቀነስ ከጀመረ, ሁሉም ወደ እርስዎ ይሮጣሉ. መርጃዎችን ማከል ወይም ጭነቱን እንደገና ማከፋፈል ከፈለጉ ወደ እርስዎ ይመለሱ። በ 25 ውስጥ ግራጫ ላለመሆን, ለእነዚህ ጉዳዮች ለማቅረብ እና ቴክኖሎጂው በተወሰኑ እርምጃዎች ውስጥ እንዴት እንደሚሠራ አስቀድመው ማረጋገጥ ይመረጣል. ስለዚህ ጉዳይ በ “ባለሙያ” ክፍል ውስጥ በዝርዝር እንነጋገር ።
• ክትትል እና ማንቂያዎች. አንድ ዘለላ ሲበላሽ ስለእሱ ለማወቅ የመጀመሪያው መሆን ይፈልጋሉ። እዚህ ሁሉም አንጓዎች ስለ ክላስተር ሁኔታ አንድ አይነት መረጃ እንደሚመልሱ በማሳወቂያ እራሳችንን ገድበናል (አዎ፣ በተለየ ሁኔታ ይከሰታል)። እና ሌሎች ችግሮች ከRedis ደንበኛ አገልግሎቶች ማንቂያዎች በበለጠ ፍጥነት ሊታወቁ ይችላሉ።

ማዛወር

እንዴት እንደምንንቀሳቀስ፡-

• በመጀመሪያ ደረጃ ከክላስተር ጋር ለመስራት ቤተ-መጽሐፍት ማዘጋጀት ያስፈልግዎታል. go-redisን ለ Go ስሪት መሰረት አድርገን ለራሳችን እንዲመች ትንሽ ቀይረነዋል። በቧንቧ መስመር በኩል መልቲ-ዘዴዎችን ተግባራዊ እናደርጋለን, እና እንዲሁም ጥያቄዎችን ለመድገም ህጎቹን በትንሹ አስተካክለናል. የPHP ስሪት ብዙ ችግሮች ነበሩት ነገር ግን በመጨረሻ በ php-redis ላይ ተረጋጋን። በቅርቡ የክላስተር ድጋፍን አስተዋውቀዋል እና በእኛ አስተያየት ጥሩ ይመስላል።
• በመቀጠል ክላስተር እራሱን ማሰማራት ያስፈልግዎታል. ይህ በማዋቀሪያው ፋይል ላይ በመመስረት በጥሬው በሁለት ትዕዛዞች ይከናወናል. ቅንብሩን ከዚህ በታች በዝርዝር እንነጋገራለን.
• ቀስ በቀስ ለመንቀሳቀስ ደረቅ ሁነታን እንጠቀማለን. ተመሳሳይ በይነገጽ ያላቸው ሁለት የቤተ-መጻህፍት ስሪቶች ስላሉን (አንዱ ለመደበኛው ስሪት ፣ ሌላኛው ለክላስተር) ፣ ከተለየ ስሪት ጋር አብሮ የሚሰራ እና በትይዩ ሁሉንም ጥያቄዎች ለክላስተር የሚደግም ጥቅል ለመፍጠር ምንም ወጪ አይጠይቅም። ምላሾችን ያወዳድሩ እና ልዩነቶችን በምዝግብ ማስታወሻዎች ውስጥ ይፃፉ (በእኛ በኒውሬሊክ ውስጥ)። ስለዚህ፣ በታቀደው ጊዜ የክላስተር ሥሪት ቢሰበርም፣ ምርታችን አይጎዳም።
• ክላስተርን በደረቅ ሁነታ ካወጣን በኋላ፣ የምላሽ አለመግባባቶችን ግራፍ በእርጋታ መመልከት እንችላለን። የስህተት መጠኑ በዝግታ ግን በእርግጠኝነት ወደ አንዳንድ ትናንሽ ቋሚዎች የሚሄድ ከሆነ ሁሉም ነገር ደህና ነው። ለምን አሁንም ልዩነቶች አሉ? በተለየ ስሪት ውስጥ መቅዳት በክላስተር ውስጥ ትንሽ ቀደም ብሎ ስለሚከሰት እና በማይክሮላግ ምክንያት መረጃው ሊለያይ ይችላል። የቀረው ሁሉ የልዩነት ምዝግብ ማስታወሻዎችን መመልከት ብቻ ነው, እና ሁሉም በመዝገቡ አተያይነት ከተገለጹ, ከዚያ መቀጠል እንችላለን.
• አሁን ደረቅ ሁነታን ወደ ተቃራኒው አቅጣጫ መቀየር ይችላሉ. ከክላስተር እንጽፋለን እና እናነባለን እና ወደ የተለየ እትም እናባዛለን። ለምንድነው? በሚቀጥለው ሳምንት የክላስተርን ስራ መከታተል እፈልጋለሁ። በድንገት በከፍተኛ ጭነት ላይ ችግሮች እንዳሉ ከታወቀ ወይም የሆነ ነገር ግምት ውስጥ ካላስገባን ሁልጊዜም ለደረቅ ሁነታ ምስጋና ይግባው ወደ አሮጌው ኮድ እና የአሁኑ ውሂብ የአደጋ ጊዜ መመለስ አለብን።
• የሚቀረው ደረቅ ሁነታን ማሰናከል እና የተለየውን ስሪት ማፍረስ ነው።

ባለሙያ

በመጀመሪያ ስለ ክላስተር ንድፍ በአጭሩ።

በመጀመሪያ ደረጃ, Redis ቁልፍ እሴት መደብር ነው. የዘፈቀደ ሕብረቁምፊዎች እንደ ቁልፎች ያገለግላሉ። ቁጥሮች፣ ሕብረቁምፊዎች እና ሙሉ መዋቅሮች እንደ እሴት ሊያገለግሉ ይችላሉ። የኋለኞቹ በጣም ብዙ ናቸው፣ ግን አጠቃላይ መዋቅሩን ለመረዳት ይህ ለእኛ አስፈላጊ አይደለም።
ከቁልፎች በኋላ የሚቀጥለው የአብስትራክሽን ደረጃ ክፍተቶች (SLOTS) ናቸው። እያንዳንዱ ቁልፍ ከ16 ቦታዎች የአንዱ ነው። በእያንዳንዱ ማስገቢያ ውስጥ ምንም አይነት ቁልፎች ሊኖሩ ይችላሉ. ስለዚህ, ሁሉም ቁልፎች በ 383 የተከፋፈሉ ስብስቦች ይከፈላሉ.

በመቀጠል በክላስተር ውስጥ N ዋና ኖዶች መኖር አለባቸው። እያንዳንዱ መስቀለኛ መንገድ በክላስተር ውስጥ ስላሉ ሌሎች አንጓዎች ሁሉንም ነገር የሚያውቅ እንደ የተለየ የሬዲስ ምሳሌ ተደርጎ ሊወሰድ ይችላል። እያንዳንዱ ዋና መስቀለኛ መንገድ በርካታ ክፍተቶችን ይይዛል። እያንዳንዱ ማስገቢያ የአንድ ዋና መስቀለኛ መንገድ ብቻ ነው። ሁሉም ክፍተቶች በአንጓዎች መካከል መሰራጨት አለባቸው። አንዳንድ ክፍተቶች ካልተመደቡ በውስጣቸው የተከማቹ ቁልፎች የማይደረስባቸው ይሆናሉ። እያንዳንዱን ዋና ኖድ በተለየ ሎጂካዊ ወይም አካላዊ ማሽን ላይ ማስኬድ ምክንያታዊ ነው። እንዲሁም እያንዳንዱ መስቀለኛ መንገድ በአንድ ኮር ላይ ብቻ እንደሚሠራ ማስታወሱ ጠቃሚ ነው ፣ እና ብዙ የሬዲስ ምሳሌዎችን በተመሳሳይ ሎጂካዊ ማሽን ላይ ማስኬድ ከፈለጉ ፣ በተለያዩ ኮሮች ላይ መሮጣቸውን ያረጋግጡ (ይህን አልሞከርንም ፣ ግን በንድፈ-ሀሳብ ሊሠራ ይገባል) . በመሰረቱ፣ ዋና ኖዶች መደበኛ መጋራትን ይሰጣሉ፣ እና ተጨማሪ ዋና ኖዶች ጥያቄዎችን ለመመዘን መፃፍ እና ማንበብ ያስችላቸዋል።

ሁሉም ቁልፎች በመክተቻዎች መካከል ከተከፋፈሉ በኋላ እና ክፍተቶቹ በዋና ኖዶች መካከል ከተበተኑ በኋላ በእያንዳንዱ ዋና መስቀለኛ መንገድ ላይ የዘፈቀደ ቁጥር ያላቸው የባሪያ ኖዶች ሊጨመሩ ይችላሉ. በእያንዳንዱ እንደዚህ አይነት ጌታ-ባሪያ አገናኝ ውስጥ, መደበኛ ማባዛት ይሰራል. የንባብ ጥያቄዎችን ለመለካት እና ዋና ውድቀት በሚከሰትበት ጊዜ ለውድቀት ባሮች ያስፈልጋሉ።

አሁን ማድረግ መቻል የተሻለ እንደሚሆን ስለ ኦፕሬሽኖች እንነጋገር ።

ስርዓቱን በRedis-CLI በኩል እናገኘዋለን። ሬዲስ አንድ ነጠላ የመግቢያ ነጥብ ስለሌለው በማናቸውም አንጓዎች ላይ የሚከተሉትን ስራዎች ማከናወን ይችላሉ. በእያንዳንዱ ነጥብ ላይ በጭነት ውስጥ ያለውን ቀዶ ጥገና የማከናወን እድል ላይ ትኩረት እሰጣለሁ.

• እኛ የምንፈልገው የመጀመሪያው እና በጣም አስፈላጊው ነገር የክላስተር ኖዶች አሠራር ነው. የክላስተርን ሁኔታ ይመልሳል፣ የአንጓዎችን ዝርዝር፣ ሚናቸውን፣ የቦታ ስርጭት፣ ወዘተ ያሳያል። ተጨማሪ መረጃ የክላስተር መረጃን እና የክላስተር ክፍተቶችን በመጠቀም ማግኘት ይቻላል።
• አንጓዎችን ማከል እና ማስወገድ መቻል ጥሩ ነው። ለዚሁ ዓላማ ክላስተር መገናኘት እና ክላስተር የመርሳት ስራዎች አሉ. እባኮትን ክላስተር መርሳት በእያንዳንዱ መስቀለኛ መንገድ ላይ መተግበር አለበት፣ ሁለቱም ጌቶች እና ቅጂዎች። እና ክላስተር ማሟላት በአንድ መስቀለኛ መንገድ ላይ ብቻ መጠራት አለበት። ይህ ልዩነት ግራ የሚያጋባ ሊሆን ይችላል፣ ስለዚህ በክላስተርዎ በቀጥታ ከመሄድዎ በፊት ስለሱ ማወቅ ጥሩ ነው። መስቀለኛ መንገድ መጨመር በጦርነት ውስጥ ደህንነቱ በተጠበቀ ሁኔታ ይከናወናል እና በምንም መልኩ የክላስተር ስራን አይጎዳውም (ይህም ምክንያታዊ ነው). አንድ መስቀለኛ መንገድ ከጥቅሉ ላይ ለማስወገድ ከፈለጉ በላዩ ላይ ምንም ክፍተቶች እንደሌሉ ማረጋገጥ አለብዎት (አለበለዚያ በዚህ መስቀለኛ መንገድ ላይ ያሉትን ሁሉንም ቁልፎች መዳረሻ ሊያጡ ይችላሉ)። እንዲሁም ባሪያዎች ያለውን ጌታ አይሰርዙት, አለበለዚያ ለአዲስ ጌታ አላስፈላጊ ድምጽ ይከናወናል. መስቀለኛ መንገዶች ከአሁን በኋላ ክፍተቶች ከሌሉ, ይህ ትንሽ ችግር ነው, ነገር ግን መጀመሪያ ባሪያዎቹን መሰረዝ ከቻልን ለምን ተጨማሪ ምርጫዎች እንፈልጋለን.
• የጌታውን እና የባሪያ ቦታዎችን በሃይል መለዋወጥ ካስፈለገዎት የክላስተር አለመሳካት ትዕዛዙ ይሰራል። በጦርነት ውስጥ ሲደውሉ, ጌታው በቀዶ ጥገናው ውስጥ እንደማይገኝ መረዳት ያስፈልግዎታል. በተለምዶ ማብሪያው የሚከሰተው ከአንድ ሰከንድ ባነሰ ጊዜ ውስጥ ነው, ነገር ግን አቶሚክ አይደለም. በዚህ ጊዜ ለጌታው የሚቀርቡ አንዳንድ ጥያቄዎች አይሳኩም ብለው መጠበቅ ይችላሉ።
• አንድ መስቀለኛ መንገድ ከጥቅሉ ውስጥ ከማስወገድዎ በፊት በላዩ ላይ ምንም ክፍተቶች ሊኖሩ አይገባም። የክላስተር ማሻሻያ ትዕዛዝን በመጠቀም እነሱን እንደገና ማሰራጨት የተሻለ ነው። ማስገቢያዎች ከአንድ ጌታ ወደ ሌላ ይተላለፋሉ. አጠቃላይ ክዋኔው ብዙ ደቂቃዎችን ሊወስድ ይችላል። ስለዚህ, ሁሉም መረጃዎች ከአንዱ መስቀለኛ መንገድ ወደ ሌላ በቀጥታ በጭነት ሊተላለፉ ይችላሉ, እና ስለ መገኘቱ ሳይጨነቁ. ሆኖም ፣ ስውር ዘዴዎችም አሉ። በመጀመሪያ፣ የውሂብ ማስተላለፍ በተቀባዩ እና በላኪ አንጓዎች ላይ ካለው የተወሰነ ጭነት ጋር የተያያዘ ነው። የተቀባዩ መስቀለኛ መንገድ በአቀነባባሪው ላይ በጣም ከተጫነ አዲስ ውሂብ በመቀበል መጫን የለብዎትም። በሁለተኛ ደረጃ፣ በላኪው ጌታ ላይ አንድም ማስገቢያ እንደሌለ፣ ሁሉም ባሮቹ ወዲያውኑ እነዚህ ክፍተቶች ወደተተላለፉበት ጌታ ይሄዳሉ። እና ችግሩ እነዚህ ሁሉ ባሪያዎች ውሂብን በአንድ ጊዜ ማመሳሰል ይፈልጋሉ። እና ሙሉ በሙሉ ከማመሳሰል ይልቅ ከፊል ከሆነ እድለኛ ይሆናሉ። ይህንን ግምት ውስጥ ያስገቡ እና ቦታዎችን የማስተላለፍ እና ባሪያዎችን የማሰናከል/የማስተላለፍ ስራዎችን ያጣምሩ። ወይም በቂ የሆነ የደህንነት ህዳግ እንዳለህ ተስፋ አድርግ።
• በዝውውሩ ወቅት፣ ቦታዎችዎን የሆነ ቦታ እንደጠፉ ካወቁ ምን ማድረግ አለብዎት? ይህ ችግር እንደማይነካህ ተስፋ አደርጋለሁ፣ ነገር ግን ካጋጠመ የክላስተር መጠገኛ ስራ አለ። ቢያንስ በነሲብ ቅደም ተከተል ክፍተቶችን በመስቀለኛ መንገዱ ላይ ትበትናለች። በመጀመሪያ መስቀለኛ መንገድን ከተከፋፈሉ ክፍተቶች ጋር በማንሳት ስራውን እንዲፈትሹ እመክራለሁ. ያልተመደቡ ቦታዎች ውስጥ ያለው ውሂብ አስቀድሞ አይገኝም በመሆኑ, እነዚህ ቦታዎች መገኘት ጋር ችግሮች መጨነቅ በጣም ዘግይቷል. በምላሹ, ክዋኔው የተከፋፈሉ ክፍተቶችን አይጎዳውም.
• ሌላው ጠቃሚ ተግባር ሞኒተር ነው. ወደ መስቀለኛ መንገድ የሚሄዱትን አጠቃላይ የጥያቄዎች ዝርዝር በቅጽበት እንዲያዩ ያስችልዎታል። ከዚህም በላይ, እሱን grep እና አስፈላጊው ትራፊክ መኖሩን ማወቅ ይችላሉ.

እንዲሁም ዋናውን አለመሳካት ሂደት መጥቀስ ተገቢ ነው. በአጭሩ, አለ, እና, በእኔ አስተያየት, በጣም ጥሩ ይሰራል. ነገር ግን የኃይል ገመዱን በማሽን ላይ ከዋናው መስቀለኛ መንገድ ከለቀሉት ሬዲስ ወዲያውኑ ይለዋወጣል እና ደንበኞች ኪሳራውን አያስተውሉም ብለው አያስቡ። በእኔ ልምምድ, መቀየር በጥቂት ሰከንዶች ውስጥ ይከሰታል. በዚህ ጊዜ፣ አንዳንድ መረጃዎች አይገኙም፡ የጌታው አለመገኘት ታይቷል፣ አንጓዎች ለአዲስ ድምጽ ይሰጣሉ፣ ባሪያዎች ተቀይረዋል፣ ውሂብ ይመሳሰላል። እቅዱ እየሰራ መሆኑን ለራስዎ ለማረጋገጥ በጣም ጥሩው መንገድ የአካባቢ ልምምዶችን ማካሄድ ነው። ክላስተርዎን በላፕቶፕዎ ላይ ያሳድጉ፣ አነስተኛ ጭነት ይስጡት፣ ብልሽትን ያስመስሉ (ለምሳሌ ወደቦችን በመዝጋት) እና የመቀየሪያውን ፍጥነት ይገምግሙ። በእኔ አስተያየት, በዚህ መንገድ ለአንድ ወይም ለሁለት ቀን ከተጫወቱ በኋላ ብቻ በቴክኖሎጂው አሠራር ላይ በራስ መተማመን ይችላሉ. ደህና ፣ ወይም የበይነመረብ ግማሹ የሚጠቀመው ሶፍትዌር ምናልባት እንደሚሰራ ተስፋ ያድርጉ።

ውቅር

ብዙውን ጊዜ አወቃቀሩ ከመሳሪያው ጋር መስራት ለመጀመር የመጀመሪያው ነገር ነው, እና ሁሉም ነገር ሲሰራ, ውቅሩን መንካት እንኳን አይፈልጉም. ወደ ቅንጅቶቹ ለመመለስ እና በጥንቃቄ ለማለፍ እራስዎን ለማስገደድ የተወሰነ ጥረት ይጠይቃል። በእኔ ትውስታ፣ ለቅንጅቱ ትኩረት ባለመስጠት ቢያንስ ሁለት ከባድ ውድቀቶች አጋጥመውናል። ለሚከተሉት ነጥቦች ልዩ ትኩረት ይስጡ.

• የእረፍት ጊዜ 0
  የቦዘኑ ግንኙነቶች የሚዘጉበት ጊዜ (በሴኮንዶች)። 0 - አይዝጉ
  የእኛ እያንዳንዱ ቤተ-መጽሐፍት ግንኙነቶችን በትክክል መዝጋት አልቻለም። ይህን ቅንብር በማሰናከል፣ በደንበኞች ብዛት ላይ ያለውን ገደብ የመምታት አደጋ አለን። በሌላ በኩል ፣ እንደዚህ አይነት ችግር ካለ ፣ የጠፉ ግንኙነቶችን በራስ-ሰር ማቋረጥ ይሸፍኑታል ፣ እና እኛ ላናስተውል ይችላል። በተጨማሪም፣ ቋሚ ግንኙነቶችን ሲጠቀሙ ይህን ቅንብር ማንቃት የለብዎትም።
• xy አስቀምጥ እና ተጨማሪ አዎ
  የRDB ቅጽበታዊ ገጽ እይታን በማስቀመጥ ላይ።
  ከዚህ በታች ስለ RDB/AOF ጉዳዮች በዝርዝር እንነጋገራለን ።
• stop-writes-on-bgsave-ስህተት የለም & ባሪያ-ማገልገል-የቆየ-ውሂብ አዎ
  ከነቃ፣ የ RDB ቅጽበተ-ፎቶ ከተሰበረ፣ ጌታው የለውጥ ጥያቄዎችን መቀበል ያቆማል። ከጌታው ጋር ያለው ግንኙነት ከጠፋ, ባሪያው ለጥያቄዎች ምላሽ መስጠቱን መቀጠል ይችላል (አዎ). ወይም ምላሽ መስጠት ያቆማል (አይ)
  ሬዲስ ወደ ዱባነት በሚቀየርበት ሁኔታ ደስተኛ አይደለንም.
• የመልሶ-ፒንግ-ባሪያ-ጊዜ 5
  ከዚህ ጊዜ በኋላ, ጌታው ተበላሽቷል ብለን መጨነቅ እንጀምራለን እና የውድቀት ሂደቱን ለማከናወን ጊዜው አሁን ነው.
  በውሸት አወንታዊ እና ውድቀትን በማነሳሳት መካከል ያለውን ሚዛን በእጅ መፈለግ አለቦት። በእኛ ልምምድ ይህ 5 ሰከንድ ነው.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  ላልተሳካ ቅጂ ይህን ያህል ውሂብ በመጠባበቂያ ውስጥ ማከማቸት እንችላለን። ማስቀመጫው ካለቀ፣ ሙሉ ለሙሉ ማመሳሰል ይኖርብዎታል።
  ልምምድ እንደሚያሳየው ከፍ ያለ ዋጋ ማዘጋጀት የተሻለ ነው. አንድ ቅጂ ማዘግየት ሊጀምር የሚችልባቸው ብዙ ምክንያቶች አሉ። የሚዘገይ ከሆነ፣ ምናልባት ጌታህ ቀድሞውንም ለመቋቋም እየታገለ ነው፣ እና ሙሉ ማመሳሰል የመጨረሻው ገለባ ይሆናል።
• ከፍተኛ ደንበኞች 10000
  ከፍተኛው የአንድ ጊዜ ደንበኞች ብዛት።
  በእኛ ልምድ, ከፍ ያለ ዋጋ ማዘጋጀት የተሻለ ነው. ሬዲስ 10k ግንኙነቶችን በትክክል ያስተናግዳል። በስርዓቱ ላይ በቂ ሶኬቶች መኖራቸውን ያረጋግጡ.
• maxmemory-policy volatile-ttl
  ያለው የማህደረ ትውስታ ገደብ ሲደረስ ቁልፎች የሚሰረዙበት ህግ።
  እዚህ አስፈላጊው ነገር ራሱ ደንብ አይደለም, ነገር ግን ይህ እንዴት እንደሚሆን መረዳት ነው. Redis የማህደረ ትውስታ ገደቡ ላይ ሲደርስ በመደበኛነት የመሥራት ችሎታ ስላለው ሊመሰገን ይችላል።

RDB እና AOF ችግሮች

ምንም እንኳን ሬዲስ ራሱ ሁሉንም መረጃዎች በ RAM ውስጥ ቢያከማችም መረጃን ወደ ዲስክ ለማስቀመጥ የሚያስችል ዘዴም አለ ። ይበልጥ በትክክል ፣ ሶስት ዘዴዎች-

• RDB-snapshot - የሁሉም ውሂብ ሙሉ ቅጽበታዊ ገጽ እይታ። የ SAVE XY አወቃቀሩን በመጠቀም ያቀናብሩ እና "ቢያንስ Y ቁልፎች ከተቀየሩ በየ X ሰከንድ የሁሉም ውሂብ ሙሉ ቅጽበታዊ አስቀምጥ" የሚለውን ያንብቡ።
• አባሪ-ብቻ ፋይል - በተከናወኑት ቅደም ተከተሎች ውስጥ የክዋኔዎች ዝርዝር. በየ X ሰከንድ ወይም በየY ኦፕሬሽኖች አዳዲስ ገቢ ስራዎችን ወደ ፋይሉ ያክላል።
• RDB እና AOF የቀደሙት ሁለት ጥምር ናቸው።

ሁሉም ዘዴዎች ጥቅሞቻቸው እና ጉዳቶቻቸው አሏቸው, ሁሉንም አልዘረዝርም, በእኔ አስተያየት, ግልጽ ያልሆኑትን ነጥቦች ብቻ ትኩረት እሰጣለሁ.

በመጀመሪያ፣ የRDB ቅጽበተ-ፎቶ ማስቀመጥ FORK መደወልን ይጠይቃል። ብዙ ውሂብ ካለ፣ ይሄ ሁሉንም ሬዲስ ከጥቂት ሚሊሰከንዶች እስከ ሰከንድ ድረስ ሊሰቅለው ይችላል። በተጨማሪም ፣ ስርዓቱ ለእንደዚህ ዓይነቱ ቅጽበታዊ ገጽ እይታ ማህደረ ትውስታን መመደብ አለበት ፣ ይህም በሎጂካዊ ማሽን ላይ ራም ድርብ አቅርቦት እንዲኖር ያስፈልጋል ። 8 ጂቢ ለሬዲስ ከተመደበ 16 ጊባ በቨርቹዋል ማሽን ላይ መገኘት አለበት ። ነው።

በሁለተኛ ደረጃ, በከፊል ማመሳሰል ላይ ችግሮች አሉ. በ AOF ሁነታ, ባሪያው እንደገና ሲገናኝ, ከፊል ማመሳሰል ይልቅ, ሙሉ ማመሳሰል ሊከናወን ይችላል. ይህ ለምን ይከሰታል, ሊገባኝ አልቻለም. ግን ይህንን ማስታወስ ጠቃሚ ነው.

እነዚህ ሁለት ነጥቦች ሁሉም ነገር አስቀድሞ በባሪያዎች የተባዛ ከሆነ ይህ ውሂብ በዲስክ ላይ በእርግጥ እንደሚያስፈልገን እንድናስብ ያደርጉናል. መረጃ ሊጠፋ የሚችለው ሁሉም ባሪያዎች ካልተሳኩ ብቻ ነው, እና ይህ "በዲሲ ውስጥ ያለው እሳት" ደረጃ ችግር ነው. እንደ ስምምነት ፣ መረጃን በባሮች ላይ ብቻ ለማስቀመጥ ሀሳብ ማቅረብ ይችላሉ ፣ ግን በዚህ ሁኔታ እነዚህ ባሪያዎች በአደጋ ጊዜ በማገገም ጊዜ ጌታ እንደማይሆኑ ማረጋገጥ ያስፈልግዎታል (ለዚህ በነሱ ውቅር ውስጥ የባሪያ ቅድሚያ አቀማመጥ አለ)። ለራሳችን, በእያንዳንዱ የተለየ ጉዳይ ላይ መረጃን ወደ ዲስክ ማስቀመጥ አስፈላጊ ስለመሆኑ እናስባለን, እና አብዛኛውን ጊዜ መልሱ "አይ" ነው.

መደምደሚያ

በማጠቃለያው ፣ ስለ እሱ በጭራሽ ላልሰሙት ሰዎች ሪዲስ-ክላስተር እንዴት እንደሚሰራ አጠቃላይ ሀሳብ መስጠት እንደቻልኩ እና እንዲሁም ሲጠቀሙበት ለነበሩት አንዳንድ ግልጽ ያልሆኑ ነጥቦችን ትኩረት እንዳደርግ ተስፋ አደርጋለሁ ። ለረጅም ግዜ.
ለጊዜዎ እናመሰግናለን እና እንደ ሁልጊዜው, በርዕሱ ላይ አስተያየቶች እንኳን ደህና መጡ.

ምንጭ: hab.com