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

ტექნოლოგიის შერჩევა

ასეთი ცუდია? ცალკე Redis (დამოუკიდებელი რედის) 1 ოსტატისა და N სლავის კონფიგურაციაში? რატომ ვუწოდებ ამას მოძველებულ ტექნოლოგიას?

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

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

• მეორეც, მხოლოდ ერთი ოსტატის არსებობამ განაპირობა დაქუცმაცების პრობლემა. ჩვენ უნდა შეგვექმნა რამდენიმე დამოუკიდებელი კლასტერი "1 master and N slaves", შემდეგ ხელით გავანაწილოთ მონაცემთა ბაზები ამ მანქანებს შორის და იმედი ვიქონიოთ, რომ ხვალ ერთ-ერთი მონაცემთა ბაზა არ გაიზრდება ისე, რომ ის ცალკე ინსტანციაში უნდა გადავიდეს.

რა არის ვარიანტი?

• ყველაზე ძვირადღირებული და მდიდარი გადაწყვეტა არის Redis-Enterprise. ეს არის ყუთიანი გადაწყვეტა სრული ტექნიკური მხარდაჭერით. მიუხედავად იმისა, რომ ტექნიკური თვალსაზრისით იდეალურად გამოიყურება, იდეოლოგიური მიზეზების გამო არ შეგვეფერება.
• რედის-კლასტერი. გარეთ არის მხარდაჭერა master failover და sharding. ინტერფეისი თითქმის არ განსხვავდება ჩვეულებრივი ვერსიისგან. პერსპექტიულად გამოიყურება, მარცხებზე მოგვიანებით ვისაუბრებთ.
• Tarantool, Memcache, Aerospike და სხვა. ყველა ეს ინსტრუმენტი თითქმის იგივეს აკეთებს. მაგრამ თითოეულს აქვს საკუთარი ნაკლოვანებები. გადავწყვიტეთ, რომ ყველა კვერცხი ერთ კალათაში არ ჩაგვეტანა. ჩვენ ვიყენებთ Memcache-ს და Tarantool-ს სხვა ამოცანებისთვის და, წინ რომ ვუყურებთ, ვიტყვი, რომ ჩვენს პრაქტიკაში მათთან უფრო მეტი პრობლემა იყო.

გამოყენების სპეციფიკა

მოდით შევხედოთ რა პრობლემები გადავწყვიტეთ ისტორიულად Redis-თან და რა ფუნქციონირება გამოვიყენეთ:

• ქეში დისტანციურ სერვისებზე მოთხოვნამდე, როგორიცაა 2GIS | გოლანგი
  

  GET SET MGET MSET "SELECT DB"

• ქეში MYSQL-მდე | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• ძირითადი საცავი სესიებთან და დრაივერის კოორდინატებთან მუშაობის სერვისისთვის | გოლანგი
  

  GET SET MGET MSET "SELECT DB" "ADD GEO KEY" "GET GEO KEY" სკანირება

როგორც ხედავთ, უმაღლესი მათემატიკა არ არის. მაშინ რა არის სირთულე? მოდით შევხედოთ თითოეულ მეთოდს ცალკე.

მეთოდი
აღწერა
Redis-Cluster-ის მახასიათებლები
გადაწყვეტილება

ᲛᲘᲡᲐᲦᲔᲑᲐᲓ ᲨᲔᲘᲥᲛᲜᲐ
ჩაწერის/წაკითხვის გასაღები

MGET MSET
ჩაწერეთ/წაიკითხეთ მრავალი გასაღები
გასაღებები იქნება სხვადასხვა კვანძზე. მზა ბიბლიოთეკებს შეუძლიათ მრავალ ოპერაციების შესრულება მხოლოდ ერთი კვანძის ფარგლებში
შეცვალეთ MGET N GET ოპერაციების მილსადენით

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

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

GEO
ოპერაციები გეოკლავით
გეოკლავი არ არის გახეხილი

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

Redis vs Redis-კლასტერი

რას ვკარგავთ და რას ვიღებთ კლასტერზე გადასვლისას?

• ნაკლოვანებები: ვკარგავთ რამდენიმე მონაცემთა ბაზის ფუნქციონირებას.
  • თუ გვსურს ლოგიკურად შეუსაბამო მონაცემები ერთ კლასტერში შევინახოთ, პრეფიქსების სახით მოგვიწევს ყავარჯნების გაკეთება.
  • ჩვენ ვკარგავთ ყველა "ბაზის" ოპერაციას, როგორიცაა SCAN, DBSIZE, CLEAR DB და ა.შ.
  • მრავალფუნქციური ოპერაციების განხორციელება ბევრად უფრო რთული გახდა, რადგან შეიძლება მოითხოვდეს რამდენიმე კვანძზე წვდომას.
• უპირატესობები:
  • შეცდომის ტოლერანტობა master failover-ის სახით.
  • შარდინგი რედისის მხარეს.
  • გადაიტანეთ მონაცემები კვანძებს შორის ატომურად და შეფერხების გარეშე.
  • დაამატეთ და გადაანაწილეთ სიმძლავრე და დატვირთვები შეფერხების გარეშე.

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

გადაადგილებისთვის ემზადება

დავიწყოთ გადაადგილების მოთხოვნებით:

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

კლასტერის მოვლა

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

• სქემები. ჩვენ ვიყენებთ Prometheus-ს და Grafana-ს CPU-ის დატვირთვის, მეხსიერების გამოყენების, კლიენტების რაოდენობის, GET, SET, AUTH ოპერაციების რაოდენობის და ა.შ.
• ექსპერტიზა. წარმოიდგინეთ, რომ ხვალ გექნებათ უზარმაზარი კლასტერი თქვენი პასუხისმგებლობის ქვეშ. თუ გაფუჭდა, შენს გარდა ვერავინ შეასწორებს. თუ ის შენელებას დაიწყებს, ყველა თქვენსკენ გაიქცევა. თუ თქვენ გჭირდებათ რესურსების დამატება ან დატვირთვის გადანაწილება, დაბრუნდით თქვენთან. იმისათვის, რომ 25-ზე ნაცრისფერი არ გახდეს, მიზანშეწონილია ამ შემთხვევების გათვალისწინება და წინასწარ შეამოწმოთ როგორ მოიქცევა ტექნოლოგია გარკვეული მოქმედებების დროს. ამაზე უფრო დეტალურად ვისაუბროთ "ექსპერტიზის" განყოფილებაში.
• მონიტორინგი და სიგნალიზაცია. როდესაც კლასტერი იშლება, თქვენ გინდათ იყოთ პირველი, ვინც იცოდეთ ამის შესახებ. აქ ჩვენ შემოვიფარგლებით შეტყობინებით, რომ ყველა კვანძი აბრუნებს ერთსა და იმავე ინფორმაციას კლასტერის მდგომარეობის შესახებ (დიახ, ეს სხვაგვარად ხდება). და სხვა პრობლემები შეიძლება უფრო სწრაფად შეამჩნიოთ Redis კლიენტის სერვისების გაფრთხილებით.

გადატანა

როგორ გადავალთ:

• უპირველეს ყოვლისა, თქვენ უნდა მოამზადოთ ბიბლიოთეკა კლასტერთან მუშაობისთვის. ჩვენ ავიღეთ go-redis, როგორც Go-ვერსიის საფუძველს და ცოტათი შევცვალეთ, რომ მოერგოს საკუთარ თავს. ჩვენ განვახორციელეთ Multi-metods მილსადენების მეშვეობით და ასევე ოდნავ შევასწორეთ მოთხოვნების განმეორების წესები. PHP ვერსიას უფრო მეტი პრობლემა ჰქონდა, მაგრამ ჩვენ საბოლოოდ გადავწყვიტეთ php-redis. მათ ახლახან შემოიღეს კლასტერული მხარდაჭერა და ეს კარგად გამოიყურება ჩვენი აზრით.
• შემდეგ თქვენ უნდა განათავსოთ თავად კლასტერი. ეს კეთდება სიტყვასიტყვით ორ ბრძანებაში, რომელიც დაფუძნებულია კონფიგურაციის ფაილზე. ჩვენ უფრო დეტალურად განვიხილავთ პარამეტრს ქვემოთ.
• თანდათანობით გადაადგილებისთვის ვიყენებთ მშრალ რეჟიმს. ვინაიდან ჩვენ გვაქვს ბიბლიოთეკის ორი ვერსია ერთი და იგივე ინტერფეისით (ერთი ჩვეულებრივი ვერსიისთვის, მეორე კლასტერისთვის), არაფერი ღირს შეფუთვის შექმნა, რომელიც იმუშავებს ცალკეულ ვერსიასთან და პარალელურად დუბლირებს ყველა მოთხოვნას კლასტერში. შეადარეთ პასუხები და ჩაწერეთ შეუსაბამობები ჟურნალებში (ჩვენს შემთხვევაში NewRelic-ში). ამრიგად, მაშინაც კი, თუ კლასტერული ვერსია გაფუჭდება გაშვების დროს, ჩვენი წარმოება არ იმოქმედებს.
• კასეტური მშრალ რეჟიმში გაშლის შემდეგ, შეგვიძლია მშვიდად შევხედოთ პასუხების შეუსაბამობების გრაფიკს. თუ შეცდომის მაჩვენებელი ნელა, მაგრამ აუცილებლად მოძრაობს რაიმე მცირე მუდმივობისკენ, მაშინ ყველაფერი კარგადაა. რატომ არის ჯერ კიდევ შეუსაბამობები? იმის გამო, რომ ცალკე ვერსიაში ჩაწერა ხდება ცოტა ადრე, ვიდრე კლასტერში და მიკროლაგის გამო, მონაცემები შეიძლება განსხვავდებოდეს. რჩება მხოლოდ შეუსაბამობის ჟურნალების გადახედვა და თუ ისინი ყველა აიხსნება ჩანაწერის არაატომურობით, მაშინ შეგვიძლია გადავიდეთ.
• ახლა შეგიძლიათ მშრალი რეჟიმის შეცვლა საპირისპირო მიმართულებით. ჩვენ დავწერთ და წავიკითხავთ კლასტერიდან და გავამეორებთ მას ცალკე ვერსიაში. Რისთვის? მომდევნო კვირაში მინდა დავაკვირდე კლასტერის მუშაობას. თუ მოულოდნელად აღმოჩნდება, რომ პიკური დატვირთვის დროს არის პრობლემები, ან რაიმე არ გავითვალისწინეთ, მშრალი რეჟიმის წყალობით ყოველთვის გვაქვს გადაუდებელი დაბრუნება ძველ კოდზე და მიმდინარე მონაცემებზე.
• რჩება მხოლოდ მშრალი რეჟიმის გამორთვა და ცალკეული ვერსიის დემონტაჟი.

ექსპერტიზა

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

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

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

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

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

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

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

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

კონფიგურაცია

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

• ტაიმაუტი 0
  დრო, რომლის შემდეგაც არააქტიური კავშირები იხურება (წამებში). 0 - არ დახუროთ
  ჩვენმა ყველა ბიბლიოთეკამ ვერ შეძლო კავშირების სწორად დახურვა. ამ პარამეტრის გამორთვით, ჩვენ რისკავს კლიენტების რაოდენობის ლიმიტს. მეორეს მხრივ, თუ ასეთი პრობლემაა, მაშინ დაკარგული კავშირების ავტომატური შეწყვეტა დაფარავს მას და შეიძლება ვერ შევამჩნიოთ. გარდა ამისა, თქვენ არ უნდა ჩართოთ ეს პარამეტრი მუდმივი კავშირების გამოყენებისას.
• შეინახეთ xy და მხოლოდ დიახ
  RDB სნეპშოტის შენახვა.
  ქვემოთ დეტალურად განვიხილავთ RDB/AOF საკითხებს.
• stop-writes-on-bgsave-error no & slave-serve-stale-data დიახ
  თუ ჩართულია, თუ RDB სნეპშოტი იშლება, მასტერი შეწყვეტს ცვლილების მოთხოვნების მიღებას. თუ მასტერთან კავშირი დაიკარგება, სლავს შეუძლია განაგრძოს თხოვნებზე პასუხის გაცემა (დიახ). ან შეწყვეტს პასუხს (არა)
  ჩვენ არ გვახარებს ის ვითარება, რომელშიც რედისი გოგრად იქცევა.
• repl-ping-slave-პერიოდი 5
  ამ დროის გასვლის შემდეგ, ჩვენ დავიწყებთ ფიქრს, რომ მასტერი გაფუჭდა და დროა ჩავატაროთ მარცხის პროცედურა.
  თქვენ მოგიწევთ ხელით იპოვოთ ბალანსი ცრუ პოზიტივებსა და მარცხის გამოწვევას შორის. ჩვენს პრაქტიკაში ეს არის 5 წამი.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  ჩვენ შეგვიძლია შევინახოთ ზუსტად ამდენი მონაცემი ბუფერში წარუმატებელი რეპლიკისთვის. თუ ბუფერი ამოიწურება, მოგიწევთ სრული სინქრონიზაცია.
  პრაქტიკა გვთავაზობს, რომ უკეთესია უფრო მაღალი მნიშვნელობის დაყენება. არსებობს უამრავი მიზეზი, რის გამოც რეპლიკა შეიძლება დაიწყოს ჩამორჩენას. თუ ის ჩამორჩება, მაშინ, სავარაუდოდ, თქვენი ოსტატი უკვე იბრძვის გაუმკლავდეს და სრული სინქრონიზაცია ბოლო წვეთი იქნება.
• მაქსიმუმ 10000 კლიენტი
  ერთჯერადი კლიენტების მაქსიმალური რაოდენობა.
  ჩვენი გამოცდილებით, უმჯობესია დავაყენოთ უფრო მაღალი ღირებულება. Redis კარგად უმკლავდება 10k კავშირს. უბრალოდ დარწმუნდით, რომ სისტემაში საკმარისი სოკეტებია.
• maxmemory-policy volatile-ttl
  წესი, რომლითაც კლავიშები იშლება, როდესაც მეხსიერების ხელმისაწვდომი ლიმიტი მიიღწევა.
  აქ მთავარია არა თავად წესი, არამედ იმის გაგება, თუ როგორ მოხდება ეს. Redis შეიძლება შეაქო მისი ნორმალური მუშაობის უნარით, როდესაც მეხსიერების ლიმიტი მიიღწევა.

RDB და AOF პრობლემები

მიუხედავად იმისა, რომ თავად Redis ინახავს ყველა ინფორმაციას RAM-ში, ასევე არსებობს დისკზე მონაცემების შენახვის მექანიზმი. უფრო ზუსტად, სამი მექანიზმი:

• RDB-snapshot - ყველა მონაცემის სრული სურათი. დააყენეთ SAVE XY კონფიგურაციის გამოყენებით და წაიკითხეთ „შეინახეთ ყველა მონაცემის სრული სურათი ყოველ X წამში, თუ მინიმუმ Y კლავიშები შეიცვალა“.
• მხოლოდ დამატებული ფაილი - ოპერაციების სია მათი შესრულების თანმიმდევრობით. ამატებს ახალ შემომავალ ოპერაციებს ფაილში ყოველ X წამში ან ყოველ Y ოპერაციაში.
• RDB და AOF წინა ორის კომბინაციაა.

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

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

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

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

დასკვნა

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

წყარო: www.habr.com