შეტყობინებების ბროკერების გაგება. შეტყობინებების მიმოწერის მექანიკის სწავლა ActiveMQ-თან და კაფკასთან. თავი 3. კაფკა

მცირე წიგნის თარგმანის გაგრძელება:
შეტყობინებების ბროკერების გაგება
ავტორი: Jakub Korab, გამომცემელი: O'Reilly Media, Inc., გამოცემის თარიღი: 2017 წლის ივნისი, ISBN: 9781492049296.

წინა ნათარგმნი ნაწილი: შეტყობინებების ბროკერების გაგება. შეტყობინებების მიმოწერის მექანიკის სწავლა ActiveMQ-თან და კაფკასთან. თავი 1 შესავალი

თავი 3

კაფკა

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

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

• იყავით უკიდურესად სწრაფი
• მიეცით მეტი გამტარობა შეტყობინებებთან მუშაობისას
• მხარდაჭერა Publisher-Subscriber და Point-to-Point მოდელები
• არ შეანელოთ ტემპი მომხმარებლების დამატებით. მაგალითად, როგორც რიგის, ასევე თემის შესრულება ActiveMQ-ში მცირდება, რადგან მომხმარებლების რაოდენობა იზრდება დანიშნულების ადგილზე.
• იყოს ჰორიზონტალურად მასშტაბური; თუ ერთი ბროკერი, რომელიც აგრძელებს შეტყობინებებს, შეუძლია ამის გაკეთება მხოლოდ დისკის მაქსიმალური სიჩქარით, მაშინ აზრი აქვს ერთი ბროკერის მაგალითზე გადასვლას, რათა გაზარდოს შესრულება.
• შეზღუდეთ წვდომა შეტყობინებების შესანახად და ხელახლა მიღებაზე

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

ერთიანი დანიშნულების მოდელი

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

ამ თავის დარჩენილი ნაწილისთვის, თუ სხვაგვარად არ განვაცხადეთ, ტერმინი „თემა“ ეხება კაფკას თემას.

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

ტერმინები "log" და "pointer" არ ჩანს კაფკას დოკუმენტაცია. ეს კარგად ცნობილი ტერმინები აქ გამოიყენება გაგების დასახმარებლად.

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

სურათი 3-1. კაფკას ტიხრები

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

მესიჯების კითხვა

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

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

კითხვის პრობლემა შეიძლება წარმოდგენილი იყოს შემდეგნაირად:

• თემას აქვს მრავალი დანაყოფი
• მომხმარებელთა მრავალ ჯგუფს შეუძლია ერთდროულად გამოიყენოს თემა
• მომხმარებელთა ჯგუფს შეიძლება ჰქონდეს რამდენიმე ცალკეული შემთხვევა

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

მომხმარებლები და მომხმარებელთა ჯგუფები

საწყის წერტილად ავიღოთ თემა ერთი დანაყოფით (ფიგურა 3-2).

სურათი 3-2. მომხმარებელი კითხულობს დანაყოფიდან

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

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

სურათი 3-3. ორი მომხმარებელი სხვადასხვა მომხმარებელთა ჯგუფში კითხულობს ერთი და იმავე დანაყოფიდან

მომხმარებლები მომხმარებელთა ჯგუფში

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

სურათი 3-4. ორი მომხმარებელი ერთსა და იმავე მომხმარებელთა ჯგუფში კითხულობს ერთი და იმავე დანაყოფიდან

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

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

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

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

ამ პრობლემის გადაჭრის კანონიკური გზა კაფკაში არის ბОმეტი ტიხრები.

დაყოფა

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

სურათი 3-5. ერთი მომხმარებელი კითხულობს რამდენიმე დანაყოფიდან

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

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

სურათი 3-6. ორი მომხმარებელი იმავე მომხმარებელთა ჯგუფში კითხულობს სხვადასხვა ტიხრებიდან

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

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

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

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

შეტყობინებების გაგზავნა

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

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

მე-2 თავში განვიხილეთ ონლაინ ფსონების სცენარი, სადაც დაკავშირებული მოვლენები უნდა დამუშავდეს ერთი მომხმარებლის მიერ:

1. მომხმარებლის ანგარიში კონფიგურირებულია.
2. ფული ირიცხება ანგარიშზე.
3. დადებულია ფსონი, რომელიც ამოიღებს ფულს ანგარიშიდან.

თუ თითოეული მოვლენა არის შეტყობინება, რომელიც გამოქვეყნებულია თემაში, მაშინ ბუნებრივი გასაღები იქნება ანგარიშის ID.
როდესაც შეტყობინება იგზავნება Kafka Producer API-ს გამოყენებით, ის გადაეცემა დანაყოფის ფუნქციას, რომელიც, შეტყობინებისა და კაფკას კლასტერის ამჟამინდელი მდგომარეობის გათვალისწინებით, აბრუნებს დანაყოფის ID, რომელზეც უნდა გაიგზავნოს შეტყობინება. ეს ფუნქცია დანერგილია Java-ში Partitioner ინტერფეისის მეშვეობით.

ეს ინტერფეისი ასე გამოიყურება:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

საკუთარი დაყოფის სტრატეგიის დაწერა

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

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

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

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

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

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

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

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

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

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

პროდიუსერის ხელშეკრულებები

დაყოფა არ არის ერთადერთი, რაც გასათვალისწინებელია შეტყობინებების გაგზავნისას. მოდით გადავხედოთ Producer კლასის send() მეთოდებს Java API-ში:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

მეტი შეტყობინებების წაკითხვის შესახებ

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

ConsumerRecords < K, V > poll(long timeout);

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

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

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

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

1. წაიკითხეთ შეტყობინება წასაკითხად.
2. შეტყობინების დამუშავება.
3. დაადასტურეთ შეტყობინება.

კაფკას მომხმარებელს გააჩნია კონფიგურაციის ვარიანტი enable.auto.commit. ეს არის ხშირად გამოყენებული ნაგულისხმევი პარამეტრი, როგორც ეს ჩვეულებრივ ხდება პარამეტრებთან, რომლებიც შეიცავს სიტყვას "ავტო".

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

კაფკა 0.10-ში კლიენტის კოდი შეიცვალა ისე, რომ დასრულება პერიოდულად ამოქმედდეს კლიენტის ბიბლიოთეკის მიერ, როგორც კონფიგურირებულია. auto.commit.interval.ms. ეს ქცევა არის JMS AUTO_ACKNOWLEDGE და DUPS_OK_ACKNOWLEDGE რეჟიმებს შორის. ავტოკომიტის გამოყენებისას შეტყობინებები შეიძლება განხორციელდეს იმისდა მიუხედავად, იყო თუ არა ისინი რეალურად დამუშავებული - ეს შეიძლება მოხდეს ნელი მომხმარებლის შემთხვევაში. თუ მომხმარებელი შეწყვეტს, შეტყობინებები მიიღებს მომდევნო მომხმარებელს, დაწყებული ვალდებულების პოზიციიდან, რამაც შეიძლება გამოიწვიოს გამოტოვებული შეტყობინება. ამ შემთხვევაში კაფკამ არ დაკარგა შეტყობინებები, კითხვის კოდი უბრალოდ არ ამუშავებდა მათ.

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

როგორც განხილულია „შეტყობინებების კითხვა რიგიდან“ გვერდზე 21, არ არსებობს შეტყობინების ერთჯერადი მიწოდება შეტყობინებების სისტემაში, როდესაც მხედველობაში მიიღება წარუმატებლობის რეჟიმები.

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

თქვენ შეგიძლიათ აკონტროლოთ ხელით ოფსეტური ჩაწერის პროცესი კაფკას სამომხმარებლო API-ში პარამეტრის დაყენებით enable.auto.commit მცდარი და აშკარად გამოძახება ერთ-ერთი შემდეგი მეთოდით:

void commitSync();
void commitAsync();

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

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

• ყალბი შეტყობინების ავტომატური დაბრუნება. მომხმარებლებმა თავად უნდა გაუმკლავდნენ გამონაკლისებს, რომლებიც წარმოიქმნება პრობლემური ტვირთამწეობისა და შეფერხებების გამო, რადგან მათ არ შეუძლიათ დაეყრდნონ ბროკერს შეტყობინებების ხელახლა მიწოდებისთვის.
• გაგზავნეთ შეტყობინებები მრავალ თემაზე ერთ ატომურ ოპერაციაში. როგორც მალე დავინახავთ, სხვადასხვა თემებზე და დანაყოფებზე კონტროლი შეიძლება განთავსდეს კაფკას კლასტერში არსებულ სხვადასხვა მანქანებზე, რომლებიც არ კოორდინირებენ ტრანზაქციებს გაგზავნისას. ამ სტატიის დაწერის დროს გარკვეული სამუშაო გაკეთდა იმისათვის, რომ ეს შესაძლებელი ყოფილიყო KIP-98-ით.
• დააკავშირეთ ერთი გზავნილის კითხვა ერთი თემიდან მეორე მესიჯის გაგზავნასთან. ისევ და ისევ, კაფკას არქიტექტურა დამოკიდებულია ბევრ დამოუკიდებელ მანქანაზე, რომელიც მუშაობს ერთ ავტობუსად და ამის დამალვის მცდელობა არ ხდება. მაგალითად, არ არსებობს API კომპონენტები, რომლებიც საშუალებას მოგცემთ დააკავშიროთ მომხმარებელი и პროდიუსერი გარიგებაში. JMS-ში ეს მოცემულია ობიექტის მიერ სხდომასაიდანაც იქმნება MessageProducers и შეტყობინება მომხმარებელთა.

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

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

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

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

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

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

Მაღალი ხელმისაწვდომობა

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

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

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

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

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

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

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

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

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

პროდიუსერის კონფიგურაციის ნაწილი არის პარამეტრი კისრები, რომელიც განსაზღვრავს რამდენმა რეპლიკამ უნდა დაადასტუროს (დაადასტუროს) შეტყობინების მიღება, სანამ განაცხადის თემა გააგრძელებს გაგზავნას: 0, 1 ან ყველა. თუ დაყენებულია ყველა, მაშინ როდესაც შეტყობინება მიიღება, ლიდერი უგზავნის დადასტურებას პროდიუსერს, როგორც კი მიიღებს ჩანაწერის დადასტურებას (დადასტურებას) თემის პარამეტრით განსაზღვრული რამდენიმე ნიშნით (მათ შორის თავად). min.insync.replicas (ნაგულისხმევი 1). თუ შეტყობინების წარმატებით გამეორება შეუძლებელია, მაშინ პროდიუსერი დააყენებს განაცხადის გამონაკლისს (NotEnoughReplicas ან NotEnoughReplicasAfterAppend).

ტიპიური კონფიგურაცია ქმნის თემას რეპლიკაციის კოეფიციენტით 3 (1 ლიდერი, 2 მიმდევარი თითო დანაყოფზე) და პარამეტრით min.insync.replicas დაყენებულია 2-ზე. ამ შემთხვევაში, კლასტერი საშუალებას მისცემს ერთ-ერთ ბროკერს, რომელიც მართავს თემის დანაყოფის დაშლას კლიენტის აპლიკაციებზე გავლენის გარეშე.

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

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

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

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

შედეგები

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

წინა ნათარგმნი ნაწილი: შეტყობინებების ბროკერების გაგება. შეტყობინებების მიმოწერის მექანიკის სწავლა ActiveMQ-თან და კაფკასთან. Თავი 1

თარგმანი შესრულებულია: tele.gg/middle_java

გაგრძელება იქნება ...

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

გამოიყენება თუ არა კაფკა თქვენს ორგანიზაციაში?

• დიახ

• არარის

• ადრე გამოყენებული, ახლა არა

• ჩვენ ვგეგმავთ გამოყენებას

მისცა ხმა 38 მომხმარებელმა. 8-მა მომხმარებელმა თავი შეიკავა.

წყარო: www.habr.com