კაფკასთან მუშაობის შესახებ დეტალურად ისაუბრეთ: როგორ მოხდა შეტყობინებების დუპლიკაციის პროცესი?
Golang
რა ტიპების რეპლიკაცია არსებობს (სინქრონული და ასინქრონული)? როგორ მუშაობს სინქრონული რეპლიკაცია და რა ხარჯები აქვს მას?
გვითხარით გუნდში შემადგენლობაზე, სერვისების პასუხისმგებლობის ზონებზე და გამოშვების ციკლზე.
რატომ შეირჩა gRPC REST-ის ნაცვლად? იყო თუ არა კონკრეტული მოთხოვნები შესრულებაზე?
აბსტრაქტული შემთხვევა: სერვისი ჩერდება (OOM kill), შეცდომები არ ჩანს, მაგრამ პოდში ბოლო სტატუსი მეხსიერების უკმარისობას აჩვენებს. რა იქნება სერვისის დიაგნოსტიკისა და სტაბილიზაციის სერიის ნაბიჯები?
თქვენ პასუხისმგებელი იყავით პროდუქტის ექსპლუატაციაზე? მხარდაჭერა თქვენი გუნდისთვის იყო? შეტყობინებები და მეტრიკები თქვენკენ მიემართებოდა?
რა საჭიროა ტრანზაქციები მონაცემთა ბაზებში?
თუ Kafka-ს დიდი ლაგი გაქვთ, მეტი consumer-ის დამატება დაეხმარება? რა შემთხვევებში დაეხმარება და რა შემთხვევებში არა? თუ 16 partition და 2 consumer-ი გაქვთ, რა მოხდება?
შესაძლოა, შეტყობინებები განაწილებულია ნაწილებად არათანაბრად? როგორ დავამარცხოთ ეს?
თქვენ შეინახეთ Kafka-დან ყველა შეტყობინება ცალკეულ ცხრილში? რა იყო ამ ყველაფრის აზრი, ხომ არ იყო Kafka საკმარისი?
რა საქმიანობით იყავით დაკავებული ბოლო სამუშაო ადგილას? რომელ პროექტზე მუშაობდით?
იქნებოდათ სიდარკარ კონტეინერები ინსტანციებზე? რა არის sidecar?
თქვენ პირდაპირი ურთიერთობა გქონდათ Kubernetes-თან?
რა განსხვავებაა EXPLAIN და EXPLAIN ANALYZE-ს შორის? რატომ არ უნდა გამოიყენოთ EXPLAIN ANALYZE წარმოებაში?
ასეთი შემთხვევისას, როდესაც გაფრთხილება აქტიურდებოდა RPS-ის ზრდის დროს 5000-მდე, რა გითავართ? როგორ განსაზღვრავდით, რეალური დატვირთვის ზრდა იყო თუ სისტემაში პრობლემა?
რატომ გააკეთეთ ხელით commit offset-ის ნაცვლად ავტომატური?
რა იყო კონკრეტულად გამტარუნარიანობის მაჩვენებლები? რამდენი მოთხოვნა იყო ჩვეულებრივ და პიკზე წამში?
როგორ განახორციელეთ Kafka მომხმარებლების მასშტაბირება? რა კრიტერიუმებით?
თუ მონაცემთა ბაზა ხელმისაწვდომი არ არის და თქვენ კვლავ ცდილობთ, ხომ არ გააგრძელებთ ერთსა და იმავე შეტყობინებების უსასრულო დამუშავებას? ყველა 500 DLQ-ში გადავა?
თქვით თქვენი ამბავი.