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

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

ბრინჯი. 1. ოთხი განყოფილება განაწილებულია სამ ბროკერს შორის

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

დანაყოფის წარუმატებლობა

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

ბროკერი 3 ტოვებს ქსელს და ახალი ლიდერი აირჩევა მე-2 სექციაში ბროკერ 2-ში.

ბრინჯი. 2. ბროკერი 3 კვდება და მისი მიმდევარი ბროკერ 2-ზე აირჩევა მე-2 დანაყოფის ახალ ლიდერად.

შემდეგ ბროკერი 1 ტოვებს და სექცია 1 ასევე კარგავს თავის ლიდერს, რომლის როლი გადადის ბროკერ 2-ზე.

ბრინჯი. 3. დარჩა ერთი ბროკერი. ყველა ლიდერი ერთ ბროკერზეა ნულოვანი ზედმეტობით

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

ბრინჯი. 4. ლიდერები რჩებიან ბროკერზე 2

როდესაც ბროკერი 3 გამოჩნდება, ჩვენ ვუბრუნდებით სამ რეპლიკას თითო დანაყოფზე. მაგრამ ყველა ლიდერი კვლავ ბროკერ 2-ზეა.

ბრინჯი. 5. 1 და 3 ბროკერების აღდგენის შემდეგ ლიდერების დაუბალანსებელი განლაგება

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

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

ამის გამოსასწორებლად კაფკა ორ ვარიანტს გვთავაზობს:

• ვარიანტი auto.leader.rebalance.enable=true საშუალებას აძლევს კონტროლერ კვანძს ავტომატურად გადაანაწილოს ლიდერები სასურველ რეპლიკებზე და ამით აღადგინოს ერთიანი განაწილება.
• ადმინისტრატორს შეუძლია სკრიპტის გაშვება kafka-preferred-replica-election.შ ხელით გადანაწილებისთვის.

ბრინჯი. 6. რეპლიკა გადაწონასწორების შემდეგ

ეს იყო წარუმატებლობის გამარტივებული ვერსია, მაგრამ რეალობა უფრო რთულია, თუმცა აქ არაფერია ძალიან რთული. ეს ყველაფერი მოდის სინქრონიზებულ რეპლიკებზე (In-Sync Replicas, ISR).

სინქრონიზებული რეპლიკა (ISR)

ISR არის დანაყოფის ასლების ნაკრები, რომელიც ითვლება „სინქრონიზებულად“ (in-sync). არის ლიდერი, მაგრამ შეიძლება არ იყოს მიმდევრები. მიმდევარი სინქრონიზებულად ითვლება, თუ მან გააკეთა ლიდერის ყველა შეტყობინების ზუსტი ასლი ინტერვალის ამოწურვამდე. replica.lag.time.max.ms.

მიმდევარი ამოღებულია ISR ნაკრებიდან, თუ ის:

• ინტერვალის არჩევის მოთხოვნა არ გაუკეთებია replica.lag.time.max.ms (სავარაუდოდ გარდაცვლილი)
• ვერ მოახერხა განახლება ინტერვალის განმავლობაში replica.lag.time.max.ms (ნელა ითვლება)

მიმდევრები აკეთებენ შერჩევის მოთხოვნას ინტერვალში replica.fetch.wait.max.ms, რომელიც ნაგულისხმევია 500 ms.

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

• acks=0, დასტური არ არის გაგზავნილი
• acks=1, დადასტურება იგზავნება მას შემდეგ, რაც ლიდერი დაწერს შეტყობინებას თავის ლოკალურ ჟურნალში
• acks=all, დასტური იგზავნება მას შემდეგ, რაც ISR-ის ყველა რეპლიკა დაწერს შეტყობინებას ლოკალურ ჟურნალებში

კაფკას ტერმინოლოგიით, თუ ISR-მ შეინახა შეტყობინება, ის არის „დადებული“. Acks=all არის ყველაზე უსაფრთხო ვარიანტი, მაგრამ ასევე ამატებს დამატებით შეფერხებას. მოდით შევხედოთ წარუმატებლობის ორ მაგალითს და როგორ ურთიერთქმედებენ სხვადასხვა "შეტევების" ვარიანტები ISR კონცეფციასთან.

Acks=1 და ISR

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

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

ბრინჯი. 7. ISR სამი ასლით

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

ბრინჯი. 8. შეტყობინებები იკარგება, როდესაც ის ავარიულია

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

ბრინჯი. 9. შეტყობინებების გაგზავნა განახლდება მცირე შესვენების შემდეგ

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

ბრინჯი. 10. მე-3 ბროკერზე მიმდევარი ამოღებულია ISR-დან

ბროკერი 1 მცირდება და ლიდერის როლი გადადის ბროკერ 3-ზე 15286 შეტყობინების დაკარგვით! მწარმოებელი იღებს შეტყობინებას კავშირის შეცდომის შესახებ. ISR-ის ფარგლებს გარეთ ლიდერზე გადასვლა მხოლოდ სიტუაციიდან გამომდინარე იყო შესაძლებელი unclean.leader.election.enable=true. თუ ის დაინსტალირებულია ყალბი, მაშინ გადასვლა არ მოხდება და წაკითხვისა და ჩაწერის ყველა მოთხოვნა უარყოფილი იქნება. ამ შემთხვევაში, ჩვენ ველოდებით ბროკერ 1-ს, რომელიც დაბრუნდება თავისი ხელუხლებელი მონაცემებით რეპლიკაში, რომელიც კვლავ აიღებს ხელმძღვანელობას.

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

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

ბრინჯი. 12. მცირე შესვენების შემდეგ შეტყობინებები კვლავ იგზავნება განყოფილებაში 0

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

Acks=ყველა და ISR

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

ბრინჯი. 13. ISR სამი ასლით. ერთი ნელია, რაც იწვევს ჩაწერის დაგვიანებას

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

ბრინჯი. 14. ყველა რეპლიკა ინახავს შეტყობინებებს და აგზავნის შეტყობინებებს

ბროკერი 3 ახლა უფრო ჩამორჩება და ამოღებულია ISR-დან. შეყოვნება მნიშვნელოვნად შემცირდა, რადგან ISR-ში არ არის დარჩენილი ნელი რეპლიკა. ბროკერი 2 ახლა ელოდება მხოლოდ ბროკერ 1-ს და მას აქვს საშუალო ჩამორჩენა 500 ms.

ბრინჯი. 15. ბროკერ 3-ის რეპლიკა ამოღებულია ISR-დან

შემდეგ ბროკერი 2 ეცემა და ლიდერობა გადადის ბროკერ 1-ზე შეტყობინებების დაკარგვის გარეშე.

ბრინჯი. 16. ბროკერი 2 ვარდება

მწარმოებელი პოულობს ახალ ლიდერს და იწყებს მისთვის შეტყობინებების გაგზავნას. შეყოვნება კიდევ უფრო მცირდება, რადგან ISR ახლა შედგება ერთი რეპლიკისგან! ამიტომ ვარიანტი acks=ყველა არ ამატებს ზედმეტობას.

ბრინჯი. 17. ბროკერ 1-ის რეპლიკა ლიდერობს შეტყობინებების დაკარგვის გარეშე

შემდეგ ბროკერი 1 იშლება და ლიდერობა მიდის ბროკერ 3-ზე 14238 შეტყობინებების დაკარგვით!

ბრინჯი. 18. ბროკერი 1 კვდება და ლიდერის გადასვლა უწმინდურ გარემოში იწვევს მონაცემთა ფართო დაკარგვას

ჩვენ ვერ დავაინსტალირეთ ვარიანტი უწმინდური.ლიდერი.არჩევნები.ჩართვა მნიშვნელობაში მართალია. ნაგულისხმევად ტოლია ყალბი. პარამეტრები acks=ყველა с unclean.leader.election.enable=true უზრუნველყოფს ხელმისაწვდომობას ზოგიერთი დამატებითი მონაცემთა უსაფრთხოებით. მაგრამ როგორც ხედავთ, ჩვენ მაინც შეგვიძლია დავკარგოთ შეტყობინებები.

მაგრამ რა მოხდება, თუ ჩვენ გვინდა გავზარდოთ მონაცემთა უსაფრთხოება? შეგიძლიათ დააყენოთ unclean.leader.election.enable = false, მაგრამ ეს სულაც არ გვიცავს მონაცემთა დაკარგვისგან. თუ ლიდერი მძიმედ დაეცა და თან წაიღო მონაცემები, მაშინ შეტყობინებები კვლავ იკარგება, პლუს ხელმისაწვდომობა იკარგება მანამ, სანამ ადმინისტრატორი არ აღადგენს სიტუაციას.

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

Acks=all, min.insync.replicas და ISR

თემის კონფიგურაციით min.insync.replicas ჩვენ ვზრდით მონაცემთა უსაფრთხოების დონეს. მოდით, კვლავ გავიაროთ წინა სცენარის ბოლო ნაწილი, მაგრამ ამჯერად min.insync.replicas=2.

ასე რომ, ბროკერ 2-ს ჰყავს რეპლიკა ლიდერი და ბროკერ 3-ის მიმდევარი ამოღებულია ISR-დან.

ბრინჯი. 19. ISR ორი რეპლიკიდან

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

ბრინჯი. 20. ISR-ების რაოდენობა ერთით ნაკლებია, ვიდრე მითითებულია min.insync.replicas-ში

ეს კონფიგურაცია სწირავს ხელმისაწვდომობას თანმიმდევრულობისთვის. შეტყობინების დადასტურებამდე, ჩვენ ვზრუნავთ, რომ ის დაწერილია მინიმუმ ორ ასლზე. ეს მწარმოებელს ბევრად მეტ ნდობას აძლევს. აქ შეტყობინების დაკარგვა შესაძლებელია მხოლოდ იმ შემთხვევაში, თუ ორი რეპლიკა ერთდროულად ვერ მოხერხდება მოკლე ინტერვალით, სანამ შეტყობინება არ განმეორდება დამატებით მიმდევარზე, რაც ნაკლებად სავარაუდოა. მაგრამ თუ სუპერ პარანოიდი ხართ, შეგიძლიათ დააყენოთ რეპლიკაციის ფაქტორი 5-ზე და min.insync.replicas 3-ით. აქ სამი ბროკერი ერთდროულად უნდა დაეცეს, რომ ჩანაწერი დაკარგოს! რა თქმა უნდა, თქვენ იხდით ამ საიმედოობას დამატებით შეყოვნებაში.

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

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

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

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

ISR-ის მნიშვნელობა

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

ჩვენ თვითონ ვირჩევთ მნიშვნელობას replica.lag.time.max.ms თქვენი საჭიროებების მიხედვით. არსებითად, ეს პარამეტრი ნიშნავს იმას, თუ რამდენი დაყოვნება გვინდა მივიღოთ როდის acks=ყველა. ნაგულისხმევი მნიშვნელობა არის ათი წამი. თუ ეს ძალიან გრძელია თქვენთვის, შეგიძლიათ შეამციროთ. შემდეგ ISR-ში ცვლილებების სიხშირე გაიზრდება, ვინაიდან მიმდევრები უფრო ხშირად წაიშლება და დაემატება.

RabbitMQ უბრალოდ სარკეების ნაკრებია, რომლებიც უნდა გაიმეორონ. ნელი სარკეები შემოაქვს დამატებით შეყოვნებას და მკვდარ სარკეებს შეუძლიათ დაიცადონ, სანამ პაკეტები, რომლებიც შეამოწმებენ თითოეული კვანძის ხელმისაწვდომობას (net tick) პასუხს. ISR საინტერესო გზაა ამ ლატენტური პრობლემების თავიდან ასაცილებლად. მაგრამ ჩვენ რისკავს ზედმეტობის დაკარგვას, რადგან ISR მხოლოდ ლიდერამდე შეიძლება შემცირდეს. ამ რისკის თავიდან ასაცილებლად გამოიყენეთ პარამეტრი min.insync.replicas.

კლიენტთან კავშირის გარანტია

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

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

კაფკას კონსენსუსის არქიტექტურა

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

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

Zookeeper ინახავს კლასტერის მდგომარეობას:

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

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

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

თითოეული სექციის კონტროლერისთვის:

• განაახლებს ინფორმაციას Zookeeper-ში ISR-ისა და ლიდერის შესახებ;
• უგზავნის LeaderAndISRCommand-ს თითოეულ ბროკერს, რომელიც მასპინძლობს ამ დანაყოფის ასლს, აცნობებს ბროკერებს ISR-ისა და ლიდერის შესახებ.

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

თითოეული ლიდერი პასუხისმგებელია ISR-ების დაქირავებაზე. პარამეტრები replica.lag.time.max.ms განსაზღვრავს ვინ შევა იქ. როდესაც ISR იცვლება, ლიდერი ახალ ინფორმაციას გადასცემს Zookeeper-ს.

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

ბრინჯი. 21. კაფკას კონსენსუსი

რეპლიკაციის პროტოკოლი

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

შერჩევის მოთხოვნები, Log End Offset (LEO) და Highwater Mark (HW)

მიგვაჩნია, რომ მიმდევრები პერიოდულად უგზავნიან ლიდერს Fetch-ის მოთხოვნებს. ნაგულისხმევი ინტერვალი არის 500 ms. ეს განსხვავდება RabbitMQ-ისგან იმით, რომ RabbitMQ-ში რეპლიკაცია არ არის ინიცირებული რიგის სარკის მიერ, არამედ მასტერის მიერ. ოსტატი ცვლის სარკეებს.

ლიდერი და ყველა მიმდევარი ინახავს Log End Offset (LEO) და Highwater (HW) ეტიკეტს. LEO ნიშანი ინახავს ბოლო შეტყობინების ოფსეტს ლოკალურ რეპლიკაში, ხოლო HW ინახავს ბოლო ჩაწერის ოფსეტს. გახსოვდეთ, რომ ჩადენის სტატუსისთვის შეტყობინება უნდა დარჩეს ყველა ISR რეპლიკაში. ეს ნიშნავს, რომ LEO ჩვეულებრივ ოდნავ უსწრებს HW-ს.

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

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

ლიდერის მარცხი

როდესაც ლიდერი დაეცემა, Zookeeper აცნობებს კონტროლერს და ის ირჩევს ლიდერის ახალ რეპლიკას. ახალი ლიდერი ადგენს ახალ HW ნიშანს მისი LEO-ს მიხედვით. შემდეგ მიმდევრები იღებენ ინფორმაციას ახალი ლიდერის შესახებ. კაფკას ვერსიიდან გამომდინარე, მიმდევარი ირჩევს ერთ-ერთ ორ სცენარს:

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

მიმდევარს შეიძლება დასჭირდეს ჟურნალის შეკვეცა შემდეგი მიზეზების გამო:

• როდესაც ლიდერი მარცხდება, პირველი მიმდევარი ISR კომპლექტში, რომელიც რეგისტრირებულია Zookeeper-ში, იმარჯვებს არჩევნებში და ხდება ლიდერი. ISR-ზე ყველა მიმდევარს, მიუხედავად იმისა, რომ განიხილება „სინქრონულად“, შესაძლოა არ მიუღია ყოფილი ლიდერისგან ყველა შეტყობინების ასლი. სავსებით შესაძლებელია, რომ გამორჩეულ მიმდევარს არ ჰქონდეს ყველაზე განახლებული ასლი. კაფკა უზრუნველყოფს, რომ არ არსებობს განსხვავება რეპლიკას შორის. ამრიგად, შეუსაბამობების თავიდან აცილების მიზნით, თითოეულმა მიმდევარმა უნდა შეამციროს თავისი ჟურნალი ახალი ლიდერის HW მნიშვნელობამდე მისი არჩევის დროს. ეს არის დაყენების კიდევ ერთი მიზეზი acks=ყველა ასე მნიშვნელოვანია თანმიმდევრულობისთვის.
• შეტყობინებები პერიოდულად იწერება დისკზე. თუ ყველა კლასტერული კვანძი ერთდროულად ვერ მოხერხდა, მაშინ დისკებზე შეინახება სხვადასხვა ოფსეტური რეპლიკა. შესაძლებელია, რომ როდესაც ბროკერები დაბრუნდებიან ონლაინში, არჩეული ახალი ლიდერი მის მიმდევრებს უკან დარჩება, რადგან ის სხვებზე ადრე იყო შენახული დისკზე.

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

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

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

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

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

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

ქვემოთ მოცემულია კავშირის უკმარისობის რამდენიმე სცენარი:

• სცენარი 1: მიმდევარი ვერ ხედავს ლიდერს, მაგრამ მაინც ხედავს ზოოპარკს.
• სცენარი 2: ლიდერი ვერ ხედავს მიმდევრებს, მაგრამ მაინც ხედავს Zookeeper-ს.
• სცენარი 3: მიმდევარი ხედავს ლიდერს, მაგრამ არ ხედავს ზოოპარკს.
• სცენარი 4: ლიდერი ხედავს მიმდევრებს, მაგრამ არ ხედავს ზოოპარკს.
• სცენარი 5: მიმდევარი სრულიად განცალკევებულია კაფკას სხვა კვანძებისგან და Zookeeper-ისგან.
• სცენარი 6: ლიდერი სრულიად განცალკევებულია კაფკას სხვა კვანძებისგან და Zookeeper-ისგან.
• სცენარი 7: კაფკას კონტროლერის კვანძი ვერ ხედავს სხვა კაფკას კვანძს.
• სცენარი 8: კაფკას კონტროლერი ვერ ხედავს Zookeeper-ს.

თითოეულ სცენარს აქვს საკუთარი ქცევა.

სცენარი 1: მიმდევარი ვერ ხედავს ლიდერს, მაგრამ მაინც ხედავს Zookeeper

ბრინჯი. 22. სცენარი 1: სამი ასლის ISR

კავშირის უკმარისობა განასხვავებს ბროკერს 3 ბროკერებისგან 1 და 2, მაგრამ არა Zookeeper-ისგან. ბროკერი 3 ვეღარ აგზავნის მოთხოვნის მიღებას. მას შემდეგ რაც დრო გავიდა replica.lag.time.max.ms ის ამოღებულია ISR-დან და არ მონაწილეობს შეტყობინების მიწოდებაში. კავშირის აღდგენის შემდეგ, ის განაახლებს მოთხოვნის მიღებას და შეუერთდება ISR-ს, როცა ლიდერს დაემთხვევა. Zookeeper გააგრძელებს პინგების მიღებას და ვარაუდობს, რომ ბროკერი ცოცხალი და ჯანმრთელია.

ბრინჯი. 23. სცენარი 1: ბროკერი ამოღებულია ISR-დან, თუ მისგან მოთხოვნის მიღება არ მიიღება replica.lag.time.max.ms ინტერვალში.

არ არის გაყოფილი ტვინის ან კვანძის შეჩერება, როგორც RabbitMQ-ში. ამის ნაცვლად, ჭარბი რაოდენობა მცირდება.

სცენარი 2: ლიდერი ვერ ხედავს მიმდევრებს, მაგრამ მაინც ხედავს Zookeeper-ს

ბრინჯი. 24. სცენარი 2. ლიდერი და ორი მიმდევარი

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

ბრინჯი. 25. სცენარი 2. ISR შემცირდა მხოლოდ ლიდერამდე

სცენარი 3. მიმდევარი ხედავს ლიდერს, მაგრამ არ ხედავს ზოოპარკს

მიმდევარი გამოყოფილია Zookeeper-ისგან, მაგრამ არა ლიდერთან ბროკერისგან. შედეგად, მიმდევარი აგრძელებს მოთხოვნის მიღებას და არის ISR-ის წევრი. Zookeeper აღარ იღებს პინგებს და არეგისტრირებს ბროკერის კრახს, მაგრამ რადგან ის მხოლოდ მიმდევარია, გამოჯანმრთელების შემდეგ არანაირი შედეგი არ მოჰყვება.

ბრინჯი. 26. სცენარი 3: მიმდევარი აგრძელებს ლიდერისთვის მოთხოვნის გაგზავნას

სცენარი 4. ლიდერი ხედავს მიმდევრებს, მაგრამ არ ხედავს Zookeeper

ბრინჯი. 27. სცენარი 4. ლიდერი და ორი მიმდევარი

ლიდერი გამოყოფილია Zookeeper-ისგან, მაგრამ არა მიმდევრების მქონე ბროკერებისგან.

ბრინჯი. 28. სცენარი 4: ლიდერი იზოლირებულია Zookeeper-ისგან

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

Сообщения acks=ყველა არ მიიღებს აღიარებას, რადგან ISR პირველ რიგში ჩართავს ყველა რეპლიკას და შეტყობინებები მათ არ აღწევს. როდესაც თავდაპირველი ლიდერი შეეცდება მათ ამოღებას ISR-დან, ის ამას ვერ შეძლებს და საერთოდ შეწყვეტს რაიმე შეტყობინების მიღებას.

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

ბრინჯი. 29. სცენარი 4. ლიდერი ბროკერ 1-ზე ხდება მიმდევარი ქსელის აღდგენის შემდეგ.

სცენარი 5: მიმდევარი სრულიად განცალკევებულია კაფკას სხვა კვანძებისგან და Zookeeper-ისგან

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

ბრინჯი. 30. სცენარი 5: იზოლირებული მიმდევარი ამოღებულია ISR-დან

სცენარი 6: ლიდერი სრულიად განცალკევებულია კაფკას სხვა კვანძებისგან და Zookeeper-ისგან

ბრინჯი. 31. სცენარი 6. ლიდერი და ორი მიმდევარი

ლიდერი მთლიანად იზოლირებულია თავისი მიმდევრებისგან, კონტროლიორისგან და ზოოპარკის მცველისგან. მოკლე პერიოდის განმავლობაში ის განაგრძობს შენატანების მიღებას acks=1.

ბრინჯი. 32. სცენარი 6: ლიდერის იზოლირება სხვა კაფკასა და ზოოპარკის კვანძებისგან

ვადის გასვლის შემდეგ არ მიიღეს მოთხოვნები replica.lag.time.max.ms, ის შეეცდება ISR-ის შეკუმშვას თავისთვის, მაგრამ ამას ვერ შეძლებს, რადგან Zookeeper-თან კომუნიკაცია არ არის, შემდეგ შეწყვეტს ჩაწერის მიღებას.

ამასობაში Zookeeper მონიშნავს იზოლირებულ ბროკერს გარდაცვლილად და მაკონტროლებელი აირჩევს ახალ ლიდერს.

ბრინჯი. 33. სცენარი 6. ორი ლიდერი

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

ბრინჯი. 34. სცენარი 6: მწარმოებლები გადადიან ახალ ლიდერზე

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

ბრინჯი. 35. სცენარი 6: თავდაპირველი ლიდერი ხდება მიმდევარი ქსელთან კავშირის აღდგენის შემდეგ

ამ სიტუაციაში, ლოგიკური განცალკევება შეიძლება მოხდეს მოკლე პერიოდის განმავლობაში, მაგრამ მხოლოდ იმ შემთხვევაში acks=1 и min.insync.replicas ასევე 1. ლოგიკური განცალკევება ავტომატურად მთავრდება ან ქსელის აღდგენის შემდეგ, როდესაც თავდაპირველი ლიდერი მიხვდება, რომ ის აღარ არის ლიდერი, ან როცა ყველა კლიენტი მიხვდება, რომ ლიდერი შეიცვალა და დაიწყებს ახალ ლიდერს წერილს - რაც არ უნდა მოხდეს პირველი. ნებისმიერ შემთხვევაში, ზოგიერთი შეტყობინება დაიკარგება, მაგრამ მხოლოდ acks=1.

არსებობს ამ სცენარის კიდევ ერთი ვარიანტი, როდესაც ქსელის გაყოფამდე, მიმდევრები ჩამორჩნენ და ლიდერმა შეკუმშა ISR მხოლოდ საკუთარ თავზე. შემდეგ ხდება იზოლირებული კავშირის დაკარგვის გამო. არჩეულია ახალი ლიდერი, მაგრამ თავდაპირველი ლიდერი აგრძელებს ჩანაწერების მიღებას acks=ყველა, რადგან მის გარდა სხვა არავინ არის ISR-ში. ეს ჩანაწერები დაიკარგება ქსელის აღდგენის შემდეგ. ამ ვარიანტის თავიდან აცილების ერთადერთი გზაა min.insync.replicas = 2.

სცენარი 7: კაფკას კონტროლერის კვანძი ვერ ხედავს სხვა კაფკას კვანძს

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

სცენარი 8: კაფკას კონტროლერი ვერ ხედავს Zookeeper-ს

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

დასკვნები სცენარებიდან

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

თუ ლიდერი დაშორდება Zookeeper-ს კავშირის დაკარგვის გამო, ამან შეიძლება გამოიწვიოს შეტყობინებების დაკარგვა acks=1. Zookeeper-თან კომუნიკაციის ნაკლებობა იწვევს მოკლე ლოგიკურ განხეთქილებას ორ ლიდერთან. ეს პრობლემა მოგვარებულია პარამეტრით acks=ყველა.

პარამეტრის min.insync.replicas ორ ან მეტ რეპლიკაში იძლევა დამატებით გარანტიას, რომ ასეთი მოკლევადიანი სცენარები არ გამოიწვევს დაკარგულ შეტყობინებებს, როგორც მე-6 სცენარში.

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

მოდით ჩამოვთვალოთ კაფკაში მონაცემების დაკარგვის ყველა გზა:

• ლიდერის ნებისმიერი წარუმატებლობა, თუ შეტყობინებები დადასტურდა გამოყენებით acks=1
• ლიდერობის ნებისმიერი უწმინდური გადასვლა, ანუ მიმდევარზე ISR-ს გარეთ, თუნდაც acks=ყველა
• ლიდერის იზოლირება Zookeeper-ისგან, თუ შეტყობინებები დადასტურდა გამოყენებით acks=1
• ლიდერის სრული იზოლაცია, რომელმაც უკვე შეამცირა ISR ჯგუფი საკუთარ თავზე. ყველა შეტყობინება დაიკარგება, თუნდაც acks=ყველა. ეს მართალია მხოლოდ იმ შემთხვევაში, თუ min.insync.replicas=1.
• ყველა დანაყოფის კვანძის ერთდროული წარუმატებლობა. იმის გამო, რომ შეტყობინებები აღიარებულია მეხსიერებიდან, ზოგიერთი შეიძლება ჯერ არ იყოს ჩაწერილი დისკზე. სერვერების გადატვირთვის შემდეგ, შესაძლოა რამდენიმე შეტყობინება არ იყოს.

ლიდერობის უწმინდური გადასვლების თავიდან აცილება შესაძლებელია მათი აკრძალვით ან მინიმუმ ორი ზედმეტობის უზრუნველყოფით. ყველაზე გამძლე კონფიგურაცია არის კომბინაცია acks=ყველა и min.insync.replicas 1-ზე მეტი.

RabbitMQ-ისა და Kafka-ს სანდოობის პირდაპირი შედარება

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

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

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

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

კაფკას ფსონი არის ის, რომ თუ შეტყობინება ინახება რამდენიმე კვანძში, მას შეუძლია დაადასტუროს შეტყობინებები მეხსიერებაში მოხვედრისთანავე. ამის გამო, არსებობს ნებისმიერი ტიპის შეტყობინებების დაკარგვის რისკი (თუნდაც acks=ყველა, min.insync.replicas=2) ერთდროული წარუმატებლობის შემთხვევაში.

მთლიანობაში, კაფკა აჩვენებს უკეთესი პროგრამული უზრუნველყოფის შესრულებას და შექმნილია კლასტერებისთვის. სანდოობისთვის საჭიროების შემთხვევაში მიმდევრების რაოდენობა შეიძლება გაიზარდოს 11-მდე. რეპლიკაციის ფაქტორი 5 და ასლების მინიმალური რაოდენობა სინქრონიზაციაში min.insync.replicas=3 გახდის შეტყობინების დაკარგვა ძალიან იშვიათ მოვლენად. თუ თქვენს ინფრასტრუქტურას შეუძლია ამ რეპლიკაციის კოეფიციენტისა და სიჭარბის დონის მხარდაჭერა, მაშინ შეგიძლიათ აირჩიოთ ეს ვარიანტი.

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

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

დაბოლოს, არ დაივიწყოთ შეცდომების შესახებ როგორც RabbitMQ-ის, ასევე Kafka-ს კლასტერიზაციისა და რეპლიკაციის მექანიზმებში. დროთა განმავლობაში, სისტემები გახდა უფრო მომწიფებული და სტაბილური, მაგრამ არცერთი შეტყობინება არ იქნება 100% დაცული დანაკარგისგან! გარდა ამისა, მასშტაბური ავარიები ხდება მონაცემთა ცენტრებში!

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

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

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

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

წყარო: www.habr.com