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

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

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

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

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

Single Node Resilience Primitives

მდგრადი რიგები/მარშრუტირება

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

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

მუდმივი შეტყობინებები

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

ბრინჯი. 1. მდგრადობის მატრიცა

კლასტერირება რიგის სარკეებით

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

რიგის ასახვა:

• ერთი მთავარი რიგი (მასტერი), რომელიც იღებს ჩაწერისა და წაკითხვის ყველა ბრძანებას
• ერთი ან მეტი სარკე, რომელიც იღებს ყველა შეტყობინებას და მეტამონაცემებს მთავარი რიგიდან. ეს სარკეები არ არის სკალაციისთვის, არამედ მხოლოდ სიჭარბისთვის.

ბრინჯი. 2. რიგის სარკე

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

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (ერთი ოსტატი და ერთი სარკე)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

გამომცემლის დადასტურება

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

წარუმატებლობის რიგი

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

ბრინჯი. 3. მრავალი სარკისებული რიგები და მათი პოლიტიკა

ბროკერი 3 იშლება. გაითვალისწინეთ, რომ რიგის C სარკე ბროკერ 2-ზე დაწინაურებულია მასტერზე. ასევე გაითვალისწინეთ, რომ ახალი სარკე შეიქმნა რიგის C-სთვის ბროკერ 1-ზე. RabbitMQ ყოველთვის ცდილობს შეინარჩუნოს თქვენს პოლიტიკაში მითითებული რეპლიკაციის ფაქტორი.

ბრინჯი. 4. ბროკერი 3 მარცხდება, რაც იწვევს C რიგს ჩავარდნას

შემდეგი ბროკერი 1 მოდის! გვყავს მხოლოდ ერთი ბროკერი. Queue B სარკე დაწინაურებულია ოსტატად.

Fig. 5

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

ამ შემთხვევაში, ბროკერ 1-ის დაკარგვა სრული იყო, ისევე როგორც მონაცემები, ასე რომ, არეკის გარეშე B რიგი მთლიანად დაიკარგა.

ბრინჯი. 6. ბროკერი 1 უბრუნდება მომსახურებას

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

ბრინჯი. 7. ბროკერი 3 უბრუნდება მომსახურებას. ყველა მთავარი რიგები ერთ კვანძზე!

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

სინქრონიზაცია

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

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

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

ბრინჯი. 8. ორი რიგი სხვადასხვა სინქრონიზაციის რეჟიმით

ახლა ჩვენ ვკარგავთ ბროკერ 3-ს.

ბრინჯი. 9. ბროკერი 3 დაეცა

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

ბრინჯი. 10. რიგი A-ს ახალი სარკე იღებს ყველა არსებულ შეტყობინებას, მაგრამ B რიგის ახალი სარკე არა.

ორივე რიგში კიდევ ათი შეტყობინება მოდის. შემდეგ ბროკერი 2 იშლება და რიგი A ბრუნდება უძველეს სარკეში, რომელიც არის ბროკერ 1-ზე. მონაცემების დაკარგვა არ ხდება, როდესაც ის ვერ ხერხდება. რიგში B, არის ოცი შეტყობინება მთავარში და მხოლოდ ათი გზავნილი სარკეში, რადგან ამ რიგში არასოდეს იმეორებდა თავდაპირველ ათი შეტყობინებას.

ბრინჯი. 11. რიგი A ბრუნდება ბროკერ 1-ში შეტყობინებების დაკარგვის გარეშე

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

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

ბრინჯი. 12. რიგი A დაბრუნდება ბროკერ 3-ში შეტყობინებების დაკარგვის გარეშე. რიგი B ბროკერ 3-ში ბრუნდება ათი შეტყობინების დაკარგვით

ჩვენ ასევე შეგვიძლია დავაყენოთ ha-promote-on-failure მნიშვნელობაში when-synced. ამ შემთხვევაში, სარკეში გადაბრუნების ნაცვლად, რიგი დაელოდება სანამ ბროკერი 1 თავისი მონაცემებით დაბრუნდება ონლაინ რეჟიმში. დაბრუნების შემდეგ, მთავარი რიგი დაბრუნდება ბროკერ 1-ზე მონაცემთა დაკარგვის გარეშე. ხელმისაწვდომობა ეწირება მონაცემთა უსაფრთხოებისთვის. მაგრამ ეს არის სარისკო რეჟიმი, რამაც შეიძლება გამოიწვიოს მონაცემების სრული დაკარგვაც კი, რასაც ცოტა ხანში განვიხილავთ.

ბრინჯი. 13. რიგი B მიუწვდომელი რჩება ბროკერი 1-ის დაკარგვის შემდეგ

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

მოდით შევხედოთ მაგალითს. ახლა ძალიან გრძელი რიგები გვაქვს. როგორ შეიძლება ისინი გაიზარდოს ასეთ ზომამდე? რამდენიმე მიზეზის გამო:

• რიგები აქტიურად არ გამოიყენება
• ეს არის მაღალსიჩქარიანი რიგები და ახლა მომხმარებლები ნელია
• ეს არის მაღალსიჩქარიანი რიგები, იყო ხარვეზი და მომხმარებლები იჭერენ

ბრინჯი. 14. ორი დიდი რიგი სხვადასხვა სინქრონიზაციის რეჟიმით

ახლა ბროკერი 3 ეცემა.

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

ბროკერი 3 ბრუნდება ონლაინში და იქმნება ახალი სარკეები. მთავარი რიგი A იწყებს არსებული შეტყობინებების გამეორებას ახალ სარკეში და ამ დროის განმავლობაში რიგი მიუწვდომელია. მონაცემების გამეორებას ორი საათი სჭირდება, რის შედეგადაც ამ რიგს ორი საათი შეწყვეტს!

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

ბრინჯი. 16. სინქრონიზაციის დროს რიგი მიუწვდომელია

ორი საათის შემდეგ, რიგი A ასევე ხელმისაწვდომი ხდება და შეუძლია ხელახლა დაიწყოს წაკითხვისა და წერის მიღება.

ჩემ

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

• always= ჩართულია არასინქრონიზებულ სარკეებზე გადასვლა
• when-synced= მხოლოდ სინქრონიზებულ სარკეზე გადასვლა, წინააღმდეგ შემთხვევაში რიგი ხდება წაუკითხავი და დაუწერელი. რიგი უბრუნდება მომსახურებას, როგორც კი ბროკერი დაბრუნდება

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

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

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

აქ თქვენ უნდა გაითვალისწინოთ შემდეგი:

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

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

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

პრობლემები ha-promote-on-failure=when-synced

იდეა ha-promote-on-failure= როდის-სინქრონიზებული არის ის, რომ ჩვენ თავიდან ავიცილებთ არასინქრონიზებულ სარკეზე გადასვლას და ამით ავიცილებთ მონაცემთა დაკარგვას. რიგი რჩება წაუკითხავი ან ჩასაწერი. ამის ნაცვლად, ჩვენ ვცდილობთ აღვადგინოთ ავარიული ბროკერი ხელუხლებელი მონაცემებით, რათა მან განაახლოს ფუნქციონირება, როგორც მასტერი მონაცემთა დაკარგვის გარეშე.

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

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

ამიტომ, ხელით სინქრონიზაცია (და სინქრონიზაციის წარუმატებლობა) კომბინაციაში ha-promote-on-failure=when-syncedჩემი აზრით საკმაოდ სარისკოა. დოკუმენტები ამბობენ, რომ ეს ვარიანტი არსებობს მონაცემთა უსაფრთხოებისთვის, მაგრამ ეს არის ორმაგი ნაჭერი დანა.

სამაგისტრო გადაბალანსება

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

ხელახალი დაბალანსება შეიძლება იყოს პრობლემური ორი მიზეზის გამო:

• არ არსებობს კარგი ინსტრუმენტები რებალანსის შესასრულებლად
• რიგის სინქრონიზაცია

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

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

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

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

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

კავშირის დაკარგვა

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

RabbitMQ-სთან გვაქვს ორი ძირითადი ვარიანტი:

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

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

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

თუ გამომცემლები უგზავნიან მონაცემებს ორივე ოსტატს, ჩვენ მივიღებთ რიგის ორ განსხვავებულ ასლს.

RabbitMQ-ის სხვადასხვა რეჟიმი უზრუნველყოფს ხელმისაწვდომობას ან თანმიმდევრულობას.

იგნორირების რეჟიმი (ნაგულისხმევი)

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

ბრინჯი. 18. სამი გამომცემელი ასოცირდება სამ ბროკერთან. შიდა, კლასტერი მარშრუტებს ყველა მოთხოვნას ბროკერ 2-ის მთავარ რიგში.

ახლა ჩვენ ვკარგავთ ბროკერ 3-ს. ის ხედავს, რომ სხვა ბროკერები ჩამოცვივდნენ და თავის სარკეს აწვდის მასტერს. ასე ხდება ლოგიკური განცალკევება.

ბრინჯი. 19. ლოგიკური დაყოფა (სპლიტ-ტვინი). ჩანაწერები გადადის ორ მთავარ რიგში და ორი ასლი განსხვავდება.

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

ბრინჯი. 20. ადმინისტრატორი გამორთავს ბროკერ 3-ს.

ბრინჯი. 21. ადმინისტრატორი იწყებს Broker 3-ს და ის უერთდება კლასტერს და კარგავს იქ დარჩენილ ყველა შეტყობინებას.

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

ავტომატური გაჯანსაღების რეჟიმი

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

უმცირესობის რეჟიმის პაუზა

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

ბრინჯი. 22. სამი გამომცემელი ასოცირდება სამ ბროკერთან. შიდა, კლასტერი მარშრუტებს ყველა მოთხოვნას ბროკერ 2-ის მთავარ რიგში.

შემდეგ ბროკერები 1 და 2 გაიყოფა ბროკერი 3-ისგან. იმის ნაცვლად, რომ მათი სარკე ოსტატად დაწინაურდეს, ბროკერი 3 აჩერებს და ხდება მიუწვდომელი.

ბრინჯი. 23. ბროკერი 3 აჩერებს, წყვეტს ყველა კლიენტს და უარყოფს კავშირის მოთხოვნას.

კავშირის აღდგენის შემდეგ, ის უბრუნდება კლასტერს.

მოდით შევხედოთ სხვა მაგალითს, სადაც მთავარი რიგი არის ბროკერ 3-ზე.

ბრინჯი. 24. მთავარი რიგი ბროკერ 3-ზე.

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

ბრინჯი. 25. ბროკერ 2-ზე გადასვლა, თუ ბროკერი 3 მიუწვდომელია.

როდესაც კავშირი აღდგება, ბროკერი 3 შეუერთდება კლასტერს.

ბრინჯი. 26. კლასტერი დაუბრუნდა ნორმალურ მუშაობას.

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

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

მომხმარებელთა კავშირის უზრუნველყოფა

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

ჩვენი ვარიანტები:

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

დასკვნები

RabbitMQ კლასტერირებას აქვს თავისი დადებითი და უარყოფითი მხარეები. ყველაზე სერიოზული ნაკლოვანებებია:

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

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

• არასანდო ქსელი.
• არასანდო საცავი.
• ძალიან გრძელი რიგები.

როდესაც საქმე ეხება მაღალი ხელმისაწვდომობის პარამეტრებს, გაითვალისწინეთ შემდეგი:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (ან autoheal)
• მუდმივი შეტყობინებები
• დარწმუნდით, რომ კლიენტები დაუკავშირდებიან აქტიურ კვანძს, როდესაც ზოგიერთი კვანძი ვერ ხერხდება

თანმიმდევრულობისთვის (მონაცემთა უსაფრთხოებისთვის), გაითვალისწინეთ შემდეგი პარამეტრები:

• გამომცემელი ადასტურებს და ხელით ადასტურებს მომხმარებლის მხრიდან
• ha-promote-on-failure=when-synced, თუ გამომცემლებს შეუძლიათ სცადონ მოგვიანებით და თუ გაქვთ ძალიან საიმედო საცავი! წინააღმდეგ შემთხვევაში დააყენეთ =always.
• ha-sync-mode=automatic (მაგრამ დიდი უმოქმედო რიგებისთვის შეიძლება საჭირო გახდეს მექანიკური რეჟიმი; ასევე განიხილეთ, გამოიწვევს თუ არა მიუწვდომლობა შეტყობინებების დაკარგვას)
• უმცირესობის რეჟიმის პაუზა
• მუდმივი შეტყობინებები

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

თუ კიდევ რამე გამომრჩა, გთხოვთ შემატყობინეთ.

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

სერიის წინა სტატიები:
No1 - habr.com/ru/company/itsumma/blog/416629
No2 - habr.com/ru/company/itsumma/blog/418389
No3 - habr.com/ru/company/itsumma/blog/437446

წყარო: www.habr.com