રેડિસનો ઉપયોગ કરીને વિતરિત લોકીંગ

હે હબર!

આજે અમે તમારા ધ્યાન પર રેડિસનો ઉપયોગ કરીને ડિસ્ટ્રિબ્યુટેડ લૉકિંગના અમલીકરણ વિશેના જટિલ લેખનો અનુવાદ લાવીએ છીએ અને તમને એક વિષય તરીકે રેડિસની સંભાવનાઓ વિશે વાત કરવા માટે આમંત્રિત કરીએ છીએ. પુસ્તકના લેખક માર્ટિન ક્લેપમેનના પ્રશ્નમાં રેડલોક અલ્ગોરિધમનું વિશ્લેષણ "ઉચ્ચ લોડ કાર્યક્રમો", આપેલ અહીં.

ડિસ્ટ્રિબ્યુટેડ લોકીંગ એ ઘણા પર્યાવરણોમાં ઉપયોગમાં લેવાતું ખૂબ જ ઉપયોગી આદિમ છે જ્યાં વિવિધ પ્રક્રિયાઓએ પરસ્પર વિશિષ્ટ રીતે વહેંચાયેલ સંસાધનો પર કામ કરવું જોઈએ.

રેડિસનો ઉપયોગ કરીને DLM (ડિસ્ટ્રિબ્યુટેડ લૉક મેનેજર) ને કેવી રીતે અમલમાં મૂકવું તેનું વર્ણન કરતી સંખ્યાબંધ લાઇબ્રેરીઓ અને પોસ્ટ્સ છે, પરંતુ દરેક લાઇબ્રેરી અલગ અભિગમ અપનાવે છે અને તેઓ જે ગેરંટી આપે છે તે થોડી વધુ અત્યાધુનિક ડિઝાઇન સાથે પ્રાપ્ત કરી શકાય તેવી સરખામણીમાં ખૂબ નબળી છે.

આ લેખમાં અમે શરતી પ્રમાણભૂત અલ્ગોરિધમનું વર્ણન કરવાનો પ્રયાસ કરીશું જે દર્શાવે છે કે રેડિસનો ઉપયોગ કરીને ડિસ્ટ્રિબ્યુટેડ લૉકિંગને કેવી રીતે અમલમાં મૂકવું. અમે અલ્ગોરિધમ નામની વાત કરીશું રેડલોક, તે વિતરિત લોક મેનેજરનો અમલ કરે છે અને અમારા મતે, આ અલ્ગોરિધમ સામાન્ય સિંગલ-ઇન્સ્ટન્સ અભિગમ કરતાં વધુ સુરક્ષિત છે. અમે આશા રાખીએ છીએ કે સમુદાય તેનું વિશ્લેષણ કરશે, પ્રતિસાદ આપશે અને વધુ જટિલ અથવા વૈકલ્પિક પ્રોજેક્ટ્સ માટે પ્રારંભિક બિંદુ તરીકે તેનો ઉપયોગ કરશે.

અમલીકરણ

અલ્ગોરિધમના વર્ણન પર આગળ વધતા પહેલા, અમે તૈયાર અમલીકરણની ઘણી લિંક્સ પ્રદાન કરીએ છીએ. તેઓ સંદર્ભ માટે વાપરી શકાય છે.

• રેડલોક-આરબી (રૂબી માટે અમલીકરણ). ત્યાં પણ છે કાંટો Redlock-rb, જે વિતરણની સરળતા માટે પેકેજ (મણિ) ઉમેરે છે, અને માત્ર તેના માટે જ નહીં.
• રેડલોક-પાય (પાયથોન અમલીકરણ).
• Aioredlock (Asyncio Python માટે અમલીકરણ).
• રેડલોક-php (PHP માટે અમલીકરણ).
• PHPRedisMutex (PHP માટે અન્ય અમલીકરણ)
• cheprasov/php-redis-lock (તાળાઓ માટે PHP લાઇબ્રેરી)
• રેડસિંક (ગો માટે અમલીકરણ).
• રેડિસન (જાવા માટે અમલીકરણ).
• Redis::DistLock (પર્લ માટે અમલીકરણ).
• રેડલોક-સીપીપી (C++ માટે અમલીકરણ).
• રેડલોક-સી.એસ (C#/.NET માટે અમલીકરણ).
• RedLock.net (C#/.NET માટે અમલીકરણ). અસિંક અને લૉક એક્સટેન્શન માટે સપોર્ટ સાથે.
• સ્કાર્લેટલોક (રૂપરેખાંકિત ડેટા સ્ટોર સાથે C# .NET માટે અમલીકરણ)
• રેડલોક 4 નેટ (C# .NET માટે અમલીકરણ)
• નોડ-રેડલોક (નોડજેએસ માટે અમલીકરણ). લૉક્સને લંબાવવા માટે સપોર્ટનો સમાવેશ થાય છે.

સુરક્ષા અને ઉપલબ્ધતા ગેરંટી

અમે અમારી ડિઝાઈનને માત્ર ત્રણ પ્રોપર્ટીઝ સાથે મૉડલ કરવા જઈ રહ્યા છીએ જે અમને લાગે છે કે ડિસ્ટ્રિબ્યુટેડ લૉકિંગનો અસરકારક રીતે ઉપયોગ કરવા માટે જરૂરી ન્યૂનતમ ગેરંટી પૂરી પાડે છે.

1. સુરક્ષા મિલકત: પરસ્પર બાકાત. કોઈપણ સમયે, ફક્ત એક ક્લાયંટ લોકને પકડી શકે છે.
2. પ્રાપ્યતા મિલકત A: કોઈ મડાગાંઠ નથી. આખરે લૉક મેળવવું હંમેશા શક્ય છે, પછી ભલે તે ક્લાયન્ટ કે જેણે સંસાધનને લૉક કર્યું હોય તે નિષ્ફળ જાય અથવા અલગ ડિસ્ક સેગમેન્ટ પર ઉતરે.
3. પ્રાપ્યતા મિલકત B: દોષ સહનશીલતા. જ્યાં સુધી મોટાભાગના રેડિસ નોડ્સ ચાલી રહ્યા છે, ત્યાં સુધી ક્લાયન્ટ્સ તાળાઓ મેળવવા અને રિલીઝ કરવામાં સક્ષમ છે.

શા માટે નિષ્ફળતા પુનઃપ્રાપ્તિ પર આધારિત અમલીકરણ આ કિસ્સામાં પૂરતું નથી
અમે શું સુધારવા જઈ રહ્યા છીએ તે સમજવા માટે, ચાલો Redis પર આધારિત મોટાભાગની વિતરિત લૉકિંગ લાઇબ્રેરીઓ સાથેની વર્તમાન સ્થિતિનું વિશ્લેષણ કરીએ.

Redis નો ઉપયોગ કરીને સંસાધનને લોક કરવાની સૌથી સરળ રીત એ છે કે ઉદાહરણમાં કી બનાવવી. સામાન્ય રીતે, કી મર્યાદિત જીવનકાળ સાથે બનાવવામાં આવે છે, આ Redis માં પ્રદાન કરેલ સમાપ્તિ સુવિધાનો ઉપયોગ કરીને પ્રાપ્ત થાય છે, તેથી વહેલા કે પછી આ કી રીલીઝ થાય છે (અમારી સૂચિમાં મિલકત 2). જ્યારે ક્લાયંટને સંસાધન છોડવાની જરૂર હોય, ત્યારે તે કી કાઢી નાખે છે.

પ્રથમ નજરમાં, આ ઉકેલ ખૂબ સારી રીતે કામ કરે છે, પરંતુ એક સમસ્યા છે: આપણું આર્કિટેક્ચર નિષ્ફળતાના એક બિંદુ બનાવે છે. જો યજમાન Redis ઉદાહરણ નિષ્ફળ જાય તો શું થશે? ચાલો પછી એક ગુલામ ઉમેરીએ! અને જો પ્રસ્તુતકર્તા અનુપલબ્ધ હોય તો અમે તેનો ઉપયોગ કરીશું. કમનસીબે, આ વિકલ્પ વ્યવહારુ નથી. આ કરવાથી, અમે સુરક્ષા સુનિશ્ચિત કરવા માટે જરૂરી મ્યુચ્યુઅલ એક્સક્લુઝન પ્રોપર્ટીનો યોગ્ય રીતે અમલ કરી શકીશું નહીં, કારણ કે રેડિસમાં પ્રતિકૃતિ અસુમેળ છે.

દેખીતી રીતે, આવા મોડેલમાં રેસની સ્થિતિ જોવા મળે છે:

1. ક્લાયન્ટ A માસ્ટર પર લોક મેળવે છે.
2. ચાવીની એન્ટ્રી સ્લેવને ટ્રાન્સફર થાય તે પહેલાં માસ્ટર નિષ્ફળ જાય છે.
3. અનુયાયીને નેતા તરીકે બઢતી આપવામાં આવે છે.
4. ક્લાયન્ટ B એ જ સંસાધન પર લૉક મેળવે છે જે A એ પહેલેથી લૉક કર્યું છે. સુરક્ષા ઉલ્લંઘન!

કેટલીકવાર તે સંપૂર્ણપણે સામાન્ય છે કે ખાસ સંજોગોમાં, જેમ કે નિષ્ફળતા, ઘણા ગ્રાહકો એક જ સમયે લોકને પકડી શકે છે. આવા કિસ્સાઓમાં, પ્રતિકૃતિ આધારિત ઉકેલ લાગુ કરી શકાય છે. નહિંતર, અમે આ લેખમાં વર્ણવેલ ઉકેલની ભલામણ કરીએ છીએ.

એક જ ઉદાહરણ સાથે યોગ્ય અમલીકરણ

ઉપર વર્ણવેલ સિંગલ-ઇન્સ્ટન્સ રૂપરેખાંકનની ખામીઓને દૂર કરવાનો પ્રયાસ કરતા પહેલા, ચાલો સમજીએ કે આ સરળ કેસને કેવી રીતે યોગ્ય રીતે હેન્ડલ કરવું, કારણ કે આ સોલ્યુશન વાસ્તવમાં એપ્લીકેશનમાં માન્ય છે જ્યાં રેસની સ્થિતિ સમયાંતરે સ્વીકાર્ય હોય છે, અને એ પણ કારણ કે બ્લોકિંગ સિંગલ ઇન્સ્ટન્સ એ આધાર તરીકે સેવા આપે છે જેનો ઉપયોગ અહીં વર્ણવેલ વિતરિત અલ્ગોરિધમમાં થાય છે.

લોક મેળવવા માટે, આ કરો:

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 સાથે સીડ કરવું અને પછી તેમાંથી સ્યુડો-રેન્ડમ સ્ટ્રીમ જનરેટ કરવું સારું રહેશે. એક સરળ ઉકેલમાં માઇક્રોસેકન્ડ રિઝોલ્યુશન વત્તા ક્લાયન્ટ IDમાં યુનિક્સ સમયનું સંયોજન સામેલ છે; તે એટલું સુરક્ષિત નથી, પરંતુ મોટા ભાગના સંદર્ભોમાં તે કદાચ કાર્ય પર આધારિત છે.

ચાવીના જીવનકાળના માપ તરીકે આપણે જે સમયનો ઉપયોગ કરીએ છીએ તેને "લોક જીવનકાળ" કહેવામાં આવે છે. આ મૂલ્ય, લોક આપમેળે રીલીઝ થાય તે પહેલાનો સમય અને અન્ય ક્લાયંટ તે સંસાધનને લોક કરી શકે તે પહેલાં ક્લાયંટને ઓપરેશન પૂર્ણ કરવા માટેનો સમય બંને છે, વાસ્તવમાં પરસ્પર બાકાતની બાંયધરીનું ઉલ્લંઘન કર્યા વિના. આ ગેરેંટી માત્ર અમુક ચોક્કસ સમય સુધી મર્યાદિત છે, જે લૉક ખરીદવાની ક્ષણથી શરૂ થાય છે.

તેથી અમે લોક હસ્તગત કરવા અને છોડવાની સારી રીતની ચર્ચા કરી છે. સિસ્ટમ (જો આપણે બિન-વિતરિત સિસ્ટમ વિશે વાત કરી રહ્યા છીએ જેમાં સિંગલ અને હંમેશા ઉપલબ્ધ છે) સુરક્ષિત છે. ચાલો આ ખ્યાલને વિતરિત સિસ્ટમ સુધી વિસ્તારીએ, જ્યાં અમારી પાસે આવી કોઈ ગેરંટી નથી.

રેડલોક એલ્ગોરિધમ

અલ્ગોરિધમનું વિતરિત સંસ્કરણ ધારે છે કે અમારી પાસે N Redis માસ્ટર્સ છે. આ ગાંઠો એકબીજાથી સંપૂર્ણપણે સ્વતંત્ર છે, તેથી અમે પ્રતિકૃતિ અથવા અન્ય કોઈપણ ગર્ભિત સંકલન પ્રણાલીનો ઉપયોગ કરતા નથી. અમે પહેલેથી જ આવરી લીધું છે કે કેવી રીતે સુરક્ષિત રીતે એક જ ઇન્સ્ટન્સ પર લૉક મેળવવું અને રિલીઝ કરવું. અમે તેને ધ્યાનમાં લઈએ છીએ કે અલ્ગોરિધમ, જ્યારે એક જ ઉદાહરણ સાથે કામ કરે છે, ત્યારે આ પદ્ધતિનો બરાબર ઉપયોગ કરશે. અમારા ઉદાહરણોમાં અમે N ને 5 પર સેટ કરીએ છીએ, જે વાજબી મૂલ્ય છે. આમ, અમારે વિવિધ કમ્પ્યુટર્સ અથવા વર્ચ્યુઅલ મશીનો પર 5 રેડિસ માસ્ટર્સનો ઉપયોગ કરવાની જરૂર પડશે જેથી તેઓ એકબીજાથી મોટાભાગે સ્વતંત્ર રીતે કાર્ય કરે.

લોક મેળવવા માટે, ક્લાયંટ નીચેની કામગીરી કરે છે:

1. વર્તમાન સમય મિલિસેકંડમાં મેળવે છે.
2. તમામ કેસોમાં સમાન કી નામ અને રેન્ડમ વેલ્યુનો ઉપયોગ કરીને, તમામ N ઉદાહરણો પર લૉક મેળવવાનો ક્રમિક પ્રયાસ કરે છે. સ્ટેજ 2 માં, જ્યારે ક્લાયંટ પ્રતિ-ઇન્સ્ટન્સ ધોરણે લોક સેટ કરે છે, ત્યારે ક્લાયંટ તેને હસ્તગત કરવા માટે વિલંબનો ઉપયોગ કરે છે જે લોક આપોઆપ રીલીઝ થાય તે સમયની તુલનામાં પૂરતો ઓછો હોય છે. ઉદાહરણ તરીકે, જો અવરોધિત કરવાની અવધિ 10 સેકન્ડ છે, તો વિલંબ ~5-50 મિલિસેકન્ડની રેન્જમાં હોઈ શકે છે. આ તે પરિસ્થિતિને દૂર કરે છે જેમાં ક્લાયંટ નિષ્ફળ રેડિસ નોડ સુધી પહોંચવાનો પ્રયાસ કરી લાંબા સમય સુધી અવરોધિત રહી શકે છે: જો દાખલો અનુપલબ્ધ હોય, તો અમે શક્ય તેટલી વહેલી તકે અન્ય ઉદાહરણ સાથે કનેક્ટ કરવાનો પ્રયાસ કરીએ છીએ.
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 SET NX ઑપરેશન્સ સફળ થઈ શકશે નહીં જો N/2+1 કી પહેલેથી અસ્તિત્વમાં છે. તેથી, એકવાર લોક હસ્તગત કરી લેવામાં આવે, તે જ ક્ષણે તેને ફરીથી હસ્તગત કરવું અશક્ય છે (આ પરસ્પર બાકાત મિલકતનું ઉલ્લંઘન કરશે).
જો કે, અમે એ સુનિશ્ચિત કરવા માંગીએ છીએ કે એક જ સમયે લૉક મેળવવાનો પ્રયાસ કરી રહેલા બહુવિધ ક્લાયન્ટ્સ એક જ સમયે સફળ ન થઈ શકે.

જો ક્લાયન્ટે મોટા ભાગના દાખલાઓને મહત્તમ લૉક અવધિ કરતાં લગભગ અથવા વધુ સમય માટે લૉક કર્યા હોય, તો તે લૉકને અમાન્ય ગણશે અને ઉદાહરણોને અનલૉક કરશે. તેથી, અમારે ફક્ત તે જ કેસને ધ્યાનમાં લેવો પડશે જેમાં ક્લાયંટ સમાપ્તિ તારીખ કરતાં ઓછા સમયમાં મોટાભાગની ઘટનાઓને અવરોધિત કરવામાં વ્યવસ્થાપિત છે. આ કિસ્સામાં, ઉપરોક્ત દલીલ અંગે, સમય દરમિયાન MIN_VALIDITY કોઈ ક્લાયન્ટ લોક ફરીથી મેળવવા માટે સક્ષમ હોવું જોઈએ નહીં. તેથી, ઘણા ક્લાયન્ટ્સ N/2+1 દાખલાઓને તે જ સમયે લોક કરી શકશે (જે સ્ટેજ 2 ના અંતે સમાપ્ત થાય છે) ત્યારે જ જ્યારે બહુમતી લોક કરવાનો સમય TTL સમય કરતા વધારે હોય, જે લોકને અમાન્ય બનાવે છે.

શું તમે સુરક્ષાનો ઔપચારિક પુરાવો પ્રદાન કરી શકો છો, હાલના સમાન અલ્ગોરિધમ્સ સૂચવી શકો છો અથવા ઉપરોક્તમાં બગ શોધી શકો છો?

સુલભતા વિચારણાઓ

સિસ્ટમની ઉપલબ્ધતા ત્રણ મુખ્ય લાક્ષણિકતાઓ પર આધારિત છે:

1. તાળાઓ આપમેળે રીલીઝ કરો (જેમ કીની સમયસીમા સમાપ્ત થાય છે): ચાવીઓ આખરે તાળાઓ માટે ઉપયોગમાં લેવા માટે ફરીથી ઉપલબ્ધ થશે.
2. હકીકત એ છે કે ગ્રાહકો સામાન્ય રીતે તાળાઓ દૂર કરીને એકબીજાને મદદ કરે છે જ્યારે ઇચ્છિત તાળું હસ્તગત કરવામાં આવ્યું ન હોય, અથવા હસ્તગત કરવામાં આવ્યું હોય અને કામ પૂર્ણ થઈ ગયું હોય; તેથી સંભવ છે કે લોક ફરીથી મેળવવા માટે આપણે ચાવીઓની સમયસીમા સમાપ્ત થવાની રાહ જોવી પડશે નહીં.
3. હકીકત એ છે કે જ્યારે ક્લાયન્ટને લૉક મેળવવા માટે ફરીથી પ્રયાસ કરવાની જરૂર પડે છે, ત્યારે તે મોટાભાગના તાળાઓ મેળવવા માટે જરૂરી સમયગાળા કરતાં તુલનાત્મક રીતે લાંબા સમય સુધી રાહ જુએ છે. આ સંસાધનો માટે સ્પર્ધા કરતી વખતે વિભાજિત-મગજની પરિસ્થિતિ ઊભી થવાની સંભાવનાને ઘટાડે છે.

જો કે, નેટવર્ક સેગમેન્ટના TTL જેટલી ઉપલબ્ધતા દંડ છે, તેથી જો ત્યાં સંલગ્ન સેગમેન્ટ્સ હોય, તો પેનલ્ટી અનિશ્ચિત હોઈ શકે છે. આ ત્યારે થાય છે જ્યારે ક્લાયંટ લોક મેળવે છે અને પછી તેને રીલીઝ કરે તે પહેલા બીજા સેગમેન્ટમાં ફાડી નાખે છે.

સૈદ્ધાંતિક રીતે, અનંત સંલગ્ન નેટવર્ક વિભાગોને જોતાં, સિસ્ટમ અનંત સમયગાળા માટે અનુપલબ્ધ રહી શકે છે.

પ્રદર્શન, નિષ્ફળતા અને fsync

ઘણા લોકો Redis નો ઉપયોગ કરે છે કારણ કે તેમને લૉક મેળવવા અને રિલીઝ કરવા માટે જરૂરી લેટન્સી અને પ્રતિ સેકન્ડમાં પૂર્ણ કરી શકાય તેવા એક્વિઝિશન/રિલીઝની સંખ્યાના સંદર્ભમાં ઉચ્ચ લોક સર્વર પ્રદર્શનની જરૂર છે. આ જરૂરિયાતને પહોંચી વળવા માટે, લેટન્સી ઘટાડવા માટે N Redis સર્વર્સ સાથે વાતચીત કરવાની વ્યૂહરચના છે. આ એક મલ્ટિપ્લેક્સિંગ વ્યૂહરચના છે (અથવા "ગરીબ માણસનું મલ્ટિપ્લેક્સિંગ", જ્યાં સૉકેટ બિન-બ્લૉકિંગ મોડમાં મૂકવામાં આવે છે, બધા આદેશો મોકલે છે, અને પછીથી આદેશો વાંચે છે, એમ માનીને કે ક્લાયંટ અને દરેક ઘટના વચ્ચેનો રાઉન્ડ-ટ્રીપ સમય સમાન છે) .

જો કે, જો આપણે નિષ્ફળતાઓમાંથી વિશ્વસનીય પુનઃપ્રાપ્તિ સાથે મોડલ બનાવવાનો પ્રયત્ન કરીએ તો લાંબા ગાળાના ડેટા સ્ટોરેજ સાથે સંકળાયેલી વિચારણાને પણ ધ્યાનમાં લેવી પડશે.

મૂળભૂત રીતે, સમસ્યાને સ્પષ્ટ કરવા માટે, ચાલો ધારીએ કે અમે Redis ને કોઈ લાંબા ગાળાના ડેટા સ્ટોરેજ સાથે ગોઠવીએ છીએ. ક્લાયંટ 3 માંથી 5 દાખલાઓને અવરોધિત કરવાનું સંચાલન કરે છે. ક્લાયંટે અવરોધિત કરવા માટે વ્યવસ્થાપિત કરેલા દાખલાઓમાંથી એક પુનઃપ્રારંભ થયો છે, અને આ ક્ષણે તે જ સંસાધન માટે ફરીથી 3 દાખલાઓ છે, જેને આપણે અવરોધિત કરી શકીએ છીએ, અને અન્ય ક્લાયંટ, બદલામાં, સુરક્ષા ગુણધર્મનું ઉલ્લંઘન કરીને, પુનઃપ્રારંભ કરેલ ઉદાહરણને અવરોધિત કરી શકે છે. તાળાઓની વિશિષ્ટતા ધારે છે.

જો તમે ડેટા અહેડ (AOF) ને સક્ષમ કરો છો, તો પરિસ્થિતિમાં થોડો સુધારો થશે. ઉદાહરણ તરીકે, તમે SHUTDOWN આદેશ મોકલીને અને તેને પુનઃપ્રારંભ કરીને સર્વરને પ્રોત્સાહન આપી શકો છો. રેડિસમાં સમાપ્તિની કામગીરી એવી રીતે લાગુ કરવામાં આવી છે કે જ્યારે સર્વર બંધ હોય ત્યારે પણ સમયનો પ્રવાહ ચાલુ રહે છે, અમારી બધી આવશ્યકતાઓ બરાબર છે. જ્યાં સુધી સામાન્ય શટડાઉન સુનિશ્ચિત કરવામાં આવે ત્યાં સુધી આ સામાન્ય છે. પાવર આઉટેજના કિસ્સામાં શું કરવું? જો Redis એ ડિફૉલ્ટ રૂપે રૂપરેખાંકિત થયેલ હોય, fsync દર સેકન્ડે ડિસ્ક પર સમન્વય સાથે, તો તે શક્ય છે કે પુનઃપ્રારંભ કર્યા પછી અમારી પાસે અમારી કી નહીં હોય. સૈદ્ધાંતિક રીતે, જો આપણે કોઈપણ ઉદાહરણ પુનઃપ્રારંભ દરમિયાન લૉક સુરક્ષાની બાંયધરી આપવા માંગીએ છીએ, તો આપણે સક્ષમ કરવું જોઈએ fsync=always લાંબા ગાળાના ડેટા સ્ટોરેજ માટે સેટિંગ્સમાં. આનાથી CP સિસ્ટમના સ્તર સુધી, જે પરંપરાગત રીતે વિતરિત તાળાઓને સુરક્ષિત રીતે અમલમાં મૂકવા માટે ઉપયોગમાં લેવામાં આવે છે તે કામગીરીને સંપૂર્ણપણે નષ્ટ કરશે.

પરંતુ પરિસ્થિતિ પ્રથમ નજરમાં લાગે તે કરતાં વધુ સારી છે. સૈદ્ધાંતિક રીતે, અલ્ગોરિધમની સુરક્ષા સચવાય છે કારણ કે જ્યારે નિષ્ફળતા પછી દાખલો પુનઃપ્રારંભ થાય છે, ત્યારે તે હાલમાં સક્રિય હોય તેવા કોઈપણ લોકમાં ભાગ લેતો નથી.

આને સુનિશ્ચિત કરવા માટે, અમારે માત્ર એ સુનિશ્ચિત કરવાની જરૂર છે કે નિષ્ફળતા પછી દાખલા અમે ઉપયોગ કરીએ છીએ તે મહત્તમ TTL કરતાં સહેજ વધુ સમય માટે અનુપલબ્ધ રહે છે. આ રીતે આપણે સમાપ્તિ તારીખ સુધી રાહ જોઈશું અને નિષ્ફળતા સમયે સક્રિય હતી તે બધી કીના સ્વચાલિત પ્રકાશન સુધી.

વિલંબિત પુનઃપ્રારંભનો ઉપયોગ કરીને, રેડિસમાં લાંબા ગાળાની દ્રઢતાની ગેરહાજરીમાં પણ સુરક્ષા પ્રાપ્ત કરવી સૈદ્ધાંતિક રીતે શક્ય છે. નોંધ કરો, જો કે, આ ઍક્સેસિબિલિટીના ઉલ્લંઘન માટે દંડમાં પરિણમી શકે છે. ઉદાહરણ તરીકે, જો મોટાભાગની ઘટનાઓ નિષ્ફળ જાય, તો સિસ્ટમ TTL માટે વૈશ્વિક સ્તરે અનુપલબ્ધ બની જશે (અને આ સમય દરમિયાન કોઈ સંસાધનને અવરોધિત કરી શકાશે નહીં).

અમે અલ્ગોરિધમની ઉપલબ્ધતા વધારીએ છીએ: અમે બ્લોકિંગને લંબાવીએ છીએ

જો ક્લાયન્ટ દ્વારા કરવામાં આવતા કામમાં નાના પગલાઓ હોય, તો ડિફૉલ્ટ લૉકની અવધિમાં ઘટાડો કરવો અને લૉકને લંબાવવા માટેની પદ્ધતિનો અમલ કરવો શક્ય છે. સૈદ્ધાંતિક રીતે, જો ક્લાયંટ કમ્પ્યુટિંગમાં વ્યસ્ત હોય અને લૉક સમાપ્તિ મૂલ્ય જોખમી રીતે ઓછું હોય, તો તમે લુઆ સ્ક્રિપ્ટ મોકલી શકો છો કે જે કીના TTLને વિસ્તૃત કરે છે જો કી હજી પણ અસ્તિત્વમાં હોય અને તેનું મૂલ્ય હજી પણ રેન્ડમ મૂલ્ય હોય ત્યારે પ્રાપ્ત થાય છે. લોક હસ્તગત કરવામાં આવ્યું હતું.

ક્લાયન્ટે માત્ર ત્યારે જ લોકને પુનઃપ્રાપ્ત કરવાનું વિચારવું જોઈએ જો તે માન્યતા અવધિમાં મોટા ભાગના દાખલાઓને લૉક કરવામાં વ્યવસ્થાપિત હોય.

સાચું છે, તકનીકી રીતે અલ્ગોરિધમ બદલાતું નથી, તેથી તાળાઓ મેળવવાના પુનરાવર્તિત પ્રયાસોની મહત્તમ સંખ્યા મર્યાદિત હોવી જોઈએ, અન્યથા સુલભતા ગુણધર્મોનું ઉલ્લંઘન કરવામાં આવશે.

સોર્સ: www.habr.com