Redis ఉపయోగించి లాకింగ్ పంపిణీ చేయబడింది

హే హబ్ర్!

ఈరోజు మేము మీ దృష్టికి Redisని ఉపయోగించి పంపిణీ చేయబడిన లాకింగ్ అమలు గురించి సంక్లిష్టమైన కథనం యొక్క అనువాదాన్ని అందిస్తున్నాము మరియు ఒక అంశంగా Redis యొక్క అవకాశాల గురించి మాట్లాడటానికి మిమ్మల్ని ఆహ్వానిస్తున్నాము. పుస్తకం యొక్క రచయిత మార్టిన్ క్లెప్‌మాన్ నుండి సందేహాస్పదంగా ఉన్న రెడ్‌లాక్ అల్గోరిథం యొక్క విశ్లేషణ "అధిక లోడ్ అప్లికేషన్లు", ఇచ్చిన ఇక్కడ.

పంపిణీ చేయబడిన లాకింగ్ అనేది అనేక వాతావరణాలలో ఉపయోగించే చాలా ఉపయోగకరమైన ఆదిమ, ఇక్కడ విభిన్న ప్రక్రియలు పరస్పరం ప్రత్యేక పద్ధతిలో భాగస్వామ్య వనరులపై పని చేయాలి.

Redisని ఉపయోగించి DLM (డిస్ట్రిబ్యూటెడ్ లాక్ మేనేజర్)ని ఎలా అమలు చేయాలో వివరించే అనేక లైబ్రరీలు మరియు పోస్ట్‌లు ఉన్నాయి, అయితే ప్రతి లైబ్రరీ విభిన్నమైన విధానాన్ని తీసుకుంటుంది మరియు అవి అందించే హామీలు కొంచెం అధునాతన డిజైన్‌తో సాధించగలిగే వాటితో పోలిస్తే చాలా బలహీనంగా ఉన్నాయి.

ఈ కథనంలో మేము రెడిస్ ఉపయోగించి పంపిణీ చేయబడిన లాకింగ్‌ను ఎలా అమలు చేయాలో ప్రదర్శించే షరతులతో కూడిన కానానికల్ అల్గారిథమ్‌ను వివరించడానికి ప్రయత్నిస్తాము. మేము అనే అల్గోరిథం గురించి మాట్లాడుతాము రెడ్లాక్, ఇది పంపిణీ చేయబడిన లాక్ మేనేజర్‌ని అమలు చేస్తుంది మరియు మా అభిప్రాయం ప్రకారం, ఈ అల్గోరిథం సాధారణ సింగిల్-ఇన్‌స్టాన్స్ విధానం కంటే సురక్షితమైనది. సంఘం దీనిని విశ్లేషిస్తుందని, అభిప్రాయాన్ని అందజేస్తుందని మరియు మరింత సంక్లిష్టమైన లేదా ప్రత్యామ్నాయ ప్రాజెక్ట్‌ల కోసం దీన్ని ప్రారంభ బిందువుగా ఉపయోగిస్తుందని మేము ఆశిస్తున్నాము.

అమలు

అల్గోరిథం యొక్క వివరణకు వెళ్లే ముందు, మేము రెడీమేడ్ అమలులకు అనేక లింక్‌లను అందిస్తాము. వారు సూచన కోసం ఉపయోగించవచ్చు.

• Redlock-rb (రూబీ కోసం అమలు). కూడా ఉంది ఫోర్క్ Redlock-rb, ఇది పంపిణీ సౌలభ్యం కోసం ఒక ప్యాకేజీ (రత్నం) జోడిస్తుంది మరియు దాని కోసం మాత్రమే కాదు.
• రెడ్‌లాక్-పై (పైథాన్ అమలు).
• ఎయిర్డ్లాక్ (Asyncio పైథాన్ కోసం అమలు).
• రెడ్లాక్-php (PHP కోసం అమలు).
• PHPRedisMutex (PHP కోసం మరొక అమలు)
• cheprasov/php-redis-lock (తాళాల కోసం PHP లైబ్రరీ)
• Redsync (గో కోసం అమలు).
• రెడిసన్ (జావా కోసం అమలు).
• Redis::DistLock (పెర్ల్ కోసం అమలు).
• రెడ్‌లాక్-సిపిపి (C++ కోసం అమలు).
• రెడ్‌లాక్-సిఎస్ (C#/.NET కోసం అమలు).
• RedLock.net (C#/.NET కోసం అమలు). అసమకాలీకరణ మరియు లాక్ పొడిగింపులకు మద్దతుతో.
• స్కార్లెట్‌లాక్ (కాన్ఫిగర్ చేయగల డేటా స్టోర్‌తో C# .NET కోసం అమలు)
• Redlock4Net (C# .NET కోసం అమలు)
• నోడ్-రెడ్‌లాక్ (NodeJS కోసం అమలు). లాక్‌లను విస్తరించడానికి మద్దతును కలిగి ఉంటుంది.

భద్రత మరియు లభ్యత హామీలు

పంపిణీ చేయబడిన లాకింగ్‌ను సమర్థవంతంగా ఉపయోగించడానికి అవసరమైన కనీస హామీలను అందించే మూడు లక్షణాలతో మేము మా డిజైన్‌ను మోడల్ చేయబోతున్నాము.

1. భద్రతా ఆస్తి: పరస్పర మినహాయింపు. ఏ సమయంలోనైనా, ఒక క్లయింట్ మాత్రమే లాక్‌ని పట్టుకోగలరు.
2. లభ్యత ఆస్తి A: డెడ్‌లాక్‌లు లేవు. రిసోర్స్‌ను లాక్ చేసిన క్లయింట్ విఫలమైనా లేదా వేరే డిస్క్ సెగ్మెంట్‌లో ల్యాండ్ అయినప్పటికీ, చివరికి లాక్‌ని పొందడం ఎల్లప్పుడూ సాధ్యపడుతుంది.
3. లభ్యత లక్షణం B: తప్పు సహనం. మెజారిటీ రెడిస్ నోడ్‌లు నడుస్తున్నంత కాలం, క్లయింట్‌లు లాక్‌లను పొందగలరు మరియు విడుదల చేయగలరు.

ఎందుకు వైఫల్యం రికవరీ ఆధారంగా అమలు ఈ సందర్భంలో సరిపోదు
మేము ఏమి మెరుగుపరచబోతున్నామో అర్థం చేసుకోవడానికి, Redis ఆధారంగా చాలా పంపిణీ చేయబడిన లాకింగ్ లైబ్రరీలతో ప్రస్తుత వ్యవహారాల స్థితిని విశ్లేషిద్దాం.

రెడిస్‌ని ఉపయోగించి రిసోర్స్‌ను లాక్ చేయడానికి సులభమైన మార్గం, ఉదాహరణకు కీని సృష్టించడం. సాధారణంగా, పరిమిత జీవితకాలంతో కీ సృష్టించబడుతుంది, ఇది Redisలో అందించబడిన గడువు ముగింపు ఫీచర్‌ని ఉపయోగించి సాధించబడుతుంది, కాబట్టి ముందుగానే లేదా తర్వాత ఈ కీ విడుదల చేయబడుతుంది (మా జాబితాలోని ఆస్తి 2). క్లయింట్ వనరును విడుదల చేయవలసి వచ్చినప్పుడు, అది కీని తొలగిస్తుంది.

మొదటి చూపులో, ఈ పరిష్కారం చాలా బాగా పనిచేస్తుంది, కానీ ఒక సమస్య ఉంది: మా నిర్మాణం వైఫల్యం యొక్క ఒకే పాయింట్‌ను సృష్టిస్తుంది. హోస్ట్ రెడిస్ ఉదాహరణ విఫలమైతే ఏమి జరుగుతుంది? అలాంటప్పుడు దాసుడిని చేర్చుకుందాం! మరియు ప్రెజెంటర్ అందుబాటులో లేకుంటే మేము దానిని ఉపయోగిస్తాము. దురదృష్టవశాత్తు, ఈ ఎంపిక ఆచరణీయమైనది కాదు. ఇలా చేయడం ద్వారా, మేము భద్రతను నిర్ధారించడానికి అవసరమైన పరస్పర మినహాయింపు ఆస్తిని సరిగ్గా అమలు చేయలేము, ఎందుకంటే Redisలో ప్రతిరూపం అసమకాలికమైనది.

సహజంగానే, అటువంటి నమూనాలో జాతి పరిస్థితి ఏర్పడుతుంది:

1. క్లయింట్ A మాస్టర్‌పై లాక్‌ని పొందుతుంది.
2. కీ ఎంట్రీని బానిసకు బదిలీ చేయడానికి ముందు మాస్టర్ విఫలమవుతాడు.
3. అనుచరుడు నాయకుడిగా పదోన్నతి పొందుతాడు.
4. A ఇప్పటికే లాక్ చేసిన అదే వనరుపై క్లయింట్ B లాక్‌ని పొందుతుంది. భద్రతా ఉల్లంఘన!

కొన్నిసార్లు వైఫల్యం వంటి ప్రత్యేక పరిస్థితుల్లో, చాలా మంది క్లయింట్లు ఒకే సమయంలో లాక్‌ని పట్టుకోవడం పూర్తిగా సాధారణం. అటువంటి సందర్భాలలో, ప్రతిరూపణ ఆధారిత పరిష్కారం వర్తించవచ్చు. లేకపోతే, ఈ వ్యాసంలో వివరించిన పరిష్కారాన్ని మేము సిఫార్సు చేస్తున్నాము.

ఒకే ఉదాహరణతో సరైన అమలు

పైన వివరించిన సింగిల్-ఇన్‌స్టాన్స్ కాన్ఫిగరేషన్ యొక్క లోపాలను అధిగమించడానికి ప్రయత్నించే ముందు, ఈ సరళమైన కేసును ఎలా సరిగ్గా నిర్వహించాలో అర్థం చేసుకుందాం, ఎందుకంటే ఈ పరిష్కారం కాలానుగుణంగా రేసు పరిస్థితి ఆమోదయోగ్యమైన అప్లికేషన్‌లలో చెల్లుబాటు అవుతుంది మరియు ఒకదానిపై నిరోధించడం వలన ఇక్కడ వివరించిన పంపిణీ అల్గారిథమ్‌లో ఉపయోగించిన ఆధారం ఒకే ఉదాహరణ.

లాక్ పొందడానికి, ఇలా చేయండి:

SET resource_name my_random_value NX PX 30000

ఈ కమాండ్ 30000 మిల్లీసెకన్ల (PX ఎంపిక) చెల్లుబాటు వ్యవధితో (NX ఎంపిక) ఇప్పటికే లేనట్లయితే మాత్రమే కీని ఇన్‌స్టాల్ చేస్తుంది. కీ సెట్ చేయబడింది "myrandomvalue" ఈ విలువ తప్పనిసరిగా అన్ని క్లయింట్‌లు మరియు అన్ని లాక్ అభ్యర్థనలలో ప్రత్యేకంగా ఉండాలి.
ప్రాథమికంగా, లాక్‌ని సురక్షితంగా విడుదల చేయడానికి యాదృచ్ఛిక విలువ ఉపయోగించబడుతుంది, స్క్రిప్ట్ రెడిస్‌తో చెబుతుంది: కీ ఉనికిలో ఉంటే మాత్రమే దాన్ని తీసివేయండి మరియు దానిలో నిల్వ చేయబడిన విలువ ఖచ్చితంగా ఊహించిన విధంగా ఉంటుంది. కింది లువా స్క్రిప్ట్‌ని ఉపయోగించి ఇది సాధించబడుతుంది:

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తో సీడ్ చేసి, దాని నుండి ఒక నకిలీ యాదృచ్ఛిక స్ట్రీమ్‌ను రూపొందించడం మంచిది. ఒక సరళమైన పరిష్కారం మైక్రోసెకండ్ రిజల్యూషన్‌లో unix సమయం మరియు క్లయింట్ ID కలయికను కలిగి ఉంటుంది; ఇది అంత సురక్షితమైనది కాదు, కానీ ఇది చాలా సందర్భాలలో పనికి సంబంధించినది.

కీ యొక్క జీవితకాలం యొక్క కొలతగా మనం ఉపయోగించే సమయాన్ని "లాక్ జీవితకాలం" అంటారు. ఈ విలువ అనేది లాక్ స్వయంచాలకంగా విడుదల కావడానికి ముందు సమయం మరియు పరస్పర మినహాయింపు హామీలను ఉల్లంఘించకుండా, మరొక క్లయింట్ ఆ వనరును లాక్ చేయడానికి ముందు ఒక క్లయింట్ ఆపరేషన్‌ని పూర్తి చేయాల్సిన సమయం రెండూ. ఈ హామీ నిర్దిష్ట సమయ విండోకు మాత్రమే పరిమితం చేయబడింది, ఇది లాక్ కొనుగోలు చేసిన క్షణం నుండి ప్రారంభమవుతుంది.

కాబట్టి మేము లాక్‌ని పొందేందుకు మరియు విడుదల చేయడానికి మంచి మార్గం గురించి చర్చించాము. సిస్టమ్ (మేము ఒకే మరియు ఎల్లప్పుడూ అందుబాటులో ఉన్న ఉదాహరణతో కూడిన పంపిణీ చేయని సిస్టమ్ గురించి మాట్లాడుతున్నట్లయితే) సురక్షితం. ఈ కాన్సెప్ట్‌ని డిస్ట్రిబ్యూట్ సిస్టమ్‌కి విస్తరింపజేద్దాం, అక్కడ మనకు అలాంటి హామీలు లేవు.

రెడ్‌లాక్ అల్గోరిథం

అల్గోరిథం యొక్క పంపిణీ సంస్కరణ మనకు N Redis మాస్టర్‌లను కలిగి ఉందని ఊహిస్తుంది. ఈ నోడ్‌లు ఒకదానికొకటి పూర్తిగా స్వతంత్రంగా ఉంటాయి, కాబట్టి మేము ప్రతిరూపణ లేదా మరే ఇతర అవ్యక్త సమన్వయ వ్యవస్థను ఉపయోగించము. ఒకే సందర్భంలో లాక్‌ని సురక్షితంగా పొందడం మరియు విడుదల చేయడం ఎలాగో మేము ఇప్పటికే కవర్ చేసాము. అల్గోరిథం, ఒకే ఉదాహరణతో పని చేస్తున్నప్పుడు, సరిగ్గా ఈ పద్ధతిని ఉపయోగిస్తుందని మేము దానిని మంజూరు చేస్తాము. మా ఉదాహరణలలో మేము N ను 5కి సెట్ చేసాము, ఇది సహేతుకమైన విలువ. అందువల్ల, మేము వేర్వేరు కంప్యూటర్‌లు లేదా వర్చువల్ మెషీన్‌లలో 5 రెడిస్ మాస్టర్‌లను ఉపయోగించాల్సి ఉంటుంది, అవి ఒకదానికొకటి చాలావరకు స్వతంత్రంగా పనిచేస్తాయి.

లాక్‌ని పొందేందుకు, క్లయింట్ కింది కార్యకలాపాలను నిర్వహిస్తుంది:

1. ప్రస్తుత సమయాన్ని మిల్లీసెకన్లలో పొందుతుంది.
2. అన్ని సందర్భాలలో ఒకే కీ పేరు మరియు యాదృచ్ఛిక విలువలను ఉపయోగించి, అన్ని N సందర్భాలలో లాక్‌ని పొందేందుకు వరుసగా ప్రయత్నిస్తుంది. స్టేజ్ 2లో, క్లయింట్ ప్రతి-ఉదాహరణ ప్రాతిపదికన లాక్‌ని సెటప్ చేసినప్పుడు, క్లయింట్ లాక్ స్వయంచాలకంగా విడుదల చేయబడిన సమయంతో పోలిస్తే తగినంత తక్కువగా ఉన్న దానిని పొందేందుకు ఆలస్యాన్ని ఉపయోగిస్తుంది. ఉదాహరణకు, నిరోధించే వ్యవధి 10 సెకన్లు అయితే, ఆలస్యం ~5-50 మిల్లీసెకన్ల పరిధిలో ఉండవచ్చు. ఇది విఫలమైన Redis నోడ్‌ను చేరుకోవడానికి ప్రయత్నిస్తున్న క్లయింట్ చాలా కాలం పాటు బ్లాక్ చేయబడే పరిస్థితిని తొలగిస్తుంది: ఉదాహరణ అందుబాటులో లేకుంటే, మేము వీలైనంత త్వరగా మరొక ఉదాహరణకి కనెక్ట్ చేయడానికి ప్రయత్నిస్తాము.
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 కీలు ఇప్పటికే ఉన్నట్లయితే N/2+1 SET NX కార్యకలాపాలు విజయవంతం కావు. అందువల్ల, ఒకసారి లాక్ పొందిన తర్వాత, అదే సమయంలో దాన్ని మళ్లీ పొందడం అసాధ్యం (ఇది పరస్పర మినహాయింపు ఆస్తిని ఉల్లంఘిస్తుంది).
అయితే, ఒకే సమయంలో లాక్‌ని పొందేందుకు ప్రయత్నిస్తున్న బహుళ క్లయింట్‌లు ఒకే సమయంలో విజయవంతం కాలేరని మేము నిర్ధారించుకోవాలనుకుంటున్నాము.

క్లయింట్ గరిష్ట లాక్ వ్యవధి కంటే ఎక్కువ లేదా అంతకంటే ఎక్కువ సందర్భాలను లాక్ చేసి ఉంటే, అది లాక్ చెల్లనిదిగా పరిగణించి, పర్యాయాలను అన్‌లాక్ చేస్తుంది. కాబట్టి, గడువు తేదీ కంటే తక్కువ సమయంలో క్లయింట్ మెజారిటీ సందర్భాలలో బ్లాక్ చేయగలిగే సందర్భాన్ని మాత్రమే మేము పరిగణనలోకి తీసుకోవాలి. ఈ సందర్భంలో, పై వాదనకు సంబంధించి, సమయంలో MIN_VALIDITY ఏ క్లయింట్ లాక్‌ని తిరిగి పొందలేరు. అందువల్ల, చాలా మంది క్లయింట్లు ఒకే సమయంలో N/2+1 దృష్టాంతాలను లాక్ చేయగలరు (ఇది దశ 2 చివరిలో ముగుస్తుంది) మెజారిటీని లాక్ చేసే సమయం TTL సమయం కంటే ఎక్కువగా ఉన్నప్పుడు మాత్రమే లాక్ చెల్లదు.

మీరు భద్రతకు సంబంధించిన అధికారిక రుజువును అందించగలరా, ఇప్పటికే ఉన్న సారూప్య అల్గారిథమ్‌లను సూచించగలరా లేదా పై వాటిలో బగ్‌ను కనుగొనగలరా?

యాక్సెసిబిలిటీ పరిగణనలు

సిస్టమ్ లభ్యత మూడు ప్రధాన లక్షణాలపై ఆధారపడి ఉంటుంది:

1. లాక్‌లను స్వయంచాలకంగా విడుదల చేయండి (కీల గడువు ముగియడంతో): లాక్‌ల కోసం ఉపయోగించేందుకు కీలు చివరికి మళ్లీ అందుబాటులోకి వస్తాయి.
2. క్లయింట్‌లు సాధారణంగా కోరుకున్న లాక్‌ని పొందనప్పుడు, లేదా కొనుగోలు చేయబడినప్పుడు మరియు ఉద్యోగం పూర్తయినప్పుడు తాళాలను తీసివేయడం ద్వారా ఒకరికొకరు సహాయం చేసుకుంటారు; కాబట్టి లాక్‌ని తిరిగి పొందేందుకు కీల గడువు ముగిసే వరకు మనం వేచి ఉండాల్సిన అవసరం లేదు.
3. ఒక క్లయింట్ లాక్‌ని పొందేందుకు మళ్లీ ప్రయత్నించాల్సిన అవసరం వచ్చినప్పుడు, చాలా లాక్‌లను పొందేందుకు అవసరమైన వ్యవధి కంటే ఎక్కువ సమయం వేచి ఉంటుంది. ఇది వనరుల కోసం పోటీ పడుతున్నప్పుడు తలెత్తే స్ప్లిట్-మెదడు పరిస్థితి యొక్క సంభావ్యతను తగ్గిస్తుంది.

అయితే, నెట్‌వర్క్ విభాగాల TTLకి సమానమైన లభ్యత పెనాల్టీ ఉంది, కాబట్టి ప్రక్కనే ఉన్న విభాగాలు ఉంటే, పెనాల్టీ నిరవధికంగా ఉండవచ్చు. క్లయింట్ లాక్‌ని పొంది, దానిని విడుదల చేయడానికి ముందు మరొక విభాగానికి రిప్ అయినప్పుడల్లా ఇది జరుగుతుంది.

సూత్రప్రాయంగా, అనంతమైన ప్రక్కనే ఉన్న నెట్‌వర్క్ విభాగాలను ఇచ్చినట్లయితే, సిస్టమ్ అనంతమైన కాలం వరకు అందుబాటులో ఉండదు.

పనితీరు, వైఫల్యం మరియు fsync

చాలా మంది వ్యక్తులు Redisని ఉపయోగిస్తున్నారు ఎందుకంటే లాక్‌లను పొందేందుకు మరియు విడుదల చేయడానికి అవసరమైన జాప్యం మరియు సెకనుకు పూర్తి చేయగల సముపార్జనలు/విడుదలల సంఖ్య పరంగా వారికి అధిక లాక్ సర్వర్ పనితీరు అవసరం. ఈ అవసరాన్ని తీర్చడానికి, జాప్యాన్ని తగ్గించడానికి N Redis సర్వర్‌లతో కమ్యూనికేట్ చేయడానికి ఒక వ్యూహం ఉంది. ఇది మల్టీప్లెక్సింగ్ స్ట్రాటజీ (లేదా "పేదవారి మల్టీప్లెక్సింగ్", ఇక్కడ సాకెట్ నాన్-బ్లాకింగ్ మోడ్‌లో ఉంచబడుతుంది, అన్ని ఆదేశాలను పంపుతుంది మరియు క్లయింట్ మరియు ప్రతి సందర్భం మధ్య రౌండ్-ట్రిప్ సమయం ఒకేలా ఉంటుందని భావించి, ఆదేశాలను తర్వాత చదువుతుంది) .

అయినప్పటికీ, వైఫల్యాల నుండి నమ్మదగిన రికవరీతో మోడల్‌ను రూపొందించడానికి మేము ప్రయత్నిస్తే, దీర్ఘకాలిక డేటా నిల్వతో అనుబంధించబడిన పరిగణనను కూడా మేము పరిగణనలోకి తీసుకోవాలి.

ప్రాథమికంగా, సమస్యను స్పష్టం చేయడానికి, మేము దీర్ఘకాల డేటా నిల్వ లేకుండా Redisని కాన్ఫిగర్ చేసాము. క్లయింట్ 3 సందర్భాలలో 5ని బ్లాక్ చేయగలడు. క్లయింట్ బ్లాక్ చేయగలిగిన సందర్భాల్లో ఒకటి పునఃప్రారంభించబడింది మరియు ఈ సమయంలో అదే వనరు కోసం మళ్లీ 3 సందర్భాలు ఉన్నాయి, వీటిని మేము బ్లాక్ చేయవచ్చు మరియు మరొక క్లయింట్, పునఃప్రారంభించిన ఉదాహరణను బ్లాక్ చేయవచ్చు, భద్రతా ఆస్తిని ఉల్లంఘిస్తుంది తాళాల ప్రత్యేకతను ఊహిస్తుంది.

మీరు ముందుగా డేటాను (AOF) ప్రారంభిస్తే, పరిస్థితి కొద్దిగా మెరుగుపడుతుంది. ఉదాహరణకు, మీరు SHUTDOWN కమాండ్‌ని పంపడం ద్వారా మరియు దాన్ని పునఃప్రారంభించడం ద్వారా సర్వర్‌ను ప్రమోట్ చేయవచ్చు. Redisలో గడువు ముగింపు కార్యకలాపాలు సెమాంటిక్‌గా అమలు చేయబడినందున, సర్వర్ ఆఫ్ చేయబడినప్పుడు కూడా సమయం ప్రవహిస్తూనే ఉంటుంది, మా అవసరాలన్నీ బాగానే ఉన్నాయి. సాధారణ షట్‌డౌన్ నిర్ధారించబడినంత వరకు ఇది సాధారణం. విద్యుత్తు అంతరాయం ఏర్పడితే ఏమి చేయాలి? Redis డిఫాల్ట్‌గా కాన్ఫిగర్ చేయబడి ఉంటే, fsync ప్రతి సెకనుకు డిస్క్‌లో సమకాలీకరించబడుతుంది, అప్పుడు పునఃప్రారంభించిన తర్వాత మన కీ మన దగ్గర ఉండకపోవచ్చు. సిద్ధాంతపరంగా, ఏదైనా సందర్భంలో పునఃప్రారంభించేటప్పుడు మేము లాక్ భద్రతకు హామీ ఇవ్వాలనుకుంటే, మేము ప్రారంభించాలి fsync=always దీర్ఘకాలిక డేటా నిల్వ కోసం సెట్టింగ్‌లలో. పంపిణీ చేయబడిన తాళాలను సురక్షితంగా అమలు చేయడానికి సాంప్రదాయకంగా ఉపయోగించే CP సిస్టమ్‌ల స్థాయికి ఇది పనితీరును పూర్తిగా నాశనం చేస్తుంది.

కానీ మొదటి చూపులో కనిపించే దానికంటే పరిస్థితి మెరుగ్గా ఉంది. సూత్రప్రాయంగా, అల్గోరిథం యొక్క భద్రత భద్రపరచబడుతుంది ఎందుకంటే విఫలమైన తర్వాత ఉదాహరణ పునఃప్రారంభించబడినప్పుడు, ప్రస్తుతం క్రియాశీలంగా ఉన్న ఏ లాక్‌లోనూ అది పాల్గొనదు.

దీన్ని నిర్ధారించడానికి, వైఫల్యం తర్వాత మేము ఉపయోగించే గరిష్ట TTL కంటే కొంచెం ఎక్కువ సమయం వరకు ఉదాహరణ అందుబాటులో ఉండదని మేము నిర్ధారించుకోవాలి. ఈ విధంగా మేము విఫలమైన సమయంలో సక్రియంగా ఉన్న అన్ని కీల గడువు తేదీ మరియు స్వయంచాలక విడుదల వరకు వేచి ఉంటాము.

ఆలస్యమైన రీస్టార్ట్‌లను ఉపయోగించి, రెడిస్‌లో దీర్ఘకాలిక పట్టుదల లేనప్పటికీ భద్రతను సాధించడం సూత్రప్రాయంగా సాధ్యమవుతుంది. అయితే, ఇది ప్రాప్యతను ఉల్లంఘించినందుకు జరిమానా విధించబడుతుందని గమనించండి. ఉదాహరణకు, చాలా సందర్భాలలో విఫలమైతే, సిస్టమ్ TTLకి ప్రపంచవ్యాప్తంగా అందుబాటులో ఉండదు (మరియు ఈ సమయంలో ఏ వనరును బ్లాక్ చేయలేరు).

మేము అల్గోరిథం యొక్క లభ్యతను పెంచుతాము: మేము నిరోధించడాన్ని పొడిగిస్తాము

క్లయింట్లు చేసే పని చిన్న దశలను కలిగి ఉన్నట్లయితే, డిఫాల్ట్ లాక్ వ్యవధిని తగ్గించడం మరియు లాక్‌లను పొడిగించే విధానాన్ని అమలు చేయడం సాధ్యపడుతుంది. సూత్రప్రాయంగా, క్లయింట్ కంప్యూటింగ్‌లో బిజీగా ఉంటే మరియు లాక్ గడువు ముగింపు విలువ ప్రమాదకరంగా తక్కువగా ఉంటే, కీ ఇప్పటికీ ఉనికిలో ఉన్నట్లయితే మరియు దాని విలువ ఇప్పటికీ యాదృచ్ఛిక విలువ అయినప్పుడు, కీ యొక్క TTLని విస్తరించే అన్ని సందర్భాలకు మీరు Lua స్క్రిప్ట్‌ను పంపవచ్చు. తాళం పొందారు.

క్లయింట్ చెల్లుబాటు వ్యవధిలో చాలా సందర్భాలలో లాక్ చేయగలిగితే మాత్రమే లాక్‌ని తిరిగి పొందాలని పరిగణించాలి.

నిజమే, సాంకేతికంగా అల్గోరిథం మారదు, కాబట్టి లాక్‌లను పొందేందుకు గరిష్ట సంఖ్యలో పునరావృతమయ్యే ప్రయత్నాలను పరిమితం చేయాలి, లేకపోతే ప్రాప్యత లక్షణాలు ఉల్లంఘించబడతాయి.

మూలం: www.habr.com