Redis ഉപയോഗിച്ച് ലോക്കിംഗ് വിതരണം ചെയ്തു

ഹേ ഹബർ!

റെഡിസ് ഉപയോഗിച്ച് വിതരണം ചെയ്ത ലോക്കിംഗ് നടപ്പിലാക്കുന്നതിനെക്കുറിച്ചുള്ള സങ്കീർണ്ണമായ ഒരു ലേഖനത്തിന്റെ വിവർത്തനം ഞങ്ങൾ ഇന്ന് നിങ്ങളുടെ ശ്രദ്ധയിൽപ്പെടുത്തുകയും ഒരു വിഷയമായി റെഡിസിന്റെ സാധ്യതകളെക്കുറിച്ച് സംസാരിക്കാൻ നിങ്ങളെ ക്ഷണിക്കുകയും ചെയ്യുന്നു. "" എന്ന പുസ്തകത്തിന്റെ രചയിതാവായ മാർട്ടിൻ ക്ലെപ്പ്മാനിൽ നിന്നുള്ള റെഡ്ലോക്ക് അൽഗോരിതത്തിന്റെ വിശകലനംഉയർന്ന ലോഡ് ആപ്ലിക്കേഷനുകൾ", കൊടുത്തു ഇവിടെ.

പല പരിതസ്ഥിതികളിലും ഉപയോഗിക്കുന്ന വളരെ ഉപയോഗപ്രദമായ ഒരു പ്രാകൃതമാണ് ഡിസ്ട്രിബ്യൂട്ടഡ് ലോക്കിംഗ്.

Redis ഉപയോഗിച്ച് DLM (ഡിസ്ട്രിബ്യൂട്ടഡ് ലോക്ക് മാനേജർ) നടപ്പിലാക്കുന്നത് എങ്ങനെയെന്ന് വിവരിക്കുന്ന നിരവധി ലൈബ്രറികളും പോസ്റ്റുകളും അവിടെയുണ്ട്, എന്നാൽ ഓരോ ലൈബ്രറിയും വ്യത്യസ്തമായ സമീപനമാണ് സ്വീകരിക്കുന്നത്, അവ നൽകുന്ന ഗ്യാരന്റികൾ അൽപ്പം കൂടുതൽ സങ്കീർണ്ണമായ ഡിസൈൻ ഉപയോഗിച്ച് നേടാനാകുന്നതിനെ അപേക്ഷിച്ച് വളരെ ദുർബലമാണ്.

ഈ ലേഖനത്തിൽ, Redis ഉപയോഗിച്ച് വിതരണം ചെയ്ത ലോക്കിംഗ് എങ്ങനെ നടപ്പിലാക്കാമെന്ന് കാണിക്കുന്ന ഒരു സോപാധിക കാനോനിക്കൽ അൽഗോരിതം വിവരിക്കാൻ ഞങ്ങൾ ശ്രമിക്കും. എന്ന് വിളിക്കപ്പെടുന്ന ഒരു അൽഗോരിതത്തെക്കുറിച്ച് നമ്മൾ സംസാരിക്കും റെഡ്ലോക്ക്, ഇത് ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് ലോക്ക് മാനേജർ നടപ്പിലാക്കുന്നു, ഞങ്ങളുടെ അഭിപ്രായത്തിൽ, ഈ അൽഗോരിതം സാധാരണ സിംഗിൾ-ഇൻസ്റ്റൻസ് സമീപനത്തേക്കാൾ സുരക്ഷിതമാണ്. കമ്മ്യൂണിറ്റി ഇത് വിശകലനം ചെയ്യുമെന്നും ഫീഡ്‌ബാക്ക് നൽകുമെന്നും കൂടുതൽ സങ്കീർണ്ണമായ അല്ലെങ്കിൽ ഇതര പ്രോജക്റ്റുകൾക്ക് ഒരു തുടക്കമായി ഉപയോഗിക്കുമെന്നും ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

നടപ്പിലാക്കൽ

അൽഗോരിതത്തിന്റെ വിവരണത്തിലേക്ക് പോകുന്നതിന് മുമ്പ്, റെഡിമെയ്ഡ് നടപ്പിലാക്കലുകളിലേക്ക് ഞങ്ങൾ നിരവധി ലിങ്കുകൾ നൽകുന്നു. അവ റഫറൻസിനായി ഉപയോഗിക്കാം.

• റെഡ്ലോക്ക്-ആർബി (റൂബിക്ക് നടപ്പിലാക്കൽ). അവിടെയും ഉണ്ട് നാൽക്കവല Redlock-rb, വിതരണത്തിന്റെ എളുപ്പത്തിനായി ഒരു പാക്കേജ് (രത്നം) ചേർക്കുന്നു, അതിനായി മാത്രമല്ല.
• റെഡ്ലോക്ക്-പൈ (പൈത്തൺ നടപ്പിലാക്കൽ).
• എയർഡ്ലോക്ക് (Asyncio Python-നുള്ള നടപ്പാക്കൽ).
• റെഡ്ലോക്ക്-പിഎച്ച്പി (PHP-യ്‌ക്കായി നടപ്പിലാക്കൽ).
• PHPRedisMutex (PHP-യ്‌ക്കുള്ള മറ്റൊരു നിർവ്വഹണം)
• cheprasov/php-redis-lock (ലോക്കുകൾക്കുള്ള PHP ലൈബ്രറി)
• റെഡ്സിങ്ക് (ഗോയ്‌ക്കായി നടപ്പിലാക്കൽ).
• റെഡിസൺ (ജാവയ്ക്കായി നടപ്പിലാക്കൽ).
• Redis::DistLock (Perl-നുള്ള നടപ്പാക്കൽ).
• റെഡ്ലോക്ക്-സിപിപി (സി++ നുള്ള നടപ്പാക്കൽ).
• റെഡ്ലോക്ക്-സിഎസ് (C#/.NET-നുള്ള നടപ്പാക്കൽ).
• RedLock.net (C#/.NET-നുള്ള നടപ്പാക്കൽ). അസിൻക്, ലോക്ക് എക്സ്റ്റൻഷനുകൾക്കുള്ള പിന്തുണയോടെ.
• സ്കാർലറ്റ്ലോക്ക് (കോൺഫിഗർ ചെയ്യാവുന്ന ഡാറ്റ സ്റ്റോർ ഉള്ള C# .NET-നുള്ള നടപ്പാക്കൽ)
• Redlock4Net (C# .NET-നുള്ള നടപ്പാക്കൽ)
• നോഡ്-റെഡ്ലോക്ക് (NodeJS-നുള്ള നടപ്പാക്കൽ). ലോക്കുകൾ വിപുലീകരിക്കുന്നതിനുള്ള പിന്തുണ ഉൾപ്പെടുന്നു.

സുരക്ഷയും ലഭ്യതയും ഉറപ്പ്

വിതരണം ചെയ്ത ലോക്കിംഗ് ഫലപ്രദമായി ഉപയോഗിക്കുന്നതിന് ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ ഗ്യാരണ്ടി നൽകുമെന്ന് ഞങ്ങൾ കരുതുന്ന മൂന്ന് പ്രോപ്പർട്ടികൾ ഉപയോഗിച്ച് ഞങ്ങളുടെ ഡിസൈൻ മാതൃകയാക്കാൻ പോകുന്നു.

1. സുരക്ഷാ പ്രോപ്പർട്ടി: പരസ്പര ഒഴിവാക്കൽ. ഏത് സമയത്തും, ഒരു ക്ലയന്റിന് മാത്രമേ ലോക്ക് പിടിക്കാൻ കഴിയൂ.
2. ലഭ്യത പ്രോപ്പർട്ടി എ: തടസ്സങ്ങളൊന്നുമില്ല. റിസോഴ്‌സ് ലോക്ക് ചെയ്‌ത ക്ലയന്റ് പരാജയപ്പെടുകയോ മറ്റൊരു ഡിസ്‌ക് സെഗ്‌മെന്റിൽ ഇറങ്ങുകയോ ചെയ്‌താലും, ഒടുവിൽ ഒരു ലോക്ക് സ്വന്തമാക്കുന്നത് എല്ലായ്പ്പോഴും സാധ്യമാണ്.
3. ലഭ്യത പ്രോപ്പർട്ടി ബി: തെറ്റ് സഹിഷ്ണുത. ഭൂരിഭാഗം റെഡിസ് നോഡുകളും പ്രവർത്തിക്കുന്നിടത്തോളം, ക്ലയന്റുകൾക്ക് ലോക്കുകൾ സ്വന്തമാക്കാനും റിലീസ് ചെയ്യാനും കഴിയും.

പരാജയം വീണ്ടെടുക്കൽ അടിസ്ഥാനമാക്കിയുള്ള നടപ്പാക്കൽ ഈ കേസിൽ പര്യാപ്തമല്ല
നമ്മൾ എന്താണ് മെച്ചപ്പെടുത്താൻ പോകുന്നതെന്ന് മനസിലാക്കാൻ, റെഡിസിനെ അടിസ്ഥാനമാക്കിയുള്ള മിക്ക വിതരണം ചെയ്ത ലോക്കിംഗ് ലൈബ്രറികളുടെയും നിലവിലെ അവസ്ഥ വിശകലനം ചെയ്യാം.

Redis ഉപയോഗിച്ച് ഒരു റിസോഴ്സ് ലോക്ക് ചെയ്യുന്നതിനുള്ള ഏറ്റവും ലളിതമായ മാർഗ്ഗം സന്ദർഭത്തിൽ ഒരു കീ സൃഷ്ടിക്കുക എന്നതാണ്. സാധാരണഗതിയിൽ, പരിമിതമായ ആയുസ്സ് ഉപയോഗിച്ചാണ് ഒരു കീ സൃഷ്‌ടിക്കുന്നത്, ഇത് Redis-ൽ നൽകിയിരിക്കുന്ന കാലഹരണപ്പെടുന്ന സവിശേഷത ഉപയോഗിച്ചാണ് നേടുന്നത്, അതിനാൽ എത്രയും വേഗം അല്ലെങ്കിൽ പിന്നീട് ഈ കീ റിലീസ് ചെയ്യും (ഞങ്ങളുടെ പട്ടികയിലെ പ്രോപ്പർട്ടി 2). ക്ലയന്റ് റിസോഴ്സ് റിലീസ് ചെയ്യേണ്ടിവരുമ്പോൾ, അത് കീ ഇല്ലാതാക്കുന്നു.

ഒറ്റനോട്ടത്തിൽ, ഈ പരിഹാരം നന്നായി പ്രവർത്തിക്കുന്നു, പക്ഷേ ഒരു പ്രശ്നമുണ്ട്: ഞങ്ങളുടെ വാസ്തുവിദ്യ പരാജയത്തിന്റെ ഒരു പോയിന്റ് സൃഷ്ടിക്കുന്നു. ഹോസ്റ്റ് റെഡിസ് ഇൻസ്‌റ്റൻസ് പരാജയപ്പെട്ടാൽ എന്ത് സംഭവിക്കും? അപ്പോൾ നമുക്ക് ഒരു അടിമയെ ചേർക്കാം! അവതാരകൻ ലഭ്യമല്ലെങ്കിൽ ഞങ്ങൾ അത് ഉപയോഗിക്കും. നിർഭാഗ്യവശാൽ, ഈ ഓപ്ഷൻ പ്രായോഗികമല്ല. ഇത് ചെയ്യുന്നതിലൂടെ, സുരക്ഷ ഉറപ്പാക്കാൻ ആവശ്യമായ പരസ്പര ഒഴിവാക്കൽ പ്രോപ്പർട്ടി ശരിയായി നടപ്പിലാക്കാൻ ഞങ്ങൾക്ക് കഴിയില്ല, കാരണം Redis-ലെ പകർപ്പ് അസമന്വിതമാണ്.

വ്യക്തമായും, അത്തരമൊരു മാതൃകയിൽ ഒരു റേസ് അവസ്ഥ സംഭവിക്കുന്നു:

1. ക്ലയന്റ് എ മാസ്റ്ററിൽ ഒരു ലോക്ക് നേടുന്നു.
2. കീ എൻട്രി അടിമയിലേക്ക് മാറ്റുന്നതിന് മുമ്പ് യജമാനൻ പരാജയപ്പെടുന്നു.
3. അനുയായിയെ നേതാവായി ഉയർത്തുന്നു.
4. A ഇതിനകം ലോക്ക് ചെയ്‌ത അതേ ഉറവിടത്തിൽ ക്ലയന്റ് ബി ഒരു ലോക്ക് നേടുന്നു. സുരക്ഷാ ലംഘനം!

പരാജയം പോലെയുള്ള പ്രത്യേക സാഹചര്യങ്ങളിൽ, പല ക്ലയന്റുകൾക്കും ഒരേ സമയം ലോക്ക് പിടിക്കാൻ കഴിയുന്നത് ചിലപ്പോൾ തികച്ചും സാധാരണമാണ്. അത്തരം സന്ദർഭങ്ങളിൽ, ഒരു പകർപ്പ് അടിസ്ഥാനമാക്കിയുള്ള പരിഹാരം പ്രയോഗിക്കാവുന്നതാണ്. അല്ലെങ്കിൽ, ഈ ലേഖനത്തിൽ വിവരിച്ചിരിക്കുന്ന പരിഹാരം ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു.

ഒരൊറ്റ ഉദാഹരണത്തിലൂടെ ശരിയായ നടപ്പാക്കൽ

മുകളിൽ വിവരിച്ച സിംഗിൾ-ഇൻസ്‌റ്റൻസ് കോൺഫിഗറേഷന്റെ പോരായ്മകൾ മറികടക്കാൻ ശ്രമിക്കുന്നതിന് മുമ്പ്, ഈ ലളിതമായ കേസ് എങ്ങനെ ശരിയായി കൈകാര്യം ചെയ്യണമെന്ന് നമുക്ക് മനസിലാക്കാം, കാരണം കാലാകാലങ്ങളിൽ ഒരു റേസ് അവസ്ഥ സ്വീകാര്യമായ ആപ്ലിക്കേഷനുകളിൽ ഈ പരിഹാരം യഥാർത്ഥത്തിൽ സാധുതയുള്ളതാണ്. ഇവിടെ വിവരിച്ചിരിക്കുന്ന ഡിസ്ട്രിബ്യൂട്ടഡ് അൽഗോരിതത്തിൽ ഉപയോഗിച്ചിരിക്കുന്ന അടിസ്ഥാനം സിംഗിൾ ഇൻസ്‌റ്റൻസ് ആണ്.

ഒരു ലോക്ക് സ്വന്തമാക്കാൻ, ഇത് ചെയ്യുക:

SET resource_name my_random_value NX PX 30000

30000 മില്ലിസെക്കൻഡ് (PX ഓപ്ഷൻ) സാധുതയുള്ള കാലയളവ് ഉള്ള ഒരു കീ നിലവിൽ ഇല്ലെങ്കിൽ മാത്രമേ ഈ കമാൻഡ് ഇൻസ്റ്റാൾ ചെയ്യുകയുള്ളൂ (NX ഓപ്ഷൻ). കീ സജ്ജീകരിച്ചിരിക്കുന്നു "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 ബൈറ്റുകൾ ആയിരിക്കണമെന്ന് ഞാൻ ഊഹിക്കുന്നു, എന്നാൽ നിങ്ങളുടെ ആവശ്യങ്ങൾക്ക് ആവശ്യമായ സ്ട്രിംഗ് അദ്വിതീയമാക്കുന്നതിനുള്ള ചെലവ് കുറഞ്ഞ മാർഗങ്ങൾ നിങ്ങൾക്ക് കണ്ടെത്താനാകും. ഉദാഹരണത്തിന്, /dev/urandom ഉപയോഗിച്ച് RC4 വിത്ത്, അതിൽ നിന്ന് ഒരു വ്യാജ-റാൻഡം സ്ട്രീം സൃഷ്ടിക്കുന്നത് നല്ലതാണ്. ഒരു ലളിതമായ പരിഹാരത്തിൽ മൈക്രോസെക്കൻഡ് റെസല്യൂഷനിലെ യുണിക്സ് സമയവും ക്ലയന്റ് ഐഡിയും സംയോജിപ്പിച്ച് ഉൾപ്പെടുന്നു; ഇത് അത്ര സുരക്ഷിതമല്ല, പക്ഷേ മിക്ക സന്ദർഭങ്ങളിലും ഇത് ചുമതലയെ ആശ്രയിച്ചിരിക്കും.

കീയുടെ ആയുസ്സിന്റെ അളവുകോലായി നമ്മൾ ഉപയോഗിക്കുന്ന സമയത്തെ "ലോക്ക് ലൈഫ് ടൈം" എന്ന് വിളിക്കുന്നു. ഈ മൂല്യം, ലോക്ക് സ്വയമേവ റിലീസ് ചെയ്യപ്പെടുന്നതിന് മുമ്പുള്ള സമയവും ഒരു ക്ലയന്റ് ഒരു ഓപ്പറേഷൻ പൂർത്തിയാക്കേണ്ട സമയവും ആണ്. ലോക്ക് വാങ്ങിയ നിമിഷം മുതൽ ആരംഭിക്കുന്ന ഒരു നിശ്ചിത സമയ വിൻഡോയിൽ മാത്രം ഈ ഗ്യാരന്റി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു.

അതിനാൽ ഒരു ലോക്ക് ഏറ്റെടുക്കുന്നതിനും റിലീസ് ചെയ്യുന്നതിനുമുള്ള ഒരു നല്ല മാർഗം ഞങ്ങൾ ചർച്ച ചെയ്തു. സിസ്റ്റം (ഞങ്ങൾ ഒരു നോൺ-ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റത്തെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, എല്ലായ്പ്പോഴും ലഭ്യമായ ഒരു ഉദാഹരണം ഉൾക്കൊള്ളുന്നു) സുരക്ഷിതമാണ്. നമുക്ക് ഈ ആശയം ഒരു വിതരണ സംവിധാനത്തിലേക്ക് വ്യാപിപ്പിക്കാം, അവിടെ ഞങ്ങൾക്ക് അത്തരം ഗ്യാരണ്ടികളൊന്നുമില്ല.

റെഡ്ലോക്ക് അൽഗോരിതം

ഞങ്ങൾക്ക് N Redis മാസ്റ്റേഴ്സ് ഉണ്ടെന്ന് അൽഗോരിതത്തിന്റെ വിതരണം ചെയ്ത പതിപ്പ് അനുമാനിക്കുന്നു. ഈ നോഡുകൾ പരസ്പരം പൂർണ്ണമായും സ്വതന്ത്രമാണ്, അതിനാൽ ഞങ്ങൾ റെപ്ലിക്കേഷനോ മറ്റേതെങ്കിലും വ്യക്തമായ ഏകോപന സംവിധാനമോ ഉപയോഗിക്കുന്നില്ല. ഒരൊറ്റ സന്ദർഭത്തിൽ ഒരു ലോക്ക് എങ്ങനെ സുരക്ഷിതമായി സ്വന്തമാക്കാമെന്നും റിലീസ് ചെയ്യാമെന്നും ഞങ്ങൾ ഇതിനകം ചർച്ച ചെയ്തിട്ടുണ്ട്. അൽഗോരിതം, ഒരൊറ്റ ഉദാഹരണത്തിൽ പ്രവർത്തിക്കുമ്പോൾ, ഈ രീതി കൃത്യമായി ഉപയോഗിക്കുമെന്നത് ഞങ്ങൾ നിസ്സാരമായി കാണുന്നു. ഞങ്ങളുടെ ഉദാഹരണങ്ങളിൽ ഞങ്ങൾ N-നെ 5 ആയി സജ്ജീകരിച്ചു, ഇത് ന്യായമായ മൂല്യമാണ്. അതിനാൽ, വ്യത്യസ്ത കമ്പ്യൂട്ടറുകളിലോ വെർച്വൽ മെഷീനുകളിലോ ഞങ്ങൾ 5 റെഡിസ് മാസ്റ്ററുകൾ ഉപയോഗിക്കേണ്ടതുണ്ട്, അവ പരസ്പരം സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ.

ഒരു ലോക്ക് നേടുന്നതിന്, ക്ലയന്റ് ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങൾ ചെയ്യുന്നു:

1. നിലവിലെ സമയം മില്ലിസെക്കൻഡിൽ ലഭിക്കും.
2. എല്ലാ കേസുകളിലും ഒരേ കീ നാമവും ക്രമരഹിതമായ മൂല്യങ്ങളും ഉപയോഗിച്ച് എല്ലാ N സംഭവങ്ങളിലും ഒരു ലോക്ക് നേടാൻ തുടർച്ചയായി ശ്രമിക്കുന്നു. ഘട്ടം 2-ൽ, ഓരോ സന്ദർഭത്തിലും ക്ലയന്റ് ഒരു ലോക്ക് സജ്ജീകരിക്കുമ്പോൾ, ലോക്ക് സ്വയമേവ റിലീസ് ചെയ്യുന്ന സമയവുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ക്ലയന്റ് അത് സ്വന്തമാക്കാൻ കാലതാമസം ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, തടയൽ ദൈർഘ്യം 10 ​​സെക്കൻഡ് ആണെങ്കിൽ, കാലതാമസം ~5-50 മില്ലിസെക്കൻഡ് പരിധിയിലായിരിക്കാം. ഒരു പരാജയപ്പെട്ട Redis നോഡിലെത്താൻ ശ്രമിക്കുന്ന ക്ലയന്റ് ദീർഘനേരം തടഞ്ഞുനിൽക്കുന്ന സാഹചര്യം ഇത് ഇല്ലാതാക്കുന്നു: ഉദാഹരണം ലഭ്യമല്ലെങ്കിൽ, ഞങ്ങൾ എത്രയും വേഗം മറ്റൊരു സംഭവത്തിലേക്ക് കണക്റ്റുചെയ്യാൻ ശ്രമിക്കുന്നു.
3. ഒരു ലോക്ക് എടുക്കാൻ, ക്ലയന്റ് എത്ര സമയം കഴിഞ്ഞുവെന്ന് കണക്കാക്കുന്നു; ഇത് ചെയ്യുന്നതിന്, ഇത് ഘട്ടം 1-ൽ ലഭിച്ച ടൈംസ്റ്റാമ്പ് യഥാർത്ഥ സമയ മൂല്യത്തിൽ നിന്ന് കുറയ്ക്കുന്നു. ഭൂരിഭാഗം സന്ദർഭങ്ങളിലും (കുറഞ്ഞത് 3) ലോക്ക് നേടാൻ ക്ലയന്റിന് കഴിഞ്ഞെങ്കിൽ മാത്രം, അതിന് എടുത്ത മൊത്തം സമയവും ലോക്ക് നേടുക, ലോക്ക് കാലാവധിയേക്കാൾ കുറവ്, ലോക്ക് ലഭിച്ചതായി കണക്കാക്കുന്നു.
4. ഒരു ലോക്ക് ലഭിച്ചിട്ടുണ്ടെങ്കിൽ, ലോക്ക് ദൈർഘ്യം യഥാർത്ഥ ലോക്ക് ദൈർഘ്യമായി കണക്കാക്കുന്നു, ഘട്ടം 3-ൽ കണക്കാക്കിയ കഴിഞ്ഞ സമയം.
5. ചില കാരണങ്ങളാൽ ക്ലയന്റ് ലോക്ക് നേടുന്നതിൽ പരാജയപ്പെട്ടാൽ (ഒന്നുകിൽ അതിന് N/2+1 ഇൻസ്‌റ്റൻസുകൾ ലോക്ക് ചെയ്യാൻ കഴിഞ്ഞില്ല, അല്ലെങ്കിൽ ലോക്ക് ദൈർഘ്യം നെഗറ്റീവായിരുന്നു), തുടർന്ന് അത് എല്ലാ സന്ദർഭങ്ങളും (അത് തടയാൻ കഴിയില്ലെന്ന് കരുതിയവ പോലും) അൺലോക്ക് ചെയ്യാൻ ശ്രമിക്കും. ).

അൽഗോരിതം അസമന്വിതമാണോ?

എല്ലാ പ്രക്രിയകളും പ്രവർത്തിക്കുന്ന സമന്വയിപ്പിച്ച ക്ലോക്ക് ഇല്ലെങ്കിലും, ഓരോ പ്രക്രിയയിലും പ്രാദേശിക സമയം ഏകദേശം ഒരേ വേഗതയിൽ ഒഴുകുന്നു, കൂടാതെ ലോക്ക് ചെയ്തതിന് ശേഷമുള്ള മൊത്തം സമയവുമായി താരതമ്യം ചെയ്യുമ്പോൾ പിശക് ചെറുതാണ് എന്ന അനുമാനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഈ അൽഗോരിതം. സ്വയമേവ റിലീസ് ചെയ്തു. ഈ അനുമാനം സാധാരണ കമ്പ്യൂട്ടറുകളുടെ സാധാരണ അവസ്ഥയുമായി വളരെ സാമ്യമുള്ളതാണ്: ഓരോ കമ്പ്യൂട്ടറിനും ഒരു പ്രാദേശിക ക്ലോക്ക് ഉണ്ട്, കൂടാതെ വ്യത്യസ്ത കമ്പ്യൂട്ടറുകൾ തമ്മിലുള്ള സമയ വ്യത്യാസം ചെറുതാണെന്ന വസ്തുത നമുക്ക് കണക്കാക്കാം.

ഈ ഘട്ടത്തിൽ, ഞങ്ങളുടെ പരസ്പര ഒഴിവാക്കൽ നിയമം കൂടുതൽ ശ്രദ്ധാപൂർവം രൂപപ്പെടുത്തണം: ലോക്ക് സാധുതയുള്ള സമയത്ത് (ഘട്ടം 3-ൽ ലഭിച്ച ഈ മൂല്യം) ലോക്ക് കൈവശം വച്ചിരിക്കുന്ന ക്ലയന്റ് പുറത്തുകടന്നാൽ മാത്രമേ പരസ്പര ഒഴിവാക്കൽ ഉറപ്പുനൽകൂ, കുറച്ച് സമയം കൂടി (ആകെ കുറച്ച് പ്രക്രിയകൾ തമ്മിലുള്ള സമയ വ്യത്യാസം നികത്താൻ മില്ലിസെക്കൻഡ്).

സമയ ഇടവേളകളുടെ ഏകോപനം ആവശ്യമുള്ള അത്തരം സിസ്റ്റങ്ങളെക്കുറിച്ച് ഇനിപ്പറയുന്ന രസകരമായ ലേഖനം കൂടുതൽ പറയുന്നു: ലീസുകൾ: വിതരണം ചെയ്ത ഫയൽ കാഷെ സ്ഥിരതയ്‌ക്കുള്ള കാര്യക്ഷമമായ തെറ്റ്-സഹിഷ്ണുത സംവിധാനം.

പരാജയത്തിൽ വീണ്ടും ശ്രമിക്കുക

ഒരു ലോക്ക് സ്വന്തമാക്കുന്നതിൽ ക്ലയന്റ് പരാജയപ്പെടുമ്പോൾ, ക്രമരഹിതമായ കാലതാമസത്തിന് ശേഷം അത് വീണ്ടും ശ്രമിക്കണം; ഒരേ സമയം ഒരേ റിസോഴ്സിൽ ഒരു ലോക്ക് നേടാൻ ശ്രമിക്കുന്ന ഒന്നിലധികം ക്ലയന്റുകളെ സമന്വയിപ്പിക്കാൻ ഇത് ചെയ്യുന്നു (ഇത് വിജയികളില്ലാത്ത ഒരു "സ്പ്ലിറ്റ് ബ്രെയിൻ" സാഹചര്യത്തിലേക്ക് നയിച്ചേക്കാം). കൂടാതെ, ഭൂരിഭാഗം റെഡിസ് സംഭവങ്ങളിലും ഒരു ക്ലയന്റ് വേഗത്തിൽ ഒരു ലോക്ക് നേടാൻ ശ്രമിക്കുന്നു, ഒരു സ്പ്ലിറ്റ് ബ്രെയിൻ സാഹചര്യം സംഭവിക്കുന്ന വിൻഡോ ഇടുങ്ങിയതാണ് (കൂടാതെ വീണ്ടും ശ്രമിക്കേണ്ടതിന്റെ ആവശ്യകതയും). അതിനാൽ, മൾട്ടിപ്ലക്‌സിംഗ് ഉപയോഗിച്ച് ഒരേസമയം N ഇൻസ്‌റ്റൻസുകളിലേക്ക് SET കമാൻഡുകൾ അയയ്ക്കാൻ ക്ലയന്റ് ശ്രമിക്കേണ്ടതാണ്.

ഭൂരിഭാഗം ലോക്കുകളും നേടുന്നതിൽ പരാജയപ്പെടുന്ന ക്ലയന്റുകൾ (ഭാഗികമായി) ഏറ്റെടുത്ത ലോക്കുകൾ റിലീസ് ചെയ്യുന്നത് എത്ര പ്രധാനമാണെന്ന് ഇവിടെ ഊന്നിപ്പറയേണ്ടതാണ്, അതിനാൽ ഉറവിടത്തിലെ ലോക്ക് വീണ്ടും ഏറ്റെടുക്കുന്നതിന് മുമ്പ് കീ കാലഹരണപ്പെടുന്നതുവരെ കാത്തിരിക്കേണ്ടതില്ല. (നെറ്റ്‌വർക്ക് വിഘടനം സംഭവിക്കുകയും ക്ലയന്റ് Redis സംഭവങ്ങളുമായുള്ള ബന്ധം നഷ്‌ടപ്പെടുകയും ചെയ്‌താൽ, കീ കാലഹരണപ്പെടാൻ കാത്തിരിക്കുമ്പോൾ നിങ്ങൾ ലഭ്യത പിഴ അടയ്‌ക്കേണ്ടി വരും).

ലോക്ക് വിടുക

ഒരു ലോക്ക് റിലീസ് ചെയ്യുന്നത് ക്ലയന്റ് ഒരു പ്രത്യേക സന്ദർഭം വിജയകരമായി പൂട്ടിയതായി തോന്നുന്നുണ്ടോ എന്നത് പരിഗണിക്കാതെ തന്നെ, എല്ലാ സംഭവങ്ങളും അൺലോക്ക് ചെയ്യേണ്ട ഒരു ലളിതമായ പ്രവർത്തനമാണ്.

സുരക്ഷാ പരിഗണനകൾ

അൽഗോരിതം സുരക്ഷിതമാണോ? വ്യത്യസ്ത സാഹചര്യങ്ങളിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് സങ്കൽപ്പിക്കാൻ ശ്രമിക്കാം.

ആരംഭിക്കുന്നതിന്, ക്ലയന്റിന് ഭൂരിഭാഗം സന്ദർഭങ്ങളിലും ഒരു ലോക്ക് നേടാൻ കഴിഞ്ഞുവെന്ന് നമുക്ക് അനുമാനിക്കാം. ഓരോ സംഭവത്തിലും എല്ലാവർക്കും ഒരേ ആയുസ്സ് ഉള്ള ഒരു കീ അടങ്ങിയിരിക്കും. എന്നിരുന്നാലും, ഈ കീകൾ ഓരോന്നും വ്യത്യസ്‌ത സമയത്താണ് ഇൻസ്‌റ്റാൾ ചെയ്‌തിരിക്കുന്നത്, അതിനാൽ അവ വ്യത്യസ്‌ത സമയങ്ങളിൽ കാലഹരണപ്പെടും. പക്ഷേ, ആദ്യത്തെ കീ T1-നേക്കാൾ മോശമല്ലാത്ത സമയത്താണ് ഇൻസ്റ്റാൾ ചെയ്തതെങ്കിൽ (ആദ്യ സെർവറുമായി ബന്ധപ്പെടുന്നതിന് മുമ്പ് ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്ന സമയം), അവസാന കീ T2-നേക്കാൾ മോശമല്ലാത്ത സമയത്താണ് ഇൻസ്റ്റാൾ ചെയ്തതെങ്കിൽ (പ്രതികരണം ലഭിച്ച സമയം അവസാന സെർവറിൽ നിന്ന്), തുടർന്ന് കാലഹരണപ്പെടുന്ന സെറ്റിലെ ആദ്യ കീയെങ്കിലും നിലനിൽക്കുമെന്ന് ഞങ്ങൾക്ക് ഉറപ്പുണ്ട് MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. മറ്റെല്ലാ കീകളും പിന്നീട് കാലഹരണപ്പെടും, അതിനാൽ ഈ സമയത്തേക്കെങ്കിലും എല്ലാ കീകളും ഒരേസമയം സാധുതയുള്ളതായിരിക്കുമെന്ന് ഞങ്ങൾക്ക് ഉറപ്പിക്കാം.

N/2+1 കീകൾ നിലവിലുണ്ടെങ്കിൽ N/2+1 SET NX പ്രവർത്തനങ്ങൾ വിജയിക്കാത്തതിനാൽ, മിക്ക കീകളും സാധുവായി തുടരുന്ന സമയത്ത്, മറ്റൊരു ക്ലയന്റിന് ലോക്ക് സ്വന്തമാക്കാൻ കഴിയില്ല. അതിനാൽ, ഒരിക്കൽ ഒരു ലോക്ക് ഏറ്റെടുത്തുകഴിഞ്ഞാൽ, അതേ നിമിഷത്തിൽ അത് വീണ്ടും സ്വന്തമാക്കുന്നത് അസാധ്യമാണ് (ഇത് പരസ്പര ഒഴിവാക്കൽ സ്വത്ത് ലംഘിക്കും).
എന്നിരുന്നാലും, ഒരേ സമയം ഒരു ലോക്ക് സ്വന്തമാക്കാൻ ശ്രമിക്കുന്ന ഒന്നിലധികം ക്ലയന്റുകൾക്ക് ഒരേ സമയം വിജയിക്കാനാകില്ലെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

പരമാവധി ലോക്ക് കാലയളവിലോ അതിലധികമോ സമയത്തേക്ക് ക്ലയന്റ് ഭൂരിഭാഗം സംഭവങ്ങളും ലോക്ക് ചെയ്‌തിട്ടുണ്ടെങ്കിൽ, അത് ലോക്ക് അസാധുവായി കണക്കാക്കുകയും ഇൻസ്‌റ്റൻസുകൾ അൺലോക്ക് ചെയ്യുകയും ചെയ്യും. അതിനാൽ, കാലഹരണപ്പെടൽ തീയതിയേക്കാൾ കുറഞ്ഞ സമയത്തിനുള്ളിൽ ഭൂരിഭാഗം സംഭവങ്ങളും ബ്ലോക്ക് ചെയ്യാൻ ക്ലയന്റ് കൈകാര്യം ചെയ്ത കേസ് മാത്രമേ ഞങ്ങൾ കണക്കിലെടുക്കേണ്ടതുള്ളൂ. ഈ സാഹചര്യത്തിൽ, മേൽപ്പറഞ്ഞ വാദത്തെ സംബന്ധിച്ച്, സമയത്ത് MIN_VALIDITY ഒരു ക്ലയന്റിനും ലോക്ക് വീണ്ടെടുക്കാൻ കഴിയില്ല. അതിനാൽ, ഭൂരിഭാഗം ലോക്ക് ചെയ്യാനുള്ള സമയം TTL സമയത്തേക്കാൾ കൂടുതലാണെങ്കിൽ മാത്രമേ പല ക്ലയന്റുകൾക്കും ഒരേ സമയം N/2+1 ഇൻസ്‌റ്റൻസുകൾ ലോക്ക് ചെയ്യാൻ കഴിയൂ (അത് ഘട്ടം 2-ന്റെ അവസാനത്തിൽ അവസാനിക്കും).

നിങ്ങൾക്ക് സുരക്ഷയുടെ ഔപചാരിക തെളിവ് നൽകാമോ, നിലവിലുള്ള സമാന അൽഗോരിതങ്ങൾ സൂചിപ്പിക്കാമോ, അല്ലെങ്കിൽ മുകളിൽ പറഞ്ഞതിൽ ഒരു ബഗ് കണ്ടെത്താമോ?

പ്രവേശനക്ഷമത പരിഗണനകൾ

സിസ്റ്റം ലഭ്യത മൂന്ന് പ്രധാന സവിശേഷതകളെ ആശ്രയിച്ചിരിക്കുന്നു:

1. ലോക്കുകൾ സ്വയമേവ റിലീസ് ചെയ്യുക (കീകൾ കാലഹരണപ്പെടുമ്പോൾ): ലോക്കുകൾക്കായി ഉപയോഗിക്കുന്നതിന് കീകൾ ഒടുവിൽ വീണ്ടും ലഭ്യമാകും.
2. ആവശ്യമുള്ള ലോക്ക് ലഭിക്കാതെ വരുമ്പോൾ, അല്ലെങ്കിൽ ഏറ്റെടുക്കുകയും ജോലി പൂർത്തിയാക്കുകയും ചെയ്യുമ്പോൾ, ക്ലയന്റുകൾ സാധാരണയായി ലോക്കുകൾ നീക്കം ചെയ്തുകൊണ്ട് പരസ്പരം സഹായിക്കുന്നു എന്ന വസ്തുത; അതിനാൽ ലോക്ക് വീണ്ടെടുക്കാൻ കീകൾ കാലഹരണപ്പെടുന്നതുവരെ കാത്തിരിക്കേണ്ടി വരില്ല.
3. ഒരു ക്ലയന്റ് ഒരു ലോക്ക് സ്വന്തമാക്കാൻ വീണ്ടും ശ്രമിക്കേണ്ടിവരുമ്പോൾ, മിക്ക ലോക്കുകളും സ്വന്തമാക്കാൻ ആവശ്യമായ കാലയളവിനേക്കാൾ താരതമ്യേന കൂടുതൽ സമയത്തേക്ക് അത് കാത്തിരിക്കുന്നു എന്നതാണ് വസ്തുത. ഇത് വിഭവങ്ങൾക്കായി മത്സരിക്കുമ്പോൾ തലച്ചോറിന്റെ പിളർപ്പ് സംഭവിക്കാനുള്ള സാധ്യത കുറയ്ക്കുന്നു.

എന്നിരുന്നാലും, നെറ്റ്‌വർക്ക് സെഗ്‌മെന്റുകളുടെ TTL-ന് തുല്യമായ ലഭ്യത പെനാൽറ്റി ഉണ്ട്, അതിനാൽ തുടർച്ചയായ സെഗ്‌മെന്റുകൾ ഉണ്ടെങ്കിൽ, പിഴ അനിശ്ചിതമായേക്കാം. ഒരു ക്ലയന്റ് ഒരു ലോക്ക് സ്വന്തമാക്കുകയും അത് റിലീസ് ചെയ്യുന്നതിന് മുമ്പ് മറ്റൊരു സെഗ്‌മെന്റിലേക്ക് കീറുകയും ചെയ്യുമ്പോഴെല്ലാം ഇത് സംഭവിക്കുന്നു.

തത്വത്തിൽ, അനന്തമായ തുടർച്ചയായ നെറ്റ്‌വർക്ക് സെഗ്‌മെന്റുകൾ നൽകിയാൽ, ഒരു സിസ്റ്റം അനന്തമായ കാലയളവിലേക്ക് ലഭ്യമല്ലാതാകും.

പ്രകടനം, പരാജയം, fsync

ലോക്കുകൾ ഏറ്റെടുക്കുന്നതിനും റിലീസ് ചെയ്യുന്നതിനും ആവശ്യമായ ലേറ്റൻസിയും സെക്കൻഡിൽ പൂർത്തിയാക്കാൻ കഴിയുന്ന ഏറ്റെടുക്കലുകളുടെ/റിലീസുകളുടെ എണ്ണവും കണക്കിലെടുത്ത് ഉയർന്ന ലോക്ക് സെർവർ പ്രകടനം ആവശ്യമുള്ളതിനാൽ പലരും Redis ഉപയോഗിക്കുന്നു. ഈ ആവശ്യകത നിറവേറ്റുന്നതിന്, ലേറ്റൻസി കുറയ്ക്കുന്നതിന് N Redis സെർവറുകളുമായി ആശയവിനിമയം നടത്തുന്നതിനുള്ള ഒരു തന്ത്രമുണ്ട്. ഇതൊരു മൾട്ടിപ്ലക്‌സിംഗ് തന്ത്രമാണ് (അല്ലെങ്കിൽ "പാവങ്ങളുടെ മൾട്ടിപ്ലക്‌സിംഗ്", അവിടെ സോക്കറ്റ് നോൺ-ബ്ലോക്കിംഗ് മോഡിൽ ഇടുകയും എല്ലാ കമാൻഡുകളും അയയ്ക്കുകയും പിന്നീട് കമാൻഡുകൾ വായിക്കുകയും ചെയ്യുന്നു, ക്ലയന്റിനും ഓരോ സംഭവത്തിനും ഇടയിലുള്ള റൗണ്ട്-ട്രിപ്പ് സമയം സമാനമാണെന്ന് കരുതുക) .

എന്നിരുന്നാലും, പരാജയങ്ങളിൽ നിന്ന് വിശ്വസനീയമായ വീണ്ടെടുക്കൽ ഉള്ള ഒരു മോഡൽ സൃഷ്ടിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുകയാണെങ്കിൽ ദീർഘകാല ഡാറ്റ സംഭരണവുമായി ബന്ധപ്പെട്ട പരിഗണനയും ഞങ്ങൾ കണക്കിലെടുക്കേണ്ടതുണ്ട്.

അടിസ്ഥാനപരമായി, പ്രശ്നം വ്യക്തമാക്കുന്നതിന്, ദീർഘകാല ഡാറ്റ സംഭരണം ഇല്ലാതെയാണ് ഞങ്ങൾ Redis കോൺഫിഗർ ചെയ്യുന്നത് എന്ന് കരുതുക. ക്ലയന്റ് 3 ൽ 5 ഇൻസ്‌റ്റൻസുകൾ ബ്ലോക്ക് ചെയ്യാൻ കൈകാര്യം ചെയ്യുന്നു. ക്ലയന്റ് തടയാൻ കഴിഞ്ഞ ഒരു സന്ദർഭം പുനരാരംഭിച്ചു, ഇപ്പോൾ അതേ ഉറവിടത്തിനായി വീണ്ടും 3 സംഭവങ്ങളുണ്ട്, അത് ഞങ്ങൾക്ക് തടയാൻ കഴിയും, കൂടാതെ മറ്റൊരു ക്ലയന്റിന് പുനരാരംഭിച്ച സംഭവം തടയാനും സുരക്ഷാ പ്രോപ്പർട്ടി ലംഘിക്കാനും കഴിയും. ലോക്കുകളുടെ പ്രത്യേകത അനുമാനിക്കുന്നു.

നിങ്ങൾ ഡാറ്റ മുന്നോട്ട് (AOF) പ്രാപ്തമാക്കുകയാണെങ്കിൽ, സ്ഥിതി അൽപ്പം മെച്ചപ്പെടും. ഉദാഹരണത്തിന്, SHUTDOWN കമാൻഡ് അയച്ച് അത് പുനരാരംഭിക്കുന്നതിലൂടെ നിങ്ങൾക്ക് ഒരു സെർവർ പ്രൊമോട്ട് ചെയ്യാം. റെഡിസിലെ കാലഹരണപ്പെടൽ പ്രവർത്തനങ്ങൾ സെർവർ ഓഫായിരിക്കുമ്പോഴും സമയം ഒഴുകുന്നത് തുടരുന്ന തരത്തിൽ അർത്ഥപരമായി നടപ്പിലാക്കിയിരിക്കുന്നതിനാൽ, ഞങ്ങളുടെ എല്ലാ ആവശ്യങ്ങളും ശരിയാണ്. ഒരു സാധാരണ ഷട്ട്ഡൗൺ ഉറപ്പാക്കുന്നിടത്തോളം ഇത് സാധാരണമാണ്. വൈദ്യുതി മുടങ്ങിയാൽ എന്തുചെയ്യണം? റെഡിസ് ഡിഫോൾട്ടായി ക്രമീകരിച്ചിട്ടുണ്ടെങ്കിൽ, ഓരോ സെക്കൻഡിലും ഡിസ്കിൽ fsync സമന്വയിപ്പിച്ച്, പുനരാരംഭിച്ചതിന് ശേഷം നമ്മുടെ കീ ഉണ്ടാകാൻ സാധ്യതയുണ്ട്. സൈദ്ധാന്തികമായി, ഏതെങ്കിലും സാഹചര്യത്തിൽ പുനരാരംഭിക്കുമ്പോൾ ലോക്ക് സുരക്ഷ ഉറപ്പ് നൽകാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ പ്രവർത്തനക്ഷമമാക്കണം fsync=always ദീർഘകാല ഡാറ്റ സംഭരണത്തിനുള്ള ക്രമീകരണങ്ങളിൽ. വിതരണം ചെയ്ത ലോക്കുകൾ സുരക്ഷിതമായി നടപ്പിലാക്കാൻ പരമ്പരാഗതമായി ഉപയോഗിക്കുന്ന സിപി സിസ്റ്റങ്ങളുടെ നിലവാരം വരെ ഇത് പ്രകടനത്തെ പൂർണ്ണമായും ഇല്ലാതാക്കും.

എന്നാൽ ഒറ്റനോട്ടത്തിൽ തോന്നുന്നതിനേക്കാൾ മികച്ചതാണ് സാഹചര്യം. തത്ത്വത്തിൽ, അൽഗോരിതത്തിന്റെ സുരക്ഷ സംരക്ഷിക്കപ്പെടുന്നു, കാരണം ഒരു പരാജയത്തിന് ശേഷം ഇൻസ്റ്റൻസ് പുനരാരംഭിക്കുമ്പോൾ, നിലവിൽ സജീവമായ ഒരു ലോക്കിലും അത് ഇനി പങ്കെടുക്കില്ല.

ഇത് ഉറപ്പാക്കാൻ, ഒരു പരാജയത്തിന് ശേഷം ഞങ്ങൾ ഉപയോഗിക്കുന്ന പരമാവധി TTL-നേക്കാൾ അല്പം കവിയുന്ന സമയത്തേക്ക് ഈ ഉദാഹരണം ലഭ്യമല്ലെന്ന് ഉറപ്പാക്കേണ്ടതുണ്ട്. ഈ രീതിയിൽ, പരാജയസമയത്ത് സജീവമായിരുന്ന എല്ലാ കീകളുടെയും കാലഹരണ തീയതിയും യാന്ത്രിക റിലീസും വരെ ഞങ്ങൾ കാത്തിരിക്കും.

കാലതാമസം വരുത്തിയ പുനരാരംഭങ്ങൾ ഉപയോഗിച്ച്, Redis-ൽ ദീർഘകാല സ്ഥിരത ഇല്ലെങ്കിൽപ്പോലും സുരക്ഷിതത്വം കൈവരിക്കാൻ തത്വത്തിൽ സാധ്യമാണ്. എന്നിരുന്നാലും, പ്രവേശനക്ഷമത ലംഘിച്ചതിന് ഇത് പിഴയ്ക്ക് കാരണമായേക്കാമെന്ന് ശ്രദ്ധിക്കുക. ഉദാഹരണത്തിന്, ഭൂരിഭാഗം സംഭവങ്ങളും പരാജയപ്പെടുകയാണെങ്കിൽ, TTL-ന് സിസ്റ്റം ആഗോളതലത്തിൽ ലഭ്യമല്ലാതാകും (ഈ സമയത്ത് ഒരു റിസോഴ്സും തടയാൻ കഴിയില്ല).

ഞങ്ങൾ അൽഗോരിതത്തിന്റെ ലഭ്യത വർദ്ധിപ്പിക്കുന്നു: ഞങ്ങൾ തടയൽ നീട്ടുന്നു

ക്ലയന്റുകൾ നിർവഹിക്കുന്ന ജോലിയിൽ ചെറിയ ഘട്ടങ്ങളുണ്ടെങ്കിൽ, ഡിഫോൾട്ട് ലോക്ക് ദൈർഘ്യം കുറയ്ക്കാനും ലോക്കുകൾ നീട്ടുന്നതിനുള്ള ഒരു സംവിധാനം നടപ്പിലാക്കാനും സാധിക്കും. തത്വത്തിൽ, ക്ലയന്റ് കമ്പ്യൂട്ടിംഗിൽ തിരക്കിലാണെങ്കിൽ ലോക്ക് കാലഹരണപ്പെടൽ മൂല്യം അപകടകരമാംവിധം കുറവാണെങ്കിൽ, കീ നിലവിലുണ്ടെങ്കിൽ, അതിന്റെ മൂല്യം ഇപ്പോഴും ക്രമരഹിതമായ മൂല്യമാണെങ്കിൽ, കീയുടെ TTL നീട്ടുന്ന എല്ലാ സന്ദർഭങ്ങളിലേക്കും നിങ്ങൾക്ക് Lua സ്ക്രിപ്റ്റ് അയയ്ക്കാൻ കഴിയും. ലോക്ക് ഏറ്റെടുത്തു.

സാധുതയുള്ള കാലയളവിനുള്ളിൽ ഭൂരിഭാഗം സംഭവങ്ങളും ലോക്ക് ചെയ്യാൻ കഴിഞ്ഞാൽ മാത്രമേ ഒരു ലോക്ക് വീണ്ടെടുക്കാൻ ക്ലയന്റ് പരിഗണിക്കാവൂ.

ശരിയാണ്, സാങ്കേതികമായി അൽഗോരിതം മാറില്ല, അതിനാൽ ലോക്കുകൾ നേടുന്നതിനുള്ള പരമാവധി ആവർത്തിച്ചുള്ള ശ്രമങ്ങൾ പരിമിതപ്പെടുത്തിയിരിക്കണം, അല്ലാത്തപക്ഷം പ്രവേശനക്ഷമത സവിശേഷതകൾ ലംഘിക്കപ്പെടും.

അവലംബം: www.habr.com