განაწილებული ჩაკეტვა Redis-ის გამოყენებით

ჰეი ჰაბრ!

დღეს თქვენს ყურადღებას ვაქცევთ რთული სტატიის თარგმანს Redis-ის გამოყენებით განაწილებული ჩაკეტვის განხორციელების შესახებ და გეპატიჟებით სასაუბროდ Redis-ის პერსპექტივებზე, როგორც თემაზე. რედლოკის ალგორითმის ანალიზი მარტინ კლეპმანისგან, წიგნის ავტორი "მაღალი დატვირთვის აპლიკაციები“, მოცემული აქ.

განაწილებული ჩაკეტვა არის ძალიან სასარგებლო პრიმიტივი, რომელიც გამოიყენება ბევრ გარემოში, სადაც სხვადასხვა პროცესმა უნდა იმუშაოს საერთო რესურსებზე ურთიერთგამომრიცხავი გზით.

არსებობს უამრავი ბიბლიოთეკა და პოსტი, რომელიც აღწერს, თუ როგორ უნდა განხორციელდეს DLM (Distributed Lock Manager) Redis-ის გამოყენებით, მაგრამ თითოეული ბიბლიოთეკა განსხვავებულ მიდგომას იყენებს და მათ მიერ მოწოდებული გარანტიები საკმაოდ სუსტია, ვიდრე ოდნავ უფრო დახვეწილი დიზაინის მიღწევა შესაძლებელია.

ამ სტატიაში ჩვენ შევეცდებით აღვწეროთ პირობითი კანონიკური ალგორითმი, რომელიც აჩვენებს, თუ როგორ უნდა განხორციელდეს განაწილებული ჩაკეტვა Redis-ის გამოყენებით. ჩვენ ვისაუბრებთ ალგორითმზე ე.წ რედლოკი, ის ახორციელებს განაწილებულ საკეტის მენეჯერს და, ჩვენი აზრით, ეს ალგორითმი უფრო უსაფრთხოა, ვიდრე ჩვეულებრივი ერთი ინსტანციის მიდგომა. ვიმედოვნებთ, რომ საზოგადოება გააანალიზებს მას, მიაწვდის უკუკავშირს და გამოიყენებს მას, როგორც ამოსავალ წერტილს უფრო რთული ან ალტერნატიული პროექტებისთვის.

განხორციელება

სანამ ალგორითმის აღწერაზე გადავიდოდეთ, ჩვენ ვაძლევთ რამდენიმე ბმულს მზა განხორციელებისთვის. ისინი შეიძლება გამოყენებულ იქნას მითითებისთვის.

• რედლოკ-რბ (განხორციელება რუბისთვის). Არსებობს ასევე ჩანგალი Redlock-rb, რომელიც ამატებს პაკეტს (ძვირფასი ქვები) განაწილების სიმარტივისთვის და არა მხოლოდ ამისთვის.
• რედლოკ-პი (პითონის განხორციელება).
• აიორედლოკი (დანერგვა Asyncio Python-ისთვის).
• Redlock-php (დანერგვა PHP-სთვის).
• PHPRedisMutex (PHP-ის კიდევ ერთი განხორციელება)
• cheprasov/php-redis-lock (PHP ბიბლიოთეკა საკეტებისთვის)
• Redsync (განხორციელება Go-სთვის).
• რედისონი (განხორციელება Java-სთვის).
• Redis::DistLock (განხორციელება Perl-ისთვის).
• Redlock-cpp (განხორციელება C++-ისთვის).
• Redlock-cs (დანერგვა C#/.NET-ისთვის).
• RedLock.net (დანერგვა C#/.NET-ისთვის). ასინქრონული და დაბლოკვის გაფართოებების მხარდაჭერით.
• ScarletLock (დანერგვა C#.NET-ისთვის კონფიგურირებადი მონაცემთა მაღაზიით)
• Redlock4Net (დანერგვა C# .NET-ისთვის)
• კვანძი-წითელი (განხორციელება NodeJS-ისთვის). მოიცავს საკეტების გაფართოების მხარდაჭერას.

უსაფრთხოებისა და ხელმისაწვდომობის გარანტიები

ჩვენ ვაპირებთ ჩვენი დიზაინის მოდელირებას მხოლოდ სამი თვისებით, რომლებიც, ვფიქრობთ, იძლევა მინიმალურ გარანტიებს, რომლებიც საჭიროა განაწილებული ჩაკეტვის ეფექტურად გამოყენებისთვის.

1. უსაფრთხოების საკუთრება: ურთიერთგამორიცხვა. ნებისმიერ დროს, მხოლოდ ერთ კლიენტს შეუძლია დაიჭიროს საკეტი.
2. ხელმისაწვდომობა თვისება A: ჩიხების გარეშე. ყოველთვის შესაძლებელია საბოლოოდ შეიძინოს დაბლოკვა, მაშინაც კი, თუ კლიენტი, რომელმაც დაბლოკა რესურსი, ვერ მოხერხდება ან მოხვდება დისკის სხვა სეგმენტზე.
3. ხელმისაწვდომობა თვისება B: შეცდომის ტოლერანტობა. სანამ Redis კვანძების უმრავლესობა მუშაობს, კლიენტებს შეუძლიათ შეიძინონ და გაათავისუფლონ საკეტები.

რატომ არ არის საკმარისი ამ შემთხვევაში წარუმატებლობის აღდგენაზე დაფუძნებული განხორციელება
იმის გასაგებად, თუ რის გაუმჯობესებას ვაპირებთ, გავაანალიზოთ არსებული მდგომარეობა ყველაზე გავრცელებულ ჩამკეტ ბიბლიოთეკებთან, რომლებიც დაფუძნებულია Redis-ზე.

რესურსის ჩაკეტვის უმარტივესი გზა Redis-ის გამოყენებით არის გასაღების შექმნა მაგალითში. როგორც წესი, გასაღები იქმნება შეზღუდული სიცოცხლის ხანგრძლივობით, ეს მიიღწევა Redis-ში მოწოდებული ვადის გასვლის ფუნქციის გამოყენებით, ასე რომ ადრე თუ გვიან ეს გასაღები გამოდის (საკუთრება 2 ჩვენს სიაში). როდესაც კლიენტს სჭირდება რესურსის გამოშვება, ის წაშლის გასაღებს.

ერთი შეხედვით, ეს გამოსავალი საკმაოდ კარგად მუშაობს, მაგრამ არის პრობლემა: ჩვენი არქიტექტურა ქმნის მარცხის ერთ წერტილს. რა მოხდება, თუ მასპინძელი Redis ინსტანცია ვერ ხერხდება? მაშინ დავამატოთ მონა! და ჩვენ გამოვიყენებთ მას, თუ წამყვანი არ არის ხელმისაწვდომი. სამწუხაროდ, ეს ვარიანტი არ არის ეფექტური. ამით ჩვენ ვერ შევძლებთ სათანადოდ განვახორციელოთ ურთიერთგამორიცხვის თვისება, რომელიც გვჭირდება უსაფრთხოების უზრუნველსაყოფად, რადგან Redis-ში რეპლიკაცია ასინქრონულია.

ცხადია, ასეთ მოდელში ხდება რასის მდგომარეობა:

1. კლიენტი A იძენს საკეტს მასტერზე.
2. სამაგისტრო მარცხდება გასაღების ჩანაწერის მონაზე გადაცემამდე.
3. მიმდევარი დაწინაურებულია ლიდერად.
4. კლიენტი B იძენს საკეტს იმავე რესურსზე, რომელიც A-მ უკვე ჩაკეტა. უსაფრთხოების დარღვევა!

ზოგჯერ სრულიად ნორმალურია, რომ განსაკუთრებულ ვითარებაში, როგორიცაა წარუმატებლობა, ბევრ კლიენტს შეუძლია ერთდროულად დაიჭიროს საკეტი. ასეთ შემთხვევებში შეიძლება გამოყენებულ იქნას რეპლიკაციაზე დაფუძნებული ხსნარი. წინააღმდეგ შემთხვევაში, ჩვენ გირჩევთ ამ სტატიაში აღწერილ გადაწყვეტას.

სწორი განხორციელება ერთი ინსტანციით

სანამ ზემოთ აღწერილი ერთი ინსტანციის კონფიგურაციის ნაკლოვანებების დაძლევას შევეცდებით, გავიგოთ, თუ როგორ უნდა მოვიქცეთ სწორად ამ მარტივ შემთხვევაზე, რადგან ეს გამოსავალი რეალურად მოქმედებს აპლიკაციებში, სადაც დროდადრო მისაღებია რბოლის პირობები და ასევე იმის გამო, რომ დაბლოკვა ერთი ინსტანცია ემსახურება როგორც საფუძველს, რომელიც გამოიყენება აქ აღწერილი განაწილებულ ალგორითმში.

საკეტის შესაძენად, გააკეთეთ ეს:

SET resource_name my_random_value NX PX 30000

ეს ბრძანება აყენებს გასაღებს მხოლოდ იმ შემთხვევაში, თუ ის უკვე არ არსებობს (NX ვარიანტი), მოქმედების პერიოდით 30000 მილიწამი (PX ვარიანტი). გასაღები დაყენებულია "myrandomvalue" ეს მნიშვნელობა უნდა იყოს უნიკალური ყველა კლიენტში და ყველა დაბლოკვის მოთხოვნაში.
ძირითადად, შემთხვევითი მნიშვნელობა გამოიყენება საკეტის უსაფრთხოდ გასათავისუფლებლად, სკრიპტით, რომელიც ეუბნება Redis: ამოიღეთ გასაღები მხოლოდ იმ შემთხვევაში, თუ ის არსებობს და მასში შენახული მნიშვნელობა არის ზუსტად ის, რაც მოსალოდნელი იყო. ეს მიიღწევა შემდეგი Lua სკრიპტის გამოყენებით:

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

ეს მნიშვნელოვანია სხვა კლიენტის მიერ დაჭერილი საკეტის ამოღების თავიდან ასაცილებლად. მაგალითად, კლიენტმა შეიძლება შეიძინოს საკეტი, შემდეგ დაბლოკოს ზოგიერთ ოპერაციაში, რომელიც გაგრძელდება პირველ საკეტზე მეტხანს (ისე, რომ გასაღების ვადის გასვლის დრო აქვს) და მოგვიანებით ამოიღოს საკეტი, რომელიც სხვა კლიენტმა მოათავსა.
მარტივი DEL-ის გამოყენება სახიფათოა, რადგან კლიენტს შეუძლია სხვა კლიენტის მიერ დაჭერილი საკეტის ამოღება. ამის საპირისპიროდ, ზემოაღნიშნული სკრიპტის გამოყენებისას, თითოეულ საკეტს „ხელმოწერილი“ აქვს შემთხვევითი სტრიქონი, ასე რომ, მხოლოდ კლიენტს, რომელმაც ის ადრე მოათავსა, შეუძლია მისი ამოღება.

რა უნდა იყოს ეს შემთხვევითი სტრიქონი? მე ვფიქრობ, რომ ის უნდა იყოს 20 ბაიტი /dev/urandom-დან, მაგრამ შეგიძლიათ იპოვოთ ნაკლებად ძვირი გზები, რათა სტრიქონი საკმარისად უნიკალური გახადოთ თქვენი მიზნებისთვის. მაგალითად, კარგი იქნება RC4-ის დათესვა /dev/urandom-ით და შემდეგ მისგან ფსევდო შემთხვევითი ნაკადის გენერირება. უფრო მარტივი გამოსავალი მოიცავს უნიქსის დროის კომბინაციას მიკროწამში გარჩევადობით პლუს კლიენტის ID; ეს არ არის ისეთი უსაფრთხო, მაგრამ, ალბათ, ამოცანის გადასაწყვეტია უმეტეს კონტექსტში.

დროს, რომელსაც ვიყენებთ გასაღების სიცოცხლის საზომად, ეწოდება "საკეტის სიცოცხლე". ეს მნიშვნელობა არის დროის ოდენობა, სანამ საკეტი ავტომატურად გათავისუფლდება და კლიენტმა უნდა დაასრულოს ოპერაცია, სანამ სხვა კლიენტი შეძლებს ამ რესურსის დაბლოკვას, ფაქტობრივად, ურთიერთგამორიცხვის გარანტიების დარღვევის გარეშე. ეს გარანტია შემოიფარგლება მხოლოდ დროის გარკვეული ფანჯრით, რომელიც იწყება საკეტის შეძენის მომენტიდან.

ასე რომ, ჩვენ განვიხილეთ საკეტის შეძენისა და გათავისუფლების კარგი გზა. სისტემა (თუ ვსაუბრობთ არაგანაწილებულ სისტემაზე, რომელიც შედგება ერთი და ყოველთვის ხელმისაწვდომი ინსტანციისგან) უსაფრთხოა. მოდით გავავრცელოთ ეს კონცეფცია განაწილებულ სისტემაზე, სადაც ასეთი გარანტიები არ გვაქვს.

რედლოკის ალგორითმი

ალგორითმის განაწილებული ვერსია ვარაუდობს, რომ ჩვენ გვყავს N Redis ოსტატები. ეს კვანძები ერთმანეთისგან სრულიად დამოუკიდებელია, ამიტომ ჩვენ არ ვიყენებთ რეპლიკაციას ან რაიმე სხვა იმპლიციტური კოორდინაციის სისტემას. ჩვენ უკვე განვიხილეთ, თუ როგორ უსაფრთხოდ შეიძინოთ და გაათავისუფლოთ საკეტი ერთ ეგზემპლარზე. მიგვაჩნია, რომ ალგორითმი, ერთ ეგზემპლართან მუშაობისას, სწორედ ამ მეთოდს გამოიყენებს. ჩვენს მაგალითებში ჩვენ დავაყენეთ N 5-ზე, რაც გონივრული მნიშვნელობაა. ამრიგად, ჩვენ დაგვჭირდება გამოვიყენოთ 5 Redis Masters სხვადასხვა კომპიუტერებზე ან ვირტუალურ მანქანებზე, რათა უზრუნველვყოთ, რომ ისინი მოქმედებენ დიდწილად ერთმანეთისგან დამოუკიდებლად.

საკეტის შესაძენად, კლიენტი ასრულებს შემდეგ ოპერაციებს:

1. იღებს მიმდინარე დროს მილიწამებში.
2. თანმიმდევრულად ცდილობს დაიბლოკოს ყველა N ინსტანციაზე, ყველა შემთხვევაში ერთი და იგივე კლავიშის სახელის და შემთხვევითი მნიშვნელობების გამოყენებით. მე-2 ეტაპზე, როდესაც კლიენტი აყენებს საკეტს თითო ინსტანციის საფუძველზე, კლიენტი იყენებს დაყოვნებას მის შესაძენად, რომელიც საკმარისად ხანმოკლეა იმ დროსთან შედარებით, რომლის შემდეგაც საკეტი ავტომატურად გათავისუფლდება. მაგალითად, თუ დაბლოკვის ხანგრძლივობაა 10 წამი, მაშინ დაყოვნება შეიძლება იყოს ~5-50 მილიწამის დიაპაზონში. ეს გამორიცხავს სიტუაციას, როდესაც კლიენტი შეიძლება დარჩეს დაბლოკილი დიდი ხნის განმავლობაში, ცდილობს მიაღწიოს წარუმატებელ Redis კვანძს: თუ ეს მაგალითი მიუწვდომელია, მაშინ ჩვენ ვცდილობთ დაუკავშირდეთ სხვა ინსტანციას რაც შეიძლება მალე.
3. საკეტის ასაღებად კლიენტი ითვლის რამდენი დრო გავიდა; ამისათვის ის აკლებს დროის ფაქტობრივ მნიშვნელობას დროის ნიშანს, რომელიც მიღებულ იქნა 1-ლ საფეხურზე. თუ და მხოლოდ იმ შემთხვევაში, თუ კლიენტს შეეძლო მიეღო ჩაკეტვა უმეტეს ინსტანციებზე (მინიმუმ 3) და მთლიან დროს, რომელიც დასჭირდა მიიღეთ საკეტი, საკეტის ხანგრძლივობაზე ნაკლები, ჩაკეტილი ითვლება მიღებულად.
4. თუ საკეტი შეძენილია, დაბლოკვის ხანგრძლივობა მიიღება, როგორც თავდაპირველი დაბლოკვის ხანგრძლივობა, გამოკლებული გასული დრო, რომელიც გამოითვლება მე-3 საფეხურზე.
5. თუ კლიენტი რაიმე მიზეზით ვერ მოიპოვებს საკეტს (ან მან ვერ შეძლო N/2+1 ინსტანციის დაბლოკვა, ან დაბლოკვის ხანგრძლივობა უარყოფითი იყო), მაშინ ის შეეცდება განბლოკოს ყველა ინსტანცია (თუნდაც ის, ვინც ფიქრობდა, რომ ვერ დაბლოკა). ).

არის თუ არა ალგორითმი ასინქრონული?

ეს ალგორითმი ემყარება ვარაუდს, რომ მიუხედავად იმისა, რომ არ არსებობს სინქრონიზებული საათი, რომელზეც ყველა პროცესი იმუშავებს, ადგილობრივი დრო თითოეულ პროცესში მაინც დაახლოებით იგივე ტემპით მიედინება და შეცდომა მცირეა იმ მთლიან დროსთან შედარებით, რომლის შემდეგაც დაბლოკვა ხდება. ავტომატურად გაათავისუფლეს. ეს ვარაუდი ძალიან ჰგავს ჩვეულებრივი კომპიუტერებისთვის დამახასიათებელ სიტუაციას: თითოეულ კომპიუტერს აქვს ლოკალური საათი და ჩვეულებრივ შეგვიძლია ვიმედოვნოთ, რომ სხვადასხვა კომპიუტერებს შორის დროის სხვაობა მცირეა.

ამ ეტაპზე, ჩვენ უფრო ფრთხილად უნდა ჩამოვაყალიბოთ ჩვენი ორმხრივი გამორიცხვის წესი: ურთიერთგამორიცხვა გარანტირებულია მხოლოდ იმ შემთხვევაში, თუ კლიენტი, რომელსაც აქვს საკეტი, გადის საკეტის მოქმედების პერიოდში (ეს მნიშვნელობა მიღებულია მე-3 საფეხურზე), მინუს კიდევ რამდენიმე დრო (სულ რამდენიმე მილიწამებში პროცესებს შორის დროის სხვაობის კომპენსაციისთვის).

შემდეგი საინტერესო სტატია უფრო მეტს მოგვითხრობს ასეთი სისტემების შესახებ, რომლებიც საჭიროებენ დროის ინტერვალების კოორდინაციას: იჯარა: ეფექტური ხარვეზების ტოლერანტული მექანიზმი განაწილებული ფაილების ქეშის თანმიმდევრულობისთვის.

ხელახლა სცადეთ წარუმატებლობა

როდესაც კლიენტი ვერ იძენს საკეტს, მან უნდა სცადო თავიდან შემთხვევითი შეფერხების შემდეგ; ეს კეთდება იმისთვის, რომ მოხდეს რამდენიმე კლიენტის დესინქრონიზაცია, რომლებიც ცდილობენ შეიძინონ დაბლოკვა ერთსა და იმავე რესურსზე ერთდროულად (რაც შეიძლება გამოიწვიოს "გაყოფილი ტვინის" სიტუაცია, რომელშიც გამარჯვებულები არ არიან). გარდა ამისა, რაც უფრო სწრაფად შეეცდება კლიენტი შეიძინოს დაბლოკვა Redis-ის შემთხვევების უმეტესობაზე, მით უფრო ვიწროა ფანჯარა, რომელშიც შეიძლება მოხდეს ტვინის გაყოფის სიტუაცია (და ნაკლებია ხელახალი ცდების საჭიროება). ამიტომ, იდეალურ შემთხვევაში, კლიენტმა უნდა სცადოს 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 ეტაპის ბოლოს) მხოლოდ მაშინ, როდესაც უმრავლესობის დაბლოკვის დრო მეტია TTL დროზე, რაც ბლოკავს არასწორად.

შეგიძლიათ წარმოადგინოთ უსაფრთხოების ოფიციალური მტკიცებულება, მიუთითოთ არსებული მსგავსი ალგორითმები ან იპოვოთ ხარვეზი ზემოთ მოცემულში?

ხელმისაწვდომობის მოსაზრებები

სისტემის ხელმისაწვდომობა დამოკიდებულია სამ ძირითად მახასიათებელზე:

1. საკეტების ავტომატური გათავისუფლება (გასაღებების ვადის გასვლის შემდეგ): გასაღებები საბოლოოდ ხელახლა იქნება ხელმისაწვდომი საკეტებისთვის გამოსაყენებლად.
2. ის ფაქტი, რომ კლიენტები, როგორც წესი, ეხმარებიან ერთმანეთს საკეტების მოხსნით, როდესაც სასურველი საკეტი არ არის შეძენილი, ან შეძენილია და სამუშაო დასრულებულია; ასე რომ, სავარაუდოა, რომ არ მოგვიწევს ლოდინი გასაღებების ვადის ამოწურვამდე, რათა ხელახლა მივიღოთ საკეტი.
3. ის ფაქტი, რომ როდესაც კლიენტს სჭირდება ხელახლა სცადო საკეტის შესაძენად, ის ელოდება შედარებით მეტ დროს, ვიდრე საკეტების უმეტესობის შესაძენად საჭირო პერიოდს. ეს ამცირებს გაყოფილი ტვინის სიტუაციის წარმოქმნის ალბათობას რესურსებისთვის კონკურენციის დროს.

თუმცა, არსებობს ხელმისაწვდომობის ჯარიმა, რომელიც ტოლია ქსელის სეგმენტების TTL-ს, ასე რომ, თუ არსებობს მიმდებარე სეგმენტები, ჯარიმა შეიძლება იყოს განუსაზღვრელი. ეს ხდება მაშინ, როდესაც კლიენტი იძენს საკეტს და შემდეგ იშლება სხვა სეგმენტში, სანამ ის გაათავისუფლებს მას.

პრინციპში, ქსელის უსასრულო მომიჯნავე სეგმენტების გათვალისწინებით, სისტემა შეიძლება მიუწვდომელი დარჩეს უსასრულო დროის განმავლობაში.

შესრულება, წარუმატებლობა და ფუნქციონირება

ბევრი ადამიანი იყენებს Redis-ს, რადგან მათ სჭირდებათ მაღალი დაბლოკვის სერვერის შესრულება საკეტების შეძენისა და გამოშვებისთვის საჭირო შეყოვნების თვალსაზრისით და შეძენის/გამოშვებების რაოდენობა, რომელიც შეიძლება დასრულდეს წამში. ამ მოთხოვნის დასაკმაყოფილებლად, არსებობს N Redis სერვერებთან კომუნიკაციის სტრატეგია, რათა შემცირდეს შეყოვნება. ეს არის მულტიპლექსირების სტრატეგია (ან "ღარიბი კაცის მულტიპლექსირება", სადაც სოკეტი მოთავსებულია არადაბლოკვის რეჟიმში, აგზავნის ყველა ბრძანებას და კითხულობს ბრძანებებს მოგვიანებით, იმ ვარაუდით, რომ კლიენტსა და თითოეულ ინსტანციას შორის ორმხრივი დრო მსგავსია) .

თუმცა, ჩვენ ასევე უნდა გავითვალისწინოთ მონაცემების გრძელვადიან შენახვასთან დაკავშირებული გათვალისწინება, თუ ჩვენ ვცდილობთ შევქმნათ მოდელი, რომელიც საიმედოდ აღდგება წარუმატებლობისგან.

ძირითადად, საკითხის გასარკვევად, დავუშვათ, რომ ჩვენ ვაკონფიგურირებთ Redis-ს გრძელვადიანი მონაცემთა შენახვის გარეშე. კლიენტი ახერხებს 3-დან 5-ის დაბლოკვას. ერთ-ერთი შემთხვევა, რომლის დაბლოკვაც კლიენტმა მოახერხა, გადატვირთულია და ამ მომენტში არის ისევ 3 შემთხვევა იმავე რესურსისთვის, რომელიც ჩვენ შეგვიძლია დავბლოკოთ და სხვა კლიენტს შეუძლია, თავის მხრივ, დაბლოკოს გადატვირთული ინსტანცია, არღვევს უსაფრთხოების თვისებას, რომელიც ითვალისწინებს საკეტების ექსკლუზიურობას.

თუ ჩართავთ წინასწარ მონაცემებს (AOF), სიტუაცია ოდნავ გაუმჯობესდება. მაგალითად, შეგიძლიათ სერვერის პოპულარიზაცია SHUTDOWN ბრძანების გაგზავნით და მისი გადატვირთვით. ვინაიდან Redis-ში ვადის გასვლის ოპერაციები სემანტიკურად არის დანერგილი ისე, რომ დრო აგრძელებს დინებას მაშინაც კი, როდესაც სერვერი გამორთულია, ჩვენი ყველა მოთხოვნა კარგია. ეს ნორმალურია, სანამ უზრუნველყოფილია ნორმალური გამორთვა. რა უნდა გააკეთოს ელექტროენერგიის გათიშვის შემთხვევაში? თუ Redis კონფიგურირებულია ნაგულისხმევად, ყოველ წამში დისკზე სინქრონიზებული fsync, მაშინ შესაძლებელია, რომ გადატვირთვის შემდეგ არ გვქონდეს ჩვენი გასაღები. თეორიულად, თუ გვსურს გარანტირებული იყოს დაბლოკვის უსაფრთხოება ნებისმიერი ინსტანციის გადატვირთვის დროს, უნდა ჩართოთ fsync=always გრძელვადიანი მონაცემთა შენახვის პარამეტრებში. ეს მთლიანად კლავს შესრულებას, CP სისტემების დონემდე, რომლებიც ტრადიციულად გამოიყენება განაწილებული საკეტების უსაფრთხოდ განსახორციელებლად.

მაგრამ სიტუაცია იმაზე უკეთესია, ვიდრე ერთი შეხედვით ჩანს. პრინციპში, ალგორითმის უსაფრთხოება შენარჩუნებულია, რადგან როდესაც ეგზემპლარის გადატვირთვა ხდება წარუმატებლობის შემდეგ, ის აღარ მონაწილეობს არცერთ დაბლოკვაში, რომელიც ამჟამად აქტიურია.

ამის უზრუნველსაყოფად, ჩვენ უბრალოდ უნდა დავრწმუნდეთ, რომ წარუმატებლობის შემდეგ ეგზემპლარი მიუწვდომელი დარჩეს გარკვეული პერიოდის განმავლობაში, რომელიც ოდნავ აღემატება მაქსიმალურ TTL-ს, რომელსაც ჩვენ ვიყენებთ. ამ გზით ჩვენ დაველოდებით ვადის გასვლის თარიღს და ყველა გასაღების ავტომატურ გამოშვებას, რომლებიც აქტიური იყო წარუმატებლობის დროს.

დაგვიანებული გადატვირთვის გამოყენებით, პრინციპში შესაძლებელია უსაფრთხოების მიღწევა Redis-ში რაიმე გრძელვადიანი მდგრადობის არარსებობის შემთხვევაშიც კი. ამასთან, გაითვალისწინეთ, რომ ამან შეიძლება გამოიწვიოს ჯარიმა ხელმისაწვდომობის დარღვევისთვის. მაგალითად, თუ შემთხვევების უმრავლესობა ვერ ხერხდება, სისტემა გლობალურად მიუწვდომელი გახდება TTL-სთვის (და ამ დროის განმავლობაში ვერც ერთი რესურსის დაბლოკვა შეუძლებელია).

ჩვენ ვზრდით ალგორითმის ხელმისაწვდომობას: ვაგრძელებთ ბლოკირებას

თუ კლიენტების მიერ შესრულებული სამუშაო შედგება მცირე ნაბიჯებისგან, შესაძლებელია შემცირდეს დაბლოკვის ნაგულისხმევი ხანგრძლივობა და დაინერგოს საკეტების გაფართოების მექანიზმი. პრინციპში, თუ კლიენტი დაკავებულია გამოთვლებით და დაბლოკვის ვადის გასვლის მნიშვნელობა სახიფათოდ დაბალია, შეგიძლიათ გააგზავნოთ Lua სკრიპტი ყველა ინსტანციაზე, რომელიც აგრძელებს გასაღების TTL-ს, თუ გასაღები ჯერ კიდევ არსებობს და მისი მნიშვნელობა მაინც შემთხვევითი მნიშვნელობაა მიღებული, როდესაც საკეტი შეიძინა.

კლიენტმა უნდა განიხილოს საკეტი ხელახლა შესაძენად მხოლოდ იმ შემთხვევაში, თუ მან მოახერხა შემთხვევების უმეტესობის დაბლოკვა მოქმედების პერიოდში.

მართალია, ტექნიკურად ალგორითმი არ იცვლება, ამიტომ საკეტების შეძენის განმეორებითი მცდელობების მაქსიმალური რაოდენობა შეზღუდული უნდა იყოს, წინააღმდეგ შემთხვევაში ხელმისაწვდომობის თვისებები დაირღვევა.

წყარო: www.habr.com