"ჰადოპ. ZooKeeper" Mail.Ru Group Technostream სერიიდან "დიდი მოცულობის მონაცემების განაწილებული დამუშავების მეთოდები Hadoop-ში"

გირჩევთ წაიკითხოთ ლექციის ჩანაწერი "Hadoop. ZooKeeper" სერიიდან "Hadoop-ში დიდი მოცულობის მონაცემების განაწილებული დამუშავების მეთოდები"

რა არის ZooKeeper, მისი ადგილი Hadoop-ის ეკოსისტემაში. სიცრუე განაწილებული გამოთვლების შესახებ. სტანდარტული განაწილებული სისტემის დიაგრამა. განაწილებული სისტემების კოორდინაციის სირთულე. ტიპიური კოორდინაციის პრობლემები. ZooKeeper-ის დიზაინის პრინციპები. ZooKeeper მონაცემთა მოდელი. znode დროშები. სესიები. კლიენტის API. პრიმიტივები (კონფიგურაცია, ჯგუფის წევრობა, მარტივი საკეტები, ლიდერის არჩევა, ჩაკეტვა ნახირის ეფექტის გარეშე). ZooKeeper არქიტექტურა. ZooKeeper DB. ZAB. მოთხოვნის დამმუშავებელი.

დღეს ვისაუბრებთ ZooKeeper-ზე. ეს ნივთი ძალიან სასარგებლოა. მას, ისევე როგორც Apache Hadoop-ის ნებისმიერ პროდუქტს, აქვს ლოგო. მასზე გამოსახულია მამაკაცი.

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

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

Hadoop-თან დაკავშირებული ყველა აპლიკაციის მსგავსად, ის შეიქმნა Yahoo! ახლა ის ასევე არის ოფიციალური Apache აპლიკაცია. ის არ არის ისეთი აქტიურად განვითარებული, როგორც HBase. თუ თქვენ მიდიხართ JIRA HBase-ში, მაშინ ყოველდღე არის შეცდომების შესახებ შეტყობინებების სიმრავლე, წინადადებების წყება რაღაცის ოპტიმიზაციისთვის, ანუ პროექტში ცხოვრება მუდმივად მიმდინარეობს. ხოლო ZooKeeper, ერთი მხრივ, შედარებით მარტივი პროდუქტია და მეორეს მხრივ, ეს უზრუნველყოფს მის საიმედოობას. და მისი გამოყენება საკმაოდ მარტივია, რის გამოც იგი გახდა სტანდარტი Hadoop-ის ეკოსისტემაში აპლიკაციებში. ამიტომ ვფიქრობდი, რომ სასარგებლო იქნებოდა მისი გადახედვა იმის გასაგებად, თუ როგორ მუშაობს და როგორ გამოვიყენოთ იგი.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

და ეს სქემა (ზემოთ) ალბათ უფრო რთული, მაგრამ უფრო საიმედოა.

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

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

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

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

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

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

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

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

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

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

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

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

ZooKeeper საშუალებას გაძლევთ გადაჭრათ ყველა ეს პრობლემა ამა თუ იმ ხარისხით. და მე გაჩვენებთ მაგალითებით, თუ როგორ გაძლევთ ამის საშუალებას.

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

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

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

ZooKeeper может работать в двух режимах. Первый – это standalone, на одной ноде. Это удобно для тестирования. А также он может работать в режиме кластера, на любом количестве სერვერები. Если у нас кластер – 100 машин, то необязательно, чтобы он работал на 100 машинах. Достаточно выделить несколько машинок, где можно запустить ZooKeeper. И исповедует принцип high availability. На каждом запущенном инстансе ZooKeeper хранит всю копию данных. Позже расскажу, как он это делает. Он не шардит данные, не партиционирует их. С одной стороны – это минус, что мы не можем хранить много, с другой стороны – это делать и не нужно. Он не для этого предназначен, это не база данных.

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

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

კლიენტი არის მომხმარებელი, რომელიც იყენებს ZooKeeper-ს.

სერვერი თავად ZooKeeper პროცესია.

Znode არის მთავარი რამ ZooKeeper-ში. ყველა ზნოდი ინახება მეხსიერებაში ZooKeeper-ის მიერ და ორგანიზებულია იერარქიული დიაგრამის სახით, ხის სახით.

არსებობს ორი სახის ოპერაციები. პირველი არის განახლება/ჩაწერა, როდესაც ზოგიერთი ოპერაცია ცვლის ჩვენი ხის მდგომარეობას. ხე საერთოა.

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

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

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

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

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

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

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

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

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

Немножко расскажу про сессии. Если у нас несколько серверов, то мы можем прозрачно переходить от сервера к სერვერი, используя идентификатор сессии. Это довольно-таки удобно.

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

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

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

თუ არ გვინდა ამ ვერსიის შემოწმება, მაშინ უბრალოდ გადავცემთ "-1" არგუმენტს.

მესამე, ის ამოწმებს ზნოდის არსებობას. აბრუნებს true თუ კვანძი არსებობს, false სხვა შემთხვევაში.

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

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

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

Არსებობს ასევე SetData. აქ ჩვენ გავდივართ ვერსიას. და თუ ამას გადავცემთ, გარკვეული ვერსიის znode-ის მონაცემები განახლდება.

თქვენ ასევე შეგიძლიათ მიუთითოთ "-1" ამ შემოწმების გამოსარიცხად.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

რისგან შედგება ZooKeeper? არის 4 ძირითადი რამ. ეს არის დამუშავების პროცესები - მოთხოვნა. და ასევე ZooKeeper Atomic Broadcast. არსებობს დავალებების ჟურნალი, სადაც ყველა ოპერაცია არის ჩაწერილი. და თავად In-Memory Replicated DB, ანუ თავად მონაცემთა ბაზა, სადაც მთელი ხე ინახება.

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

თავად მონაცემთა ბაზა სრულად არის გამეორებული. ZooKeeper-ის ყველა შემთხვევა ინახავს მონაცემთა სრულ ასლს.

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

ZooKeeper Atomic Broadcast არის ნივთი, რომელიც გამოიყენება გამეორებული მონაცემების შესანარჩუნებლად.

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

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

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

წყარო: www.habr.com