Redis በመጠቀም የተከፋፈሉ መቆለፊያዎች

ሃይ ሀብር!

ዛሬ Redis ን በመጠቀም የተከፋፈሉ መቆለፊያዎችን በመተግበር ላይ ያለውን ውስብስብ ጽሑፍ ወደ እርስዎ ትኩረት እናመጣለን እና ስለ ሬዲስ ተስፋዎች እንደ አርእስት ለመነጋገር እንመክራለን። የመጽሐፉ ደራሲ ማርቲን ክሌፕማን የታሰበው የ Redlock ስልተ ቀመር ትንተናከፍተኛ ጭነት መተግበሪያዎች", የተሰጠው ነው እዚህ.

የተከፋፈሉ መቆለፊያዎች የተለያዩ ሂደቶች በጋራ መገልገያዎች ላይ እርስ በርስ በሚጣጣም መልኩ መስራት በሚፈልጉባቸው ብዙ አካባቢዎች ውስጥ ጥቅም ላይ የሚውሉ በጣም ጠቃሚ ጥንታዊ ናቸው.

DLM (Distributed Lock Manager) በሬዲስ እንዴት መተግበር እንደሚቻል የሚገልጹ በርከት ያሉ ቤተ-መጻሕፍት እና ልጥፎች አሉ፣ ነገር ግን እያንዳንዱ ቤተ-መጽሐፍት የተለየ አካሄድ ስለሚወስድ የሚሰጠው ዋስትና ትንሽ ውስብስብ በሆነ ንድፍ ሊደረስበት ከሚችለው ጋር ሲወዳደር ደካማ ነው።

በዚህ ጽሑፍ ውስጥ የተከፋፈለ መቆለፊያን በሬዲስ እንዴት መተግበር እንደሚቻል የሚያሳይ ሁኔታዊ ቀኖናዊ ስልተ-ቀመርን ለመግለጽ እንሞክራለን። ስለ አንድ ስልተ ቀመር እንነጋገራለን ዳግም መቆለፊያ, የተከፋፈለ የመቆለፊያ አስተዳዳሪን ይተገብራል እና, በእኛ አስተያየት, ይህ ስልተ ቀመር ከአንድ ነጠላ ምሳሌ ጋር ከተለመደው አሰራር የበለጠ ደህንነቱ የተጠበቀ ነው. ህብረተሰቡ ተንትኖ፣ አስተያየት በመስጠት እና ለተወሳሰቡ ወይም አማራጭ ፕሮጀክቶች ትግበራ እንደ መነሻ ይጠቀምበታል ብለን ተስፋ እናደርጋለን።

ትግበራ

ወደ አልጎሪዝም ገለጻ ከመቀጠልዎ በፊት, ዝግጁ ለሆኑ አተገባበር ብዙ አገናኞችን እንሰጣለን. ለማጣቀሻነት ጥቅም ላይ ሊውሉ ይችላሉ.

• redlock-rb (ለ Ruby ትግበራ). እንዲሁም አለ። ሹካ ለስርጭት ቀላልነት ጥቅል (ጌም) የሚጨምር Redlock-rb እና ሌሎችም።
• redlock-py (ለ Python ትግበራ).
• አዮሬድሎክ (ለ Asyncio Python ትግበራ).
• redlock-php (ለ PHP ትግበራ).
• PHPRedisMutex (ለ PHP ሌላ ትግበራ)
• cheprasov / php-redis-መቆለፊያ (PHP ቤተ-መጽሐፍት ለቁልፍ)
• ቀይ ማመሳሰል (ለ Go ትግበራ)።
• ራዲሰን (ለጃቫ ትግበራ)።
• Redis :: DistLock (ለፐርል መተግበር).
• redlock-cpp (ለ C ++ ትግበራ).
• redlock-cs (ለ C #/.NET ትግበራ).
• RedLock.net (ለ C #/.NET ትግበራ). ለአስመር እና ለመቆለፊያ ቅጥያዎች ድጋፍ።
• ቀይ መቆለፊያ (ለC# .NET ትግበራ ከተዋቀረ የውሂብ ማከማቻ ጋር)
• Redlock4Net (ለ C# .NET ትግበራ)
• መስቀለኛ ቀይ መቆለፊያ (ለ NodeJS ትግበራ). ለመቆለፊያ ማራዘሚያዎች ድጋፍን ያካትታል።

የደህንነት እና ተገኝነት ዋስትናዎች

የተከፋፈሉ መቆለፊያዎችን በብቃት ለመጠቀም የሚያስፈልጉትን አነስተኛ ዋስትናዎች ይሰጣሉ ብለን ከምናስበው ሶስት ንብረቶች ጋር ፕሮጀክታችንን እንቀርፃለን።

1. የደህንነት ንብረት፡ የጋራ መገለል። በማንኛውም ጊዜ አንድ ደንበኛ ብቻ መቆለፊያን ይይዛል።
2. የተደራሽነት ንብረት ሀ፡ ምንም መቆለፊያዎች የሉም። ሀብቱን የያዘው ደንበኛ ባይሳካም ወይም የተለየ የዲስክ ክፍል ቢመታ ሁልጊዜም በመጨረሻ መቆለፊያ ማግኘት ትችላለህ።
3. የተገኝነት ንብረት ለ፡ ስህተት መቻቻል። አብዛኛዎቹ Redis nodes እየሰሩ እስከሆኑ ድረስ ደንበኞች መቆለፊያዎችን ማግኘት እና መልቀቅ ይችላሉ።

ለምን በዚህ ጉዳይ ላይ ያልተሳካ ትግበራ በቂ አይደለም
ምን እንደምናሻሽል ለመረዳት በሬዲስ ላይ በመመስረት በአብዛኛዎቹ ቤተ-መጻሕፍት የተዘጋጀውን ወቅታዊ ሁኔታ እንመርምር።

Redisን በመጠቀም ሀብትን ለመቆለፍ ቀላሉ መንገድ በምሳሌው ውስጥ ቁልፍ መፍጠር ነው። ብዙውን ጊዜ ቁልፉ የሚፈጠረው ከተገደበ የህይወት ዘመን ጋር ነው፣ ይህ የሚገኘው በሬዲስ ውስጥ ያለውን የአገልግሎት ማብቂያ ባህሪ በመጠቀም ነው፣ ስለዚህ ይዋል ይደር ይህ ቁልፍ ይለቀቃል (በእኛ ዝርዝር ውስጥ 2 ንብረት)። አንድ ደንበኛ ሃብት መልቀቅ ሲፈልግ ቁልፉን ይሰርዛል።

በቅድመ-እይታ, ይህ መፍትሄ የሚሰራ ይመስላል, ግን ችግር አለ-የእኛ አርክቴክቸር አንድ ነጠላ የውድቀት ነጥብ አለው. የሊድ ሬዲስ ምሳሌ ካልተሳካ ምን ይከሰታል? እንግዲህ ተከታይ እንጨምር! እና አስተናጋጁ ከሌለ እንጠቀማለን. እንደ አለመታደል ሆኖ ይህ አማራጭ ተግባራዊ ሊሆን አይችልም። ይህን በማድረግ ለደህንነት ሲባል የምንፈልገውን የጋራ መገለል ንብረት በትክክል መተግበር አንችልም ምክንያቱም በሬዲስ ውስጥ ማባዛት አይመሳሰልም።

በግልጽ እንደሚታየው ፣ የዘር ሁኔታ በእንደዚህ ዓይነት ሞዴል ውስጥ ይከሰታል

1. ደንበኛ ሀ በጌታው ላይ መቆለፊያ ያገኛል።
2. ወደ ቁልፉ መፃፍ ወደ ባሪያው ከመተላለፉ በፊት ጌታው አልተሳካም.
3. ተከታይ ወደ መሪነት ከፍ ብሏል።
4. ደንበኛ B አስቀድሞ በኤ የተቆለፈውን በተመሳሳይ ግብአት ላይ መቆለፊያ ያገኛል። የደህንነት ጥሰት!

አንዳንድ ጊዜ እንደ አለመሳካት ባሉ ልዩ ሁኔታዎች ውስጥ ብዙ ደንበኞች በተመሳሳይ ጊዜ መቆለፊያን ሊይዙ መቻላቸው በጣም የተለመደ ነው። በእንደዚህ ዓይነት ሁኔታዎች, በማባዛት ላይ የተመሰረተ መፍትሄ ሊተገበር ይችላል. አለበለዚያ በዚህ ጽሑፍ ውስጥ የተገለጸውን መፍትሄ እንመክራለን.

በአንድ ምሳሌ ትክክለኛ አተገባበር

ከላይ የተገለጸውን የነጠላ ምሳሌ ውቅር ድክመቶችን ለማሸነፍ ከመሞከርዎ በፊት ፣ ይህንን ቀላል ጉዳይ እንዴት በትክክል መያዝ እንደሚቻል እንይ ፣ ምክንያቱም እንዲህ ዓይነቱ መፍትሄ በእውነቱ የውድድር ሁኔታ ከጊዜ ወደ ጊዜ ተቀባይነት በሚሰጥባቸው መተግበሪያዎች ውስጥ ተቀባይነት ያለው ስለሆነ እና እንዲሁም ስለ ማገድ ነው። አንድ ነጠላ ምሳሌ እዚህ በተገለጸው በተከፋፈለው ስልተ ቀመር ውስጥ ጥቅም ላይ የሚውል መሠረት ሆኖ ያገለግላል።

መቆለፊያ ለማግኘት የሚከተሉትን ያድርጉ

SET resource_name my_random_value NX PX 30000

ይህ ትእዛዝ ቁልፉን የሚያዘጋጀው አስቀድሞ ከሌለ ብቻ ነው (አማራጭ NX)፣ የሚቆይበት ጊዜ 30000 ሚሊሰከንዶች (አማራጭ PX)። ቁልፉ ተቀናብሯል ወደ "myrandomvalue". ይህ ዋጋ በሁሉም ደንበኞች እና በሁሉም የመቆለፊያ ጥያቄዎች ላይ ልዩ መሆን አለበት።
በመሠረቱ፣ የዘፈቀደ እሴት መቆለፊያውን ደህንነቱ በተጠበቀ ሁኔታ ለመልቀቅ ጥቅም ላይ ይውላል፣ ስክሪፕቱ Redis ቁልፉን ካለ ብቻ እንዲሰርዝ ይነግረዋል፣ እና በውስጡ የተቀመጠው እሴት በትክክል የሚጠበቀው ነው። ይህ በሚከተለው የሉአ ስክሪፕት የተገኘ ነው።

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

በሌላ ደንበኛ የሚወሰድ መቆለፊያ እንዳይለቀቅ ለመከላከል ይህ አስፈላጊ ነው። ለምሳሌ፣ አንድ ደንበኛ መቆለፊያ ይይዛል፣ከዚያም ከመጀመሪያው መቆለፊያ በላይ የሚቆይ አንዳንድ ስራዎችን መቆለፍ (ቁልፉ ጊዜው የሚያበቃበት ጊዜ እንዲኖረው) እና በኋላ ሌላ ደንበኛ የያዘውን መቆለፊያ ያስወግዳል።
ደንበኛው በሌላ ደንበኛ የተያዘውን መቆለፊያ ሊለቅ ስለሚችል ቀላል DEL መጠቀም ደህንነቱ የተጠበቀ ነው። በተቃራኒው, ከላይ ያለውን ስክሪፕት ሲጠቀሙ, እያንዳንዱ መቆለፊያ በዘፈቀደ ሕብረቁምፊ "የተፈረመ" ነው, ስለዚህ ቀደም ሲል ያስቀመጠው ደንበኛ ብቻ ነው ማስወገድ የሚችለው.

ይህ የዘፈቀደ ሕብረቁምፊ ምን መሆን አለበት? ከ/dev/urandom 20 ባይት መሆን አለበት ብዬ እገምታለሁ፣ ነገር ግን ገመዱን ለእርስዎ ዓላማዎች በበቂ ሁኔታ ልዩ ለማድረግ ብዙ ወጪ የማይጠይቁ መንገዶች አሉ። ለምሳሌ፣ RC4ን ወደ /dev/urandom መዝራት እና በእሱ ላይ የተመሰረተ የውሸት-የዘፈቀደ ዥረት ማመንጨት ጥሩ ይሆናል። ቀለል ያለ መፍትሔ በማይክሮ ሰከንድ ጥራት እና የደንበኛ መታወቂያ ውስጥ የዩኒክስ ጊዜ ጥምረት ያካትታል; ደህንነቱ የተጠበቀ አይደለም፣ ግን በአብዛኛዎቹ ሁኔታዎች እስከ የተግባር ደረጃ ድረስ ነው ሊባል ይችላል።

ለቁልፍ የህይወት ዘመን መለኪያ የምንጠቀምበት ጊዜ "Lock Validity" ይባላል። ይህ ዋጋ ሁለቱም መቆለፊያው በራስ-ሰር የሚለቀቅበት ጊዜ እና ደንበኛ ሌላ ደንበኛ በምላሹ የጋራ መገለልን ዋስትና ሳይጥስ ሀብቱን ከመቆለፉ በፊት ኦፕሬሽኑን የሚፈጽምበት ጊዜ ነው። ይህ ዋስትና ለተወሰነ ጊዜ ብቻ የተገደበ ነው, ይህም መቆለፊያው ከተገዛበት ጊዜ ጀምሮ ይጀምራል.

ስለዚህ መቆለፊያ ለማግኘት እና ለመልቀቅ ጥሩ መንገድ ተወያይተናል። ስርዓቱ (አንድ እና ሁልጊዜ የሚገኝ ምሳሌን ያካተተ ያልተከፋፈለ ስርዓት እየተነጋገርን ከሆነ) ደህንነቱ የተጠበቀ ነው። ይህንን ፅንሰ-ሀሳብ እንደዚህ አይነት ዋስትናዎች ወደሌለንበት የተከፋፈለ ስርዓት እናራዝመው።

አልጎሪዝምን እንደገና መቆለፍ

የተሰራጨው የአልጎሪዝም ስሪት N መሪ Redis እንዳለን ይገምታል። እነዚህ አንጓዎች አንዳቸው ከሌላው ሙሉ በሙሉ ነፃ ናቸው፣ ስለዚህ ማባዛትን ወይም ሌላ ማንኛውንም ስውር የማስተባበር ስርዓት አንጠቀምም። በአንድ ምሳሌ ላይ መቆለፊያን እንዴት ደህንነቱ በተጠበቀ ሁኔታ ማግኘት እና መልቀቅ እንደሚቻል አስቀድመን ሸፍነናል። ከአንድ ነጠላ ምሳሌ ጋር ሲሰራ ስልተ ቀመር ይህንን ዘዴ እንደሚጠቀም እንደ እውነቱ እንወስዳለን. በምሳሌዎቻችን ውስጥ N ወደ 5 እናስቀምጣለን, ይህም ፍጹም ምክንያታዊ እሴት ነው. እንደዚሁ 5 ሬዲስ ማስተርስ በተለያዩ ማሽኖች ወይም ቨርችዋል ማሽኖች ላይ እርስ በርስ በተናጥል እንዲሠሩ ማድረግ አለብን።

መቆለፊያ ለማግኘት ደንበኛው የሚከተሉትን ተግባራት ያከናውናል:

1. የአሁኑን ጊዜ በሚሊሰከንዶች ያገኛል።
2. በቅደም ተከተል በሁሉም የ N ጉዳዮች ላይ ተመሳሳይ ቁልፍ ስም እና የዘፈቀደ እሴቶችን በመጠቀም በሁሉም የ N አጋጣሚዎች ላይ መቆለፊያ ለማግኘት ይሞክራል። በደረጃ 2 ላይ መቆለፊያን በመደበኛነት ሲመሰርቱ ደንበኛው መቆለፊያውን ለማግኘት መዘግየትን ይጠቀማል, ይህም መቆለፊያው በራስ-ሰር ከተለቀቀበት ጊዜ ጋር ሲነፃፀር በጣም አጭር ነው. ለምሳሌ የማገጃው ጊዜ 10 ሰከንድ ከሆነ, መዘግየቱ በ ~ 5-50 ሚሊሰከንዶች ውስጥ ሊሆን ይችላል. ይህ ያልተሳካው Redis node ለመድረስ በመሞከር ደንበኛው ለረጅም ጊዜ ታግዶ የሚቆይበትን ሁኔታ ያስወግዳል: ምሳሌው ከሌለ, ከዚያም በተቻለ ፍጥነት ከሌላ ምሳሌ ጋር ለመገናኘት እንሞክራለን.
3. መቆለፊያ ለመውሰድ ደንበኛው ምን ያህል ጊዜ እንዳለፈ ያሰላል; ይህንን ለማድረግ በደረጃ 1 የተገኘውን የጊዜ ማህተም አሁን ካለው የጊዜ እሴት ይቀንሳል። ደንበኛው በአብዛኛዎቹ አጋጣሚዎች መቆለፊያውን (ቢያንስ 3) ማግኘት ከቻለ እና የወሰደውን አጠቃላይ ጊዜ ለማግኘት ከቻለ ብቻ ነው። መቆለፊያ, ከመቆለፊያው ጊዜ ያነሰ, የመቆለፊያው ግዢ እንደተፈጸመ ይቆጠራል.
4. መቆለፊያ ከተገኘ፣ በደረጃ 3 ላይ የተሰላውን ያለፈውን ጊዜ ሲቀንስ የመቆለፊያው ቆይታ የመጀመሪያ ዋጋ እንደ መቆለፊያው ጊዜ ይወሰዳል።
5. ደንበኛው በሆነ ምክንያት መቆለፊያን ማግኘት ካልቻለ (ወይ N/2+1 አጋጣሚዎችን መቆለፍ ካልቻለ ወይም የመቆለፊያ ቆይታው አሉታዊ ሆኖ ከተገኘ) ሁሉንም አጋጣሚዎች ለመክፈት ይሞክራል (ምንም እንኳን እነዚያን ፣ እንደ ይታሰብ ነበር, ማገድ አይችልም).

አልጎሪዝም አልተመሳሰለም?

ይህ ስልተ-ቀመር የተመሰረተው ሁሉም ሂደቶች እንዲሰሩ የተመሳሰለ ሰዓት ባይኖርም በእያንዳንዱ ሂደት ውስጥ ያለው የአካባቢ ሰዓት አሁንም በተመሳሳይ ፍጥነት ይፈስሳል, እና ስህተቱ ከተቆለፈበት ጠቅላላ ጊዜ ጋር ሲነጻጸር አነስተኛ ነው. በራስ-ሰር ይለቀቃል. ይህ ግምት በተራ ኮምፒውተሮች ውስጥ ካለው ሁኔታ ጋር በጣም ተመሳሳይ ነው-እያንዳንዱ ኮምፒዩተር የአካባቢ ሰዓት አለው, እና አብዛኛውን ጊዜ በኮምፒዩተሮች መካከል ያለው የጊዜ ልዩነት ትንሽ ነው ብለን መጠበቅ እንችላለን.

በዚህ ነጥብ ላይ ስለእርስ በርስ መገለል ሕጋችን የበለጠ ግልጽ መሆን አለብን፡ እርስ በርስ መገለል የሚረጋገጠው ደንበኛው መቆለፊያው በተረጋገጠበት ጊዜ (ይህ ዋጋ በደረጃ 3 ላይ የተገኘ ነው) ከወጣ ብቻ ነው, የተወሰነ ተጨማሪ ጊዜ ሲቀንስ ብቻ ነው. (በአጠቃላይ በሂደቶች መካከል ያለውን የጊዜ መዘግየት ለማካካስ ጥቂት ሚሊሰከንዶች)።

የሚከተለው አስደሳች መጣጥፍ የጊዜ ልዩነትን ማስተባበር ስለሚያስፈልጋቸው ስርዓቶች የበለጠ ይናገራል የሊዝ ውል፡ ለተከፋፈለ የፋይል መሸጎጫ ወጥነት ቀልጣፋ ስህተትን የሚቋቋም ዘዴ.

ውድቀት ላይ እንደገና ይሞክሩ

አንድ ደንበኛ መቆለፊያ ማግኘት ሲያቅተው በዘፈቀደ መዘግየት በኋላ እንደገና መሞከር አለበት፤ ይህ የሚደረገው በተመሳሳይ ሃብት ላይ በተመሳሳይ ጊዜ መቆለፊያ ለማግኘት የሚሞክሩ ብዙ ደንበኞች እንዳይመሳሰሉ ለማድረግ ነው (ይህም አሸናፊዎች ወደሌሉበት "የተከፋፈለ-አንጎል" ሁኔታን ያስከትላል)። እንዲሁም፣ ደንበኛው በአብዛኛዎቹ የሬዲስ አጋጣሚዎች ላይ መቆለፊያ ለማግኘት በፍጥነት በሚሞክር መጠን፣ የአዕምሮ ሁኔታ የሚፈጠርበት መስኮት እየጠበበ ይሄዳል (እና እንደገና የመሞከር ፍላጎት ይቀንሳል)። ስለዚህ፣ በሐሳብ ደረጃ፣ ደንበኛው ማባዛትን በመጠቀም የSET ትዕዛዞችን ወደ N አጋጣሚዎች ለመላክ በአንድ ጊዜ መሞከር አለበት።

እዚህ ላይ አፅንዖት መስጠት ተገቢ ነው ብዙ ቁልፎችን ማግኘት ያልቻሉ ደንበኞች መቆለፊያዎች (በከፊል) ያገኙትን ቁልፍ በማግኘታቸው በሀብቱ ላይ ያለው መቆለፊያ እንደገና ከመግዛቱ በፊት ቁልፍ እስኪያበቃ ድረስ መጠበቅ አይኖርባቸውም (ምንም እንኳን ኔትወርክ ከሆነ) መከፋፈል ይከሰታል , እና ደንበኛው ከ Redis አጋጣሚዎች ጋር ያለውን ግንኙነት ያጣል, ከዚያ ቁልፉ ጊዜው እስኪያልፍ ድረስ በመጠባበቅ ላይ እያለ የተገኝነት ጥሰት ቅጣት መክፈል አለብዎት).

መልቀቅን ቆልፍ

መቆለፊያን መልቀቅ ደንበኛው አንድን የተወሰነ ምሳሌ በተሳካ ሁኔታ መቆለፍ ቢችልም ባይመስልም ሁሉንም አጋጣሚዎች እንዲከፍቱ የሚፈልግ ቀላል ክወና ነው።

የደህንነት ግምት

አልጎሪዝም ደህንነቱ የተጠበቀ ነው? በተለያዩ ሁኔታዎች ውስጥ ምን እንደሚፈጠር ለመገመት እንሞክር.

በመጀመሪያ፣ ደንበኛው በአብዛኛዎቹ አጋጣሚዎች መቆለፊያ ማግኘት እንደቻለ እናስብ። እያንዳንዱ አጋጣሚዎች ለሁሉም ተመሳሳይ የህይወት ዘመን ያለው ቁልፍ ይይዛሉ። ነገር ግን እያንዳንዳቸው እነዚህ ቁልፎች በራሳቸው ጊዜ ተጭነዋል, ስለዚህ በተለያየ ጊዜ ውስጥ የአገልግሎት ጊዜው ያበቃል. ግን የመጀመሪያው ቁልፍ ከ T1 በባሰ ጊዜ ከተዘጋጀ (የመጀመሪያውን አገልጋይ ከማግኘታችን በፊት የምንመርጠው ጊዜ) እና የመጨረሻው ቁልፍ ከ T2 በባሰ ጊዜ ተዘጋጅቷል (ከመጨረሻው ምላሽ የተሰጠበት ጊዜ) አገልጋይ ተቀብሏል)፣ ከዚያ በስብስቡ ውስጥ ያለው የመጀመሪያው ቁልፍ ጊዜው የሚያልፍበት ቢያንስ እንደሚቆይ እርግጠኛ ነን MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. ሁሉም ሌሎች ቁልፎች በኋላ ጊዜያቸው ያበቃል፣ ስለዚህ ሁሉም ቁልፎች ቢያንስ ለዚህ ጊዜ በተመሳሳይ ጊዜ የሚሰሩ መሆናቸውን እርግጠኞች መሆን እንችላለን።

አብዛኛዎቹ ቁልፎች ልክ እንደሆኑ በሚቆዩበት ጊዜ፣ N/2+1 SET NX ክወናዎች የ N/2+1 ቁልፎች ካሉ ሊሳካ ስለማይችል ሌላ ደንበኛ መቆለፊያውን ማግኘት አይችልም። ስለዚህ, አንዴ መቆለፊያ ከተገኘ, በተመሳሳይ ጊዜ እንደገና ማግኘት አይቻልም (ይህ የጋራ መገለል ንብረትን ይጥሳል).
ሆኖም፣ በተመሳሳይ ጊዜ መቆለፊያ ለማግኘት የሚሞክሩ ብዙ ደንበኞች በተመሳሳይ ጊዜ ሊሳካላቸው እንደማይችል ማረጋገጥ እንፈልጋለን።

ደንበኛው አብዛኛዎቹን አጋጣሚዎች ከከፍተኛው የመቆለፊያ ቆይታ ጊዜ በላይ ወይም ከዚያ በላይ ከቆለፈው፣ መቆለፊያውን ያበላሸዋል እና አጋጣሚዎችን ይከፍታል። ስለዚህ, ደንበኛው ከቆይታ ጊዜ ባነሰ ጊዜ ውስጥ አብዛኛዎቹን አጋጣሚዎች ማገድ የቻለበትን ሁኔታ ብቻ ግምት ውስጥ ማስገባት አለብን. በዚህ ጉዳይ ላይ, ከላይ ያለውን ክርክር በተመለከተ, በጊዜው MIN_VALIDITY ማንም ደንበኛ መቆለፊያውን መልሶ ማግኘት መቻል የለበትም። ስለዚህ፣ ብዙ ደንበኞች የ N/2+1 አጋጣሚዎችን በተመሳሳይ ጊዜ መቆለፍ የሚችሉት (በደረጃ 2 መጨረሻ ላይ ነው) ብዙዎችን የመቆለፍ ጊዜ ከቲቲኤል ጊዜ የበለጠ በሚሆንበት ጊዜ ብቻ ነው፣ በዚህም መቆለፊያውን ዋጋ ያሳጣዋል።

እና መደበኛ የሆነ የደህንነት ማረጋገጫ መስጠት፣ ያሉትን ተመሳሳይ ስልተ ቀመሮች መጠቆም ወይም ከላይ ያለውን ስህተት ማግኘት ትችላለህ?

የተደራሽነት ግምት

የስርአቱ መገኘት በሶስት ዋና ዋና ባህሪያት ላይ የተመሰረተ ነው.

1. መቆለፊያው በራስ-ሰር መለቀቅ (ቁልፎቹ ስለሚያልቁ)፡ በመጨረሻ ቁልፎቹ ለመቆለፍ ጥቅም ላይ እንዲውሉ እንደገና ይገኛሉ።
2. ብዙውን ጊዜ ደንበኞች የሚፈለገው መቆለፊያ ሳይገኝ ሲቀር ወይም ሲገኝ እና ሥራው ሲጠናቀቅ መቆለፊያዎችን በማንሳት እርስ በርስ መረዳዳት; ስለዚህ ቁልፉን እንደገና ለማግኘት ቁልፎቹ እስኪያልቅ ድረስ መጠበቅ የለብንም ማለት ነው።
3. አንድ ደንበኛ መቆለፊያን ለማግኘት እንደገና መሞከር ሲፈልግ፣ ብዙ መቆለፊያዎችን ለማግኘት ከሚያስፈልገው ጊዜ በአንፃራዊነት ረዘም ያለ ጊዜ ይጠብቃል። ይህ በሃብት ፉክክር ውስጥ የተከፈለ የአንጎል ሁኔታ እድልን ይቀንሳል።

ነገር ግን፣ ለተቀነሰ አቅርቦት ቅጣት መክፈል አለቦት፣ በኔትወርክ ክፍሎች ውስጥ ከ TTL ጊዜ ጋር እኩል ነው፣ ስለዚህ ቀጣይ ክፍሎች ካሉ፣ ይህ ቅጣት ያልተወሰነ ሊሆን ይችላል። ይሄ የሚሆነው አንድ ደንበኛ መቆለፊያ ባገኘ ቁጥር እና ከዚያ ከመልቀቁ በፊት ወደ ሌላ ክፍል ሲቀርጽ ነው።

በመርህ ደረጃ፣ ማለቂያ የሌላቸው ቀጣይ የአውታረ መረብ ክፍሎች ካሉ፣ ስርዓቱ ላልተወሰነ ጊዜ የማይገኝ ሆኖ ሊቆይ ይችላል።

አፈጻጸም፣ አለመሳካት እና fsync

ብዙ ሰዎች Redisን የሚጠቀሙት ለቁልፍ አገልጋዩ ከፍተኛ አፈፃፀም ስለሚፈልጉ፣ መቆለፊያዎችን ለማግኘት እና ለመልቀቅ ከሚያስፈልገው መዘግየት አንፃር እንዲሁም በሴኮንድ የሚጠናቀቁትን የመግዛት/የመልቀቅ ስራዎች ብዛት። ይህንን መስፈርት ለማሟላት ከN Redis አገልጋዮች ጋር የመግባባት መዘግየትን ለመቀነስ የሚያስችል ስልት አለ። ይህ የማባዛት ስልት ነው (ወይም "የድሃ ሰው ማባዛት" ሶኬቱ ወደ ማገድ ሁነታ የተቀናበረበት፣ ሁሉንም ትእዛዞች ይልካል እና ትእዛዞቹን በኋላ ያነብባል፣ ይህም በደንበኛው እና በእያንዳንዱ አጋጣሚ መካከል ያለው የዙር ጉዞ ጊዜ ተመሳሳይ ነው ተብሎ ይታሰባል። ).

ነገር ግን፣ በጠንካራ ውድቀት መልሶ ማግኛ ሞዴል ለመፍጠር ከፈለግን የረጅም ጊዜ የመረጃ ማከማቻ ግምትም አለ።

በመሠረቱ፣ ጉዳዩን ለማብራራት፣ ሬዲስን ያለምንም ጽናት እያዋቀርን ነው ብለን እናስብ። ደንበኛው ከ3 አጋጣሚዎች 5ቱን ማገድ ይችላል። ደንበኛው ሊያግዱት ከቻሉት ሁኔታዎች ውስጥ አንዱ እንደገና ተጀምሯል ፣ በዚህ ጊዜ 3 ተመሳሳይ ሀብቶች እንደገና ይታያሉ ፣ እኛ ልንከለክለው እንችላለን ፣ እና ሌላኛው ደንበኛ በተራው ደግሞ እንደገና የጀመረውን ምሳሌ በመዝጋት የመቆለፊያ አግላይነትን የሚወስደውን የደህንነት ንብረቱን ይጥሳል።

አስቀድመህ ዳታ (AOF) ካነቃህ ሁኔታው ​​በትንሹ ይሻሻላል። ለምሳሌ የ SHUTDOWN ትዕዛዝ በመስጠት እና እንደገና በማስጀመር አገልጋይን ማስተዋወቅ ይችላሉ። በሬዲስ ውስጥ ያሉት የማብቂያ ስራዎች በትርጉም ደረጃ ተግባራዊ ስለሚሆኑ አገልጋዩ ቢጠፋም ጊዜ መሄዱን ስለሚቀጥል ሁሉም ፍላጎቶቻችን ጥሩ ናቸው። መደበኛ መዘጋት እስካለ ድረስ መደበኛ። የመብራት መቆራረጥ ምን ማድረግ አለበት? Redis በነባሪነት ከተዋቀረ በዲስክ ላይ በየሰከንዱ fsync በማመሳሰል፣ ከዳግም ማስጀመር በኋላ ቁልፋችን በቂ ላይሆን ይችላል። በንድፈ ሀሳብ፣ በማንኛውም የአብነት ሁኔታ ላይ የመቆለፊያዎችን ደህንነት ማረጋገጥ ከፈለግን ማካተት አለብን fsync=always ለረጅም ጊዜ የውሂብ ማከማቻ ቅንብሮች ውስጥ. ይህ ሙሉ በሙሉ አፈጻጸምን ይገድላል, እንደዚህ ያሉ የሲፒ ስርዓቶች ደረጃ, ይህም በተለምዶ የተከፋፈሉ መቆለፊያዎች ደህንነቱ የተጠበቀ ትግበራ ጥቅም ላይ ይውላሉ.

ነገር ግን ሁኔታው ​​በመጀመሪያ እይታ ከሚታየው የተሻለ ነው. በመርህ ደረጃ፣ የአልጎሪዝም ደህንነት ተጠብቆ ይቆያል ምክንያቱም አንድ ምሳሌ ከተሳካ በኋላ እንደገና ሲጀመር አሁን ባለው መቆለፊያ ውስጥ አይሳተፍም።

ይህንን ለማረጋገጥ፣ ከተሳካልን በኋላ፣ ምሳሌው ከምንጠቀምበት ከፍተኛ TTL በትንሹ በልጦ መቆየቱን ብቻ ማረጋገጥ አለብን። ስለዚህ ውድቀት በሚከሰትበት ጊዜ ንቁ የነበሩትን ሁሉንም ቁልፎች የማብቂያ ጊዜ እና አውቶማቲክ መልቀቅን እንጠብቃለን።

የዘገየ ዳግም ማስጀመርን በመጠቀም በመርህ ደረጃ በሬዲስ ውስጥ የረጅም ጊዜ ጽናት ባይኖርም ደህንነትን ማግኘት ይቻላል። ይሁን እንጂ ይህ ተደራሽነትን በመጣስ ቅጣት ሊያስከትል እንደሚችል ልብ ይበሉ። ለምሳሌ፣ አብዛኛው አጋጣሚዎች ካልተሳኩ ስርዓቱ ለቲቲኤል ጊዜ በአለም አቀፍ ደረጃ የማይገኝ ይሆናል (እና በዚህ ጊዜ ምንም አይነት ግብአት ሊታገድ አይችልም)።

የአልጎሪዝምን ተገኝነት ማሻሻል: መቆለፊያውን ማራዘም

በደንበኞች የሚሠራው ሥራ አነስተኛ ደረጃዎችን ካቀፈ, ነባሪውን የመቆለፊያ ጊዜ መቀነስ እና መቆለፊያዎችን ለማራዘም ዘዴን መተግበር ይቻላል. በመርህ ደረጃ፣ ደንበኛው በስሌቶች ከተጠመደ እና የመቆለፊያ ጊዜው ዋጋ በአደገኛ ሁኔታ ከቀነሰ ቁልፉ አሁንም ካለ እና እሴቱ አሁንም የተገኘው የዘፈቀደ እሴት ከሆነ የ TTL ቁልፍን የሚያራዝሙ ለሁሉም ሁኔታዎች የሉአ ስክሪፕት መላክ ይችላሉ። መቆለፊያው ሲገኝ.

ደንበኛው በድጋሚ የተገኘውን መቆለፊያ በአገልግሎት ጊዜ ውስጥ አብዛኞቹን ጉዳዮች በተሳካ ሁኔታ ከቆለፈ በኋላ ብቻ ነው የሚያስበው።

እውነት ነው, አልጎሪዝም በቴክኒካዊነት አይለወጥም, ስለዚህ መቆለፊያዎችን ለማግኘት ከፍተኛው የድጋሚ ሙከራዎች ብዛት ውስን መሆን አለበት, አለበለዚያ የተደራሽነት ባህሪያቱ ይጣሳሉ.

ምንጭ: hab.com