В səhvlərə dözümlülük və yüksək əlçatanlıq üçün RabbitMQ klasterinə baxdıq. İndi Apache Kafkanın dərinliklərinə nəzər salaq.
Burada təkrarlama vahidi bölmədir. Hər bir mövzu bir və ya bir neçə bölmədən ibarətdir. Hər bölmənin ardıcılları olan və ya olmayan bir lideri var. Mövzu yaradarkən siz bölmələrin sayını və təkrarlanma əmsalını təyin edirsiniz. Adi dəyər 3-dür, bu üç replika deməkdir: bir lider və iki izləyici.
düyü. 1. Dörd bölmə üç broker arasında bölüşdürülür
Bütün oxumaq və yazma sorğuları liderə gedir. İzləyicilər vaxtaşırı liderə ən son mesajları almaq üçün sorğu göndərirlər. İstehlakçılar heç vaxt ardıcıllara müraciət etmirlər; sonuncular yalnız ehtiyat və qüsurlara dözümlülük üçün mövcuddur.
Bölmə uğursuzluğu
Broker uğursuz olduqda, bir neçə bölmənin rəhbərləri tez-tez uğursuz olur. Onların hər birində başqa qovşağın izləyicisi lider olur. Əslində, bu, həmişə belə deyil, çünki sinxronizasiya faktoru da təsir göstərir: sinxronlaşdırılmış izləyicilərin olub-olmaması, yoxsa, sinxronlaşdırılmamış replikaya keçidə icazə verilib-verilməməsi. Amma hələlik hər şeyi mürəkkəbləşdirməyək.
Broker 3 şəbəkəni tərk edir və 2-ci brokerdə 2-ci bölmə üçün yeni lider seçilir.
düyü. 2. Broker 3 ölür və onun 2-ci brokerdəki davamçısı 2-ci bölmənin yeni lideri seçilir
Sonra 1-ci broker ayrılır və 1-ci bölmə də öz liderini itirir, onun rolu 2-ci brokerə keçir.
düyü. 3. Bir makler qalıb. Bütün liderlər sıfır ehtiyatla bir brokerdədir
Broker 1 yenidən onlayn olduqda, dörd izləyici əlavə edir və hər bölməyə bir qədər artıqlıq verir. Lakin bütün liderlər hələ də broker 2-də qaldılar.
düyü. 4. Liderlər 2-ci brokerdə qalırlar
Broker 3 ortaya çıxdıqda, hər bölmə üçün üç replikaya qayıdırıq. Lakin bütün liderlər hələ də 2-ci brokerdədir.
düyü. 5. 1 və 3-cü brokerlərin bərpasından sonra liderlərin balanssız yerləşdirilməsi
Kafka, RabbitMQ-dan daha yaxşı liderin yenidən balanslaşdırılması üçün alətə malikdir. Orada, miqrasiya zamanı artıqlığı azaltmaqla master nodu köçürmək üçün siyasətləri dəyişdirən üçüncü tərəf plaginindən və ya skriptindən istifadə etməli idiniz. Bundan əlavə, böyük növbələr üçün sinxronizasiya zamanı əlçatmazlığı qəbul etməli olduq.
Kafka lider rolu üçün “üstünlük verilən replikalar” anlayışına malikdir. Mövzu bölmələri yaradıldıqda, Kafka liderləri qovşaqlar arasında bərabər paylamağa çalışır və həmin ilk liderləri üstünlük kimi qeyd edir. Vaxt keçdikcə, serverin yenidən işə salınması, uğursuzluqlar və əlaqənin pozulması səbəbindən liderlər yuxarıda təsvir edilən ekstremal vəziyyətdə olduğu kimi digər qovşaqlarda da ola bilər.
Bunu düzəltmək üçün Kafka iki variant təklif edir:
- Seçim auto.leader.rebalance.enable=true nəzarətçi qovşağına liderləri avtomatik olaraq üstünlük verilən replikalara yenidən təyin etməyə və bununla da vahid paylanmanı bərpa etməyə imkan verir.
- Administrator skripti işlədə bilər kafka-tercih olunan-replika-seçki.sh əl ilə yenidən təyinat üçün.
düyü. 6. Yenidən balanslaşdırmadan sonra replikalar
Bu, uğursuzluğun sadələşdirilmiş versiyası idi, lakin burada çox mürəkkəb bir şey yoxdur, baxmayaraq ki, reallıq daha mürəkkəbdir. Hamısı sinxronlaşdırılmış replikalara (In-Sync Replicas, ISR) düşür.
Sinxronlaşdırılmış Replikalar (ISR)
ISR, "sinxronlaşdırılmış" (sinxronlaşdırılmış) hesab edilən bölmənin replikaları toplusudur. Lider var, amma ardıcıllar olmaya bilər. Əgər interval bitməmiş liderin bütün mesajlarının dəqiq surətlərini çıxarıbsa, izləyici sinxronlaşdırılmış sayılır. replica.lag.time.max.ms.
İzləyici aşağıdakı hallarda ISR dəstindən çıxarılır:
- intervalı seçmək üçün müraciət etməyib replica.lag.time.max.ms (ölü güman edilir)
- interval ərzində yeniləməyi bacarmadı replica.lag.time.max.ms (yavaş hesab olunur)
İzləyicilər intervalda seçmə sorğuları edir replica.fetch.wait.max.ms, standart olaraq 500ms.
ISR-nin məqsədini aydın şəkildə izah etmək üçün istehsalçının təsdiqləmələrinə və bəzi uğursuzluq ssenarilərinə baxmalıyıq. İstehsalçılar brokerin təsdiqi nə vaxt göndərəcəyini seçə bilərlər:
- acks=0, təsdiq göndərilməyib
- acks=1, lider yerli jurnalına mesaj yazdıqdan sonra təsdiq göndərilir
- acks=all, ISR-dəki bütün replikalar mesajı yerli jurnallara yazdıqdan sonra təsdiq göndərilir
Kafka terminologiyasında, əgər ISR mesajı saxlayıbsa, o, “məsləhətdir”. Acks=all ən təhlükəsiz seçimdir, həm də əlavə gecikmə əlavə edir. Uğursuzluğun iki nümunəsinə və müxtəlif 'acks' variantlarının ISR konsepsiyası ilə necə qarşılıqlı əlaqəsinə baxaq.
Acks=1 və ISR
Bu misalda biz görəcəyik ki, əgər lider bütün izləyicilərdən gələn hər mesajın saxlanmasını gözləmirsə, lider uğursuz olarsa, məlumat itkisi mümkündür. Sinxronlaşdırılmamış izləyiciyə naviqasiya parametrlə aktivləşdirilə və ya söndürülə bilər natəmiz.lider.seçki.aktiv etmək.
Bu nümunədə istehsalçı acks=1 dəyərinə malikdir. Bölmə hər üç broker arasında paylanmışdır. Broker 3 geridədir, o, səkkiz saniyə əvvəl liderlə sinxronlaşıb və indi 7456 mesaj geridədir. Broker 1 yalnız bir saniyə geridə qaldı. Prodüserimiz mesaj göndərir və liderin gözləmədiyi yavaş və ya ölü izləyicilər olmadan tez bir şəkildə cavab alır.
düyü. 7. Üç replika ilə ISR
Broker 2 uğursuz olur və istehsalçı əlaqə xətası alır. Rəhbərlik 1-ci brokerə keçdikdən sonra biz 123 mesaj itiririk. Broker 1-dəki izləyici ISR-nin bir hissəsi idi, lakin o, düşdükdə liderlə tam sinxronlaşdırılmadı.
düyü. 8. Qəza zamanı mesajlar itir
Konfiqurasiyada bootstrap.servers İstehsalçının siyahıda bir neçə brokeri var və yeni bölmə lideri olan başqa brokerdən soruşa bilər. Daha sonra o, broker 1 ilə əlaqə qurur və mesaj göndərməyə davam edir.
düyü. 9. Qısa fasilədən sonra mesajların göndərilməsi davam edir
Broker 3 daha da geridədir. O, gətirmə sorğuları verir, lakin sinxronizasiya edə bilmir. Bunun səbəbi brokerlər arasında yavaş şəbəkə bağlantısı, saxlama problemi və s. ola bilər. O, ISR-dən çıxarılıb. İndi ISR bir replikadan ibarətdir - lider! İstehsalçı mesajlar göndərməyə və təsdiqləri almağa davam edir.
düyü. 10. Broker 3-də izləyici ISR-dən çıxarılır
Broker 1 aşağı düşür və liderlik rolu 3 mesaj itkisi ilə 15286-cü brokerə keçir! İstehsalçı əlaqə xətası mesajı alır. ISR-dən kənar liderə keçid yalnız tənzimləmə sayəsində mümkün oldu unclean.leader.election.enable=true. Əgər quraşdırılıbsa saxta, onda keçid baş verməyəcək və bütün oxumaq və yazma sorğuları rədd ediləcək. Bu halda, biz 1-ci brokerin yenidən liderliyi ələ keçirəcək replikada bütöv məlumatları ilə qayıtmasını gözləyirik.
düyü. 11. Broker 1 düşür. Bir uğursuzluq baş verdikdə, çox sayda mesaj itirilir
Prodüser sonuncu brokerlə əlaqə qurur və görür ki, o, indi bölmənin rəhbəridir. O, 3-cü brokerə mesajlar göndərməyə başlayır.
düyü. 12. Qısa fasilədən sonra mesajlar yenidən 0-cı bölməyə göndərilir
Biz gördük ki, yeni əlaqələr qurmaq və yeni lider axtarmaq üçün qısa fasilələrlə yanaşı, istehsalçı davamlı olaraq mesajlar göndərir. Bu konfiqurasiya ardıcıllıq (məlumat təhlükəsizliyi) hesabına mövcudluğu təmin edir. Kafka minlərlə mesajı itirdi, lakin yeni yazıları qəbul etməyə davam etdi.
Acks=hamısı və ISR
Gəlin bu ssenarini bir daha təkrar edək, lakin bununla acks=hamısı. Broker 3-ün orta gecikmə müddəti dörd saniyədir. İstehsalçı ilə mesaj göndərilir acks=hamısı, və indi tez cavab almır. Lider mesajın ISR-dəki bütün replikalar tərəfindən saxlanmasını gözləyir.
düyü. 13. Üç replika ilə ISR. Biri yavaşdır, nəticədə qeyd gecikmələri olur
Dörd saniyə əlavə gecikmədən sonra 2-ci broker ack göndərir. Bütün replikalar indi tam yenilənir.
düyü. 14. Bütün replikalar mesajları saxlayır və ack göndərir
Broker 3 indi daha da geri qalır və ISR-dən çıxarılır. ISR-də heç bir yavaş replika qalmadığından gecikmə əhəmiyyətli dərəcədə azalır. Broker 2 indi yalnız 1-ci brokeri gözləyir və onun orta hesabla 500 ms gecikməsi var.
düyü. 15. Broker 3-dəki replika ISR-dən çıxarılır
Sonra 2-ci broker düşür və liderlik mesajları itirmədən 1-ci brokerə keçir.
düyü. 16. Broker 2 düşür
İstehsalçı yeni lider tapır və ona mesajlar göndərməyə başlayır. ISR indi bir replikadan ibarət olduğu üçün gecikmə daha da azaldılır! Buna görə də seçim acks=hamısı artıqlıq əlavə etmir.
düyü. 17. Broker 1-dəki replika mesajları itirmədən liderlik edir
Sonra 1-ci broker çökür və aparıcı 3 mesaj itkisi ilə 14238-cü brokerə keçir!
düyü. 18. Broker 1 ölür və natəmiz qəbulu ilə liderlik keçidi geniş məlumat itkisi ilə nəticələnir
Seçimi quraşdıra bilmədik natəmiz.lider.seçki.aktiv etmək mənaya keçir doğru. Varsayılan olaraq bərabərdir saxta. Parametrlər acks=hamısı с unclean.leader.election.enable=true bəzi əlavə məlumat təhlükəsizliyi ilə əlçatanlığı təmin edir. Ancaq gördüyünüz kimi, hələ də mesajları itirə bilərik.
Bəs məlumat təhlükəsizliyini artırmaq istəsək nə olacaq? qoymaq olar unclean.leader.election.enable = yalan, lakin bu, bizi məlumat itkisindən mütləq qorumayacaq. Lider sərt yıxılıbsa və məlumatları özü ilə götürübsə, mesajlar hələ də itirilir, üstəlik administrator vəziyyəti bərpa edənə qədər mövcudluq itirilir.
Bütün mesajların lazımsız olmasını təmin etmək və əks halda qeydi silmək daha yaxşıdır. Daha sonra, ən azı broker baxımından, məlumat itkisi yalnız iki və ya daha çox eyni vaxtda uğursuzluq halında mümkündür.
Acks=hamısı, min.insync.replicas və ISR
Mövzu konfiqurasiyası ilə min.insync.replikalar Biz məlumatların təhlükəsizliyi səviyyəsini artırırıq. Əvvəlki ssenarinin son hissəsini yenidən nəzərdən keçirək, amma bu dəfə min.insync.replicas=2.
Beləliklə, broker 2-də replika lideri var və 3-cü brokerdəki izləyici ISR-dən çıxarılır.
düyü. 19. İki replikadan ISR
Broker 2 düşür və liderlik mesajları itirmədən 1-ci brokerə keçir. Amma indi ISR yalnız bir replikadan ibarətdir. Bu, qeydləri almaq üçün minimum rəqəmə uyğun gəlmir və buna görə də broker yazma cəhdinə xəta ilə cavab verir NotEnoughReplicas.
düyü. 20. ISR-lərin sayı min.insync.replicas-da göstəriləndən bir azdır
Bu konfiqurasiya ardıcıllıq üçün əlçatanlığı qurban verir. Mesajı qəbul etməzdən əvvəl onun ən azı iki replikaya yazıldığını təmin edirik. Bu, istehsalçıya daha çox inam verir. Burada mesajın itirilməsi yalnız iki replika mesaj əlavə izləyiciyə təkrarlanana qədər qısa bir intervalda eyni vaxtda uğursuz olarsa mümkündür ki, bu da mümkün deyil. Ancaq super paranoyaksınızsa, replikasiya faktorunu 5-ə təyin edə bilərsiniz və min.insync.replikalar tərəfindən 3. Burada rekordu itirmək üçün üç broker eyni anda düşməlidir! Əlbəttə ki, bu etibarlılıq üçün əlavə gecikmə zamanı ödəyirsiniz.
Məlumat təhlükəsizliyi üçün əlçatanlıq lazım olduqda
İçində olduğu kimi , bəzən məlumat təhlükəsizliyi üçün əlçatanlıq tələb olunur. Bu barədə düşünmək lazımdır:
- Naşir sadəcə xəta qaytara və yuxarı xidmət və ya istifadəçiyə daha sonra yenidən cəhd edə bilərmi?
- Naşir sonra yenidən cəhd etmək üçün mesajı yerli və ya verilənlər bazasında saxlaya bilərmi?
Cavab xeyrdirsə, əlçatanlığın optimallaşdırılması məlumat təhlükəsizliyini yaxşılaşdırır. Qeydə almamaq əvəzinə əlçatanlığı seçsəniz, daha az data itirəcəksiniz. Beləliklə, hər şey tarazlıq tapmağa gəlir və qərar konkret vəziyyətdən asılıdır.
ISR mənası
ISR dəsti məlumat təhlükəsizliyi və gecikmə arasında optimal balansı seçməyə imkan verir. Məsələn, gecikmə baxımından ölü və ya yavaş replikaların təsirini minimuma endirərək, əksər replikaların uğursuzluğu halında mövcudluğu təmin edin.
Mənanı özümüz seçirik replica.lag.time.max.ms ehtiyaclarınıza uyğun olaraq. Əslində, bu parametr nə qədər gecikməni nə vaxt qəbul etməyə hazır olduğumuzu bildirir acks=hamısı. Varsayılan dəyər on saniyədir. Əgər bu sizin üçün çox uzundursa, onu azalda bilərsiniz. Sonra ISR-də dəyişikliklərin tezliyi artacaq, çünki izləyicilər silinəcək və daha tez-tez əlavə olunacaq.
RabbitMQ sadəcə təkrarlanması lazım olan güzgülər toplusudur. Yavaş güzgülər əlavə gecikmə təqdim edir və ölü güzgülər hər bir node (şəbəkə işarəsi) mövcudluğunu yoxlayan paketlərin cavab verməsini gözləyə bilər. ISR bu gecikmə problemlərindən qaçmaq üçün maraqlı bir yoldur. Lakin biz artıqlığı itirmək riskimiz var, çünki ISR yalnız liderə qədər kiçilə bilər. Bu riskdən qaçmaq üçün parametrdən istifadə edin min.insync.replikalar.
Müştəri əlaqəsinə zəmanət
Ayarlarında bootstrap.servers istehsalçı və istehlakçı müştəriləri birləşdirmək üçün bir neçə broker təyin edə bilər. İdeya ondan ibarətdir ki, bir node aşağı düşəndə müştərinin əlaqə aça biləcəyi bir neçə ehtiyat qalır. Bunlar mütləq bölmə rəhbərləri deyil, sadəcə ilkin yükləmə üçün tramplindir. Müştəri onlardan oxu/yazma bölmə liderinin hansı node olduğunu soruşa bilər.
RabbitMQ-da müştərilər istənilən node-a qoşula bilər və daxili marşrutlaşdırma sorğunu getməli olduğu yerə göndərir. Bu o deməkdir ki, siz RabbitMQ qarşısında yük balanslayıcı quraşdıra bilərsiniz. Kafka müştərilərdən müvafiq bölmə liderini saxlayan node ilə əlaqə qurmağı tələb edir. Belə bir vəziyyətdə, yük balanslaşdırıcısını quraşdıra bilməzsiniz. Siyahı bootstrap.servers Müştərilərin uğursuzluqdan sonra düzgün qovşaqlara daxil ola bilməsi və tapa bilməsi vacibdir.
Kafka Konsensus Memarlığı
İndiyədək biz klasterin brokerin yıxıldığını və yeni rəhbərin necə seçildiyini necə öyrəndiyini düşünməmişik. Kafkanın şəbəkə bölmələri ilə necə işlədiyini başa düşmək üçün əvvəlcə konsensus arxitekturasını başa düşməlisiniz.
Hər bir Kafka klasteri Zookeeper klasteri ilə birlikdə yerləşdirilir ki, bu da sistemə müəyyən vəziyyətlə bağlı konsensus əldə etməyə imkan verən, mövcudluqdan daha çox ardıcıllığa üstünlük verən paylanmış konsensus xidmətidir. Oxuma və yazma əməliyyatlarını təsdiqləmək üçün Zookeeper qovşaqlarının əksəriyyətinin razılığı tələb olunur.
Zookeeper klasterin vəziyyətini saxlayır:
- Mövzular, bölmələr, konfiqurasiya, cari lider replikaları, üstünlük verilən replikaların siyahısı.
- Klaster üzvləri. Hər bir broker Zookeeper klasterinə ping edir. Müəyyən bir müddət ərzində ping almazsa, Zookeeper brokeri əlçatmaz kimi qeyd edir.
- Nəzarətçi üçün əsas və ehtiyat qovşaqların seçilməsi.
Nəzarətçi node replika liderlərinin seçilməsindən məsul olan Kafka brokerlərindən biridir. Zookeeper klaster üzvlüyü və mövzu dəyişiklikləri haqqında nəzarətçiyə bildirişlər göndərir və nəzarətçi bu dəyişikliklərə uyğun hərəkət etməlidir.
Məsələn, on arakəsmə və təkrarlanma əmsalı 3 olan yeni mövzunu götürək. Nəzarətçi hər bölmə üçün lider seçməli, liderləri brokerlər arasında optimal şəkildə bölüşdürməyə çalışmalıdır.
Hər bölmə nəzarətçisi üçün:
- Zookeeper-də ISR və lider haqqında məlumatları yeniləyir;
- Bu bölmənin replikasını saxlayan hər bir brokerə bir LeaderAndISRCommand göndərir, brokerləri ISR və lider haqqında məlumatlandırır.
Lideri olan broker yıxıldıqda, Zookeeper nəzarətçiyə bildiriş göndərir və o, yeni lider seçir. Yenə də nəzarətçi əvvəlcə Zookeeper-i yeniləyir və sonra hər bir brokerə rəhbərlik dəyişikliyi barədə bildiriş göndərir.
Hər bir lider ISR-lərin işə götürülməsinə cavabdehdir. Parametrlər replica.lag.time.max.ms ora kimin girəcəyini müəyyən edir. ISR dəyişdikdə, lider Zookeeperə yeni məlumatları ötürür.
Zookeper hər hansı bir dəyişiklik barədə həmişə məlumatlandırılır ki, uğursuzluq halında rəhbərlik rahat şəkildə yeni rəhbərə keçsin.
düyü. 21. Kafka Konsensus
Replikasiya protokolu
Replikasiyanın təfərrüatlarını başa düşmək potensial məlumat itkisi ssenarilərini daha yaxşı başa düşməyə kömək edir.
Nümunə sorğuları, Log End Offset (LEO) və Highwater Mark (HW)
Biz hesab etdik ki, izləyicilər vaxtaşırı liderə gətirmə sorğuları göndərirlər. Standart interval 500ms-dir. Bu, RabbitMQ-dan onunla fərqlənir ki, RabbitMQ-da replikasiya növbə güzgüsü tərəfindən deyil, master tərəfindən başlanır. Usta dəyişiklikləri güzgülərə itələyir.
Lider və bütün ardıcıllar Log End Offset (LEO) və Highwater (HW) etiketini saxlayırlar. LEO işarəsi yerli replikada son mesajın ofsetini, HW isə sonuncu öhdəliyin ofsetini saxlayır. Unutmayın ki, öhdəçilik statusu üçün mesaj bütün ISR replikalarında davamlı olmalıdır. Bu o deməkdir ki, LEO adətən HW-dən bir qədər irəlidədir.
Lider mesaj aldıqda onu yerli olaraq saxlayır. İzləyici, LEO-nu ötürərək, gətirmə sorğusu edir. Lider daha sonra bu LEO-dan başlayaraq mesajlar toplusu göndərir və cari HW-ni də ötürür. Lider bütün replikaların mesajı verilmiş ofsetdə saxladığı barədə məlumat aldıqda, HW işarəsini hərəkət etdirir. Yalnız lider HW-ni hərəkət etdirə bilər və beləliklə, bütün izləyicilər onların sorğusuna verilən cavabların cari dəyərini biləcəklər. Bu o deməkdir ki, izləyicilər həm mesaj, həm də HW biliklərində liderdən geri qala bilər. İstehlakçılar yalnız cari HW-ə qədər mesajlar alırlar.
Qeyd edək ki, “davamlı” diskə deyil, yaddaşa yazılmaq deməkdir. Performans üçün Kafka müəyyən intervalda diskə sinxronizasiya edir. RabbitMQ-da da belə bir interval var, lakin o, yalnız master və bütün güzgülər mesajı diskə yazdıqdan sonra naşirə bildiriş göndərəcək. Kafka tərtibatçıları performans səbəbi ilə mesaj yaddaşa yazılan kimi bir akk göndərməyə qərar verdilər. Kafka mərc edir ki, artıqlıq təsdiq edilmiş mesajların yalnız yaddaşda qısa müddətə saxlanması riskini kompensasiya edir.
Lider uğursuzluğu
Lider yıxıldıqda Zookeeper nəzarətçini xəbərdar edir və o, yeni lider replikasını seçir. Yeni lider LEO-ya uyğun olaraq yeni HW işarəsi qoyur. İzləyicilər daha sonra yeni lider haqqında məlumat alırlar. Kafkanın versiyasından asılı olaraq izləyici iki ssenaridən birini seçəcək:
- O, yerli jurnalı məlum HW-ə kəsəcək və bu işarədən sonra mesajlar üçün yeni liderə sorğu göndərəcək.
- Rəhbər seçildiyi zaman HW-ni öyrənmək üçün liderə sorğu göndərəcək və sonra jurnalı bu ofsetə kəsəcək. Daha sonra bu ofsetdən başlayaraq dövri gətirmə sorğuları etməyə başlayacaq.
İzləyici aşağıdakı səbəblərə görə jurnalı kəsməli ola bilər:
- Lider uğursuz olduqda, Zookeeper-də qeydiyyatdan keçmiş ISR dəstindəki ilk izləyici seçkidə qalib gəlir və lider olur. ISR-dəki bütün izləyicilər “sinxronlaşdırılmış” hesab olunsalar da, keçmiş liderdən bütün mesajların surətlərini almamış ola bilərlər. Təqdim olunan izləyicinin ən müasir nüsxəsinin olmaması tamamilə mümkündür. Kafka replikalar arasında fərqin olmadığını təmin edir. Beləliklə, uyğunsuzluqların qarşısını almaq üçün hər bir izləyici öz jurnalını yeni liderin seçildiyi zaman onun HW dəyərinə uyğunlaşdırmalıdır. Bu, qurulmasının başqa bir səbəbidir acks=hamısı ardıcıllıq üçün çox vacibdir.
- Mesajlar vaxtaşırı diskə yazılır. Bütün klaster qovşaqları eyni vaxtda uğursuz olarsa, müxtəlif ofsetlərə malik replikalar disklərdə saxlanılacaq. Mümkündür ki, brokerlər yenidən onlayn olduqda, seçilən yeni lider digərlərindən əvvəl diskdə saxlandığı üçün ardıcıllarının arxasında olacaq.
Çoxluq ilə birləşmə
Klasterə yenidən qoşulduqda, replikalar lider uğursuz olduqda olduğu kimi edir: onlar liderin replikasını yoxlayır və jurnalını onun HW-yə (seçki zamanı) kəsir. Müqayisə üçün, RabbitMQ yenidən birləşən qovşaqları tamamilə yeni kimi qəbul edir. Hər iki halda, broker hər hansı mövcud vəziyyəti ləğv edir. Avtomatik sinxronizasiya istifadə edilərsə, usta "bütün dünya gözləsin" metodu ilə tamamilə bütün cari məzmunu yeni güzgüdə təkrarlamalıdır. Master bu əməliyyat zamanı heç bir oxu və ya yazma əməliyyatını qəbul etmir. Bu yanaşma böyük növbələrdə problemlər yaradır.
Kafka paylanmış jurnaldır və ümumiyyətlə o, oxunduqdan sonra verilənlərin növbədən silindiyi RabbitMQ növbəsindən daha çox mesaj saxlayır. Aktiv növbələr nisbətən kiçik qalmalıdır. Ancaq Kafka günlər və ya həftələr müddəti təyin edə bilən özünəməxsus saxlama siyasəti olan bir jurnaldır. Növbənin bloklanması və tam sinxronizasiya yanaşması paylanmış jurnal üçün tamamilə qəbuledilməzdir. Əvəzində, Kafka ardıcılları, əgər onların surəti liderdən qabaqdırsa, sadəcə olaraq öz jurnallarını liderin HW-yə (seçilməsi zamanı) kəsirlər. Daha çox ehtimal olunan halda, izləyici geridə qaldıqda, sadəcə cari LEO-dan başlayaraq gətirmə sorğuları etməyə başlayır.
Yeni və ya yenidən qoşulmuş izləyicilər ISR-dən kənarda başlayırlar və öhdəliklərdə iştirak etmirlər. Onlar sadəcə olaraq qrupla yanaşı işləyirlər, liderə çatana və ISR-ə daxil olana qədər mümkün qədər tez mesajlar alırlar. Heç bir kilid yoxdur və bütün məlumatlarınızı atmağa ehtiyac yoxdur.
Bağlantının pozulması
Kafka RabbitMQ-dan daha çox komponentə malikdir, buna görə də klaster əlaqəsi kəsildikdə daha mürəkkəb davranışlar toplusuna malikdir. Lakin Kafka əvvəlcə klasterlər üçün nəzərdə tutulmuşdu, ona görə də həllər çox yaxşı düşünülmüşdür.
Aşağıda bir neçə əlaqə nasazlığı ssenarisi verilmişdir:
- Ssenari 1: Təqibçi lideri görmür, amma yenə də Zookeperi görür.
- Ssenari 2: Lider heç bir izləyici görmür, lakin Zookeeperi görür.
- Ssenari 3: İzləyici lideri görür, lakin Zookeperi görmür.
- Ssenari 4: Lider ardıcılları görür, lakin Zookeperi görmür.
- Ssenari 5: İzləyici həm digər Kafka qovşaqlarından, həm də Zookeeper-dən tamamilə ayrıdır.
- Ssenari 6: Lider həm digər Kafka qovşaqlarından, həm də Zookeeperdən tamamilə ayrıdır.
- Ssenari 7: Kafka nəzarətçi qovşağı başqa bir Kafka qovşağını görə bilmir.
- Ssenari 8: Kafka nəzarətçisi Zookeeper-i görmür.
Hər bir ssenarinin öz davranışı var.
Ssenari 1: İzləyici lideri görmür, lakin Zookeeperi görür
düyü. 22. Ssenari 1: Üç replikanın ISR
Bağlantı nasazlığı 3-cü brokeri 1 və 2-ci brokerlərdən ayırır, lakin Zookeeper-dən deyil. Broker 3 daha gətirmə sorğuları göndərə bilməz. Vaxt keçdikdən sonra replica.lag.time.max.ms o, ISR-dən çıxarılır və mesajların qəbulunda iştirak etmir. Bağlantı bərpa edildikdən sonra o, sorğuları bərpa etməyə davam edəcək və liderə çatdıqda ISR-ə qoşulacaq. Zookeeper pingləri almağa davam edəcək və brokerin sağ və sağlam olduğunu güman edəcək.
düyü. 23. Ssenari 1: replica.lag.time.max.ms intervalında heç bir gətirmə sorğusu alınmazsa, broker ISR-dən çıxarılır.
RabbitMQ-da olduğu kimi bölünmüş beyin və ya node dayandırılması yoxdur. Əksinə, artıqlıq azalır.
Ssenari 2: Lider heç bir izləyici görmür, lakin Zookeeperi görür
düyü. 24. Ssenari 2. Lider və iki ardıcıl
Şəbəkə bağlantısının pozulması lideri izləyicilərdən ayırır, lakin broker hələ də Zookeeper-i görə bilər. Birinci ssenaridə olduğu kimi, ISR daralır, lakin bu dəfə yalnız liderə aiddir, çünki bütün izləyicilər gətirmə sorğuları göndərməyi dayandırır. Yenə də məntiqi bölgü yoxdur. Bunun əvəzinə, əlaqə bərpa olunana qədər yeni mesajlar üçün ehtiyat itkisi var. Zookeeper ping almağa davam edir və brokerin sağ və sağlam olduğuna inanır.
düyü. 25. Ssenari 2. ISR yalnız liderə qədər azaldı
Ssenari 3. İzləyici lideri görür, lakin Zookeperi görmür
İzləyici Zookeeperdən ayrılır, lakin liderlə brokerdən deyil. Nəticədə, izləyici gətirmə sorğuları etməyə və ISR-nin üzvü olmağa davam edir. Zookeeper artıq pingləri qəbul etmir və broker qəzasını qeyd etmir, lakin o, yalnız izləyici olduğu üçün bərpa edildikdən sonra heç bir nəticə yoxdur.
düyü. 26. Ssenari 3: İzləyici liderə gətirmə sorğuları göndərməyə davam edir
Ssenari 4. Lider izləyiciləri görür, lakin Zookeeperi görmür
düyü. 27. Ssenari 4. Lider və iki ardıcıl
Lider Zookeeperdən ayrılır, lakin ardıcılları olan brokerlərdən deyil.
düyü. 28. Ssenari 4: Zookeperdən təcrid olunmuş lider
Bir müddət sonra Zookeeper broker nasazlığını qeyd edəcək və bu barədə nəzarətçini xəbərdar edəcək. O, izləyiciləri arasından yeni lider seçəcək. Bununla belə, orijinal lider lider olduğunu düşünməyə davam edəcək və daxil olanları qəbul etməyə davam edəcək acks=1. İzləyicilər artıq ona gətirmə sorğuları göndərmirlər, ona görə də o, onları ölü hesab edəcək və ISR-ni özünə qaytarmağa çalışacaq. Lakin Zookeeper ilə əlaqəsi olmadığı üçün o, bunu edə bilməyəcək və bu zaman hər hansı əlavə girişləri qəbul etməkdən imtina edəcək.
Сообщения acks=hamısı ISR əvvəlcə bütün replikaları işə saldığından və mesajlar onlara çatmadığı üçün təsdiq almayacaq. Orijinal lider onları ISR-dən silməyə çalışdıqda, bunu edə bilməyəcək və ümumiyyətlə hər hansı mesajı qəbul etməyi dayandıracaq.
Müştərilər tezliklə lider dəyişikliyini hiss edir və qeydləri yeni serverə göndərməyə başlayırlar. Şəbəkə bərpa edildikdən sonra, ilkin lider onun artıq lider olmadığını görür və log fərqinin qarşısını almaq üçün uğursuzluq zamanı yeni liderin malik olduğu HW dəyərinə görə jurnalını kəsir. Sonra o, yeni liderə gətirmə sorğuları göndərməyə başlayacaq. Orijinal liderdən yeni liderə təkrarlanmayan bütün qeydlər itirilir. Yəni, iki liderin işlədiyi bir neçə saniyə ərzində ilkin lider tərəfindən qəbul edilməyən mesajlar itəcək.
düyü. 29. Ssenari 4. Şəbəkə bərpa edildikdən sonra 1-ci brokerdəki lider izləyiciyə çevrilir.
Ssenari 5: İzləyici həm digər Kafka qovşaqlarından, həm də Zookeeper-dən tamamilə ayrıdır
İzləyici həm digər Kafka qovşaqlarından, həm də Zookeeper-dən tamamilə təcrid olunub. Şəbəkə bərpa olunana qədər o, sadəcə olaraq özünü ISR-dən uzaqlaşdırır və sonra digərləri ilə ayaqlaşır.
düyü. 30. Ssenari 5: Təcrid olunmuş izləyici ISR-dən çıxarılır
Ssenari 6: Lider həm digər Kafka qovşaqlarından, həm də Zookeeperdən tamamilə ayrıdır
düyü. 31. Ssenari 6. Lider və iki ardıcıl
Lider öz ardıcıllarından, nəzarətçidən və Zookeperdən tamamilə təcrid olunub. Qısa müddət ərzində o, müraciətləri qəbul etməyə davam edəcək acks=1.
düyü. 32. Ssenari 6: Liderin digər Kafka və Zookeeper qovşaqlarından təcrid edilməsi
Müddəti bitdikdən sonra müraciətlərin qəbul edilməməsi replica.lag.time.max.ms, o, ISR-ni özünə daraltmağa çalışacaq, lakin Zookeeper ilə əlaqə olmadığı üçün bunu edə bilməyəcək, sonra yazıları qəbul etməyi dayandıracaq.
Bu vaxt Zookeeper təcrid olunmuş brokeri ölü kimi qeyd edəcək və nəzarətçi yeni lider seçəcək.
düyü. 33. Ssenari 6. İki lider
Orijinal lider bir neçə saniyə ərzində girişləri qəbul edə bilər, lakin sonra hər hansı mesajı qəbul etməyi dayandırır. Müştərilər hər 60 saniyədən bir ən son metadata ilə yenilənir. Onlara lider dəyişikliyi barədə məlumat veriləcək və yeni liderə yazılar göndərməyə başlayacaqlar.
düyü. 34. Ssenari 6: İstehsalçılar yeni liderə keçirlər
Bağlantının itirilməsindən sonra ilkin lider tərəfindən edilən bütün təsdiqlənmiş qeydlər itəcək. Şəbəkə bərpa edildikdən sonra ilkin lider Zookeeper vasitəsilə onun artıq lider olmadığını aşkar edəcək. Sonra o, seçki zamanı yeni liderin HW-yə jurnalını kəsəcək və izləyici kimi sorğular göndərməyə başlayacaq.
düyü. 35. Ssenari 6: Şəbəkə bağlantısı bərpa edildikdən sonra ilkin lider izləyiciyə çevrilir
Bu vəziyyətdə, məntiqi ayrılma qısa müddətə baş verə bilər, ancaq yalnız acks=1 и min.insync.replikalar həmçinin 1. Məntiqi ayırma ya şəbəkə bərpa edildikdən sonra, ilkin lider artıq lider olmadığını başa düşdükdə və ya bütün müştərilər liderin dəyişdiyini başa düşdükdə və yeni liderə yazmağa başlayanda - hansı birinci olarsa, avtomatik olaraq bitir. Hər halda, bəzi mesajlar itiriləcək, lakin yalnız ilə acks=1.
Bu ssenarinin başqa bir variantı da var ki, şəbəkə parçalanmazdan əvvəl izləyicilər geridə qaldı və lider ISR-ni yalnız özünə sıxdı. Daha sonra əlaqənin itirilməsi səbəbindən təcrid olunur. Yeni lider seçilir, lakin ilkin lider hətta girişləri qəbul etməyə davam edir acks=hamısı, çünki ISR-də ondan başqa heç kim yoxdur. Şəbəkə bərpa edildikdən sonra bu qeydlər itiriləcək. Bu seçimdən qaçmağın yeganə yolu min.insync.replikalar = 2.
Ssenari 7: Kafka Nəzarətçi Düyünü Başqa Kafka Düyününü Görə bilmir
Ümumiyyətlə, Kafka node ilə əlaqə kəsildikdən sonra nəzarətçi ona hər hansı lider dəyişikliyi məlumatını ötürə bilməyəcək. Ən pis halda, bu, ssenari 6-da olduğu kimi qısamüddətli məntiqi ayrılığa gətirib çıxaracaq. Çox vaxt, sonuncu uğursuz olarsa, broker sadəcə olaraq liderliyə namizəd olmayacaq.
Ssenari 8: Kafka nəzarətçisi Zookeeper-i görmür
Zookeeper düşmüş nəzarətçidən ping almayacaq və nəzarətçi kimi yeni Kafka qovşağını seçəcək. Orijinal nəzarətçi özünü belə təqdim etməyə davam edə bilər, lakin Zookeeper-dən bildirişlər almır, ona görə də yerinə yetirmək üçün heç bir vəzifəsi olmayacaq. Şəbəkə bərpa edildikdən sonra o, artıq nəzarətçi olmadığını, adi Kafka düyününə çevrildiyini anlayacaq.
Ssenarilərdən nəticələr
Biz görürük ki, izləyici bağlantısının itirilməsi mesaj itkisi ilə nəticələnmir, sadəcə olaraq şəbəkə bərpa olunana qədər ehtiyatı müvəqqəti olaraq azaldır. Bu, əlbəttə ki, bir və ya bir neçə qovşaq itirildikdə məlumat itkisinə səbəb ola bilər.
Lider əlaqə itkisi səbəbindən Zookeeperdən ayrılarsa, bu, mesajların itirilməsi ilə nəticələnə bilər. acks=1. Zookeeper ilə ünsiyyətin olmaması iki liderlə qısa məntiqi parçalanmaya səbəb olur. Bu problem parametrlə həll olunur acks=hamısı.
Parametr min.insync.replikalar iki və ya daha çox replikaya çevrilməsi bu cür qısamüddətli ssenarilərin Ssenari 6-da olduğu kimi itirilmiş mesajlarla nəticələnməyəcəyinə əlavə zəmanət verir.
İtirilmiş Mesajların xülasəsi
Gəlin Kafkada məlumatları itirə biləcəyiniz bütün yolları sadalayaq:
- Mesajlar istifadə edərək təsdiqlənərsə, hər hansı bir lider uğursuzluğu acks=1
- Rəhbərliyin hər hansı bir natəmiz keçidi, yəni ISR-dən kənar bir ardıcıla, hətta ilə acks=hamısı
- Mesajlar istifadə edərək təsdiqlənərsə, lideri Zookeeperdən təcrid etmək acks=1
- Artıq ISR qrupunu özünə endirmiş liderin tam təcrid edilməsi. Hətta bütün mesajlar silinəcək acks=hamısı. Bu yalnız əgər doğrudur min.insync.replicas=1.
- Bütün bölmə qovşaqlarının eyni vaxtda uğursuzluğu. Mesajlar yaddaşdan qəbul edildiyi üçün bəziləri hələ diskə yazılmaya bilər. Serverləri yenidən işə saldıqdan sonra bəzi mesajlar çatışmaya bilər.
Natəmiz liderlik keçidlərinin qarşısını ya onları qadağan etməklə, ya da ən azı iki ixtisarı təmin etməklə almaq olar. Ən davamlı konfiqurasiya birləşmədir acks=hamısı и min.insync.replikalar daha çox 1.
RabbitMQ və Kafkanın etibarlılığının birbaşa müqayisəsi
Etibarlılığı və yüksək əlçatanlığı təmin etmək üçün hər iki platforma əsas və ikincili təkrarlama sistemi tətbiq edir. Bununla belə, RabbitMQ-nin Axilles dabanı var. Uğursuzluqdan sonra yenidən qoşulduqda, qovşaqlar məlumatlarını atırlar və sinxronizasiya bloklanır. Bu ikiqat şıltaqlıq RabbitMQ-da böyük növbələrin uzunömürlülüyünü şübhə altına alır. Ya azaldılmış ehtiyat və ya uzun bloklama vaxtlarını qəbul etməli olacaqsınız. Artıqlığın azaldılması kütləvi məlumat itkisi riskini artırır. Ancaq növbələr kiçikdirsə, ehtiyatsızlıq üçün təkrar qoşulma cəhdləri ilə qısa müddət ərzində əlçatmazlıq (bir neçə saniyə) aradan qaldırıla bilər.
Kafkanın bu problemi yoxdur. O, məlumatları yalnız lider və izləyici arasındakı fərq nöqtəsindən kənarlaşdırır. Bütün paylaşılan məlumatlar saxlanılır. Bundan əlavə, replikasiya sistemi bloklamır. Yeni izləyici yetişən zaman lider postları qəbul etməyə davam edir, ona görə də devoplar üçün klasterə qoşulmaq və ya yenidən qoşulmaq mənasız bir işə çevrilir. Təbii ki, replikasiya zamanı şəbəkə bant genişliyi kimi problemlər hələ də mövcuddur. Eyni anda birdən çox izləyici əlavə etsəniz, bant genişliyi məhdudiyyəti ilə qarşılaşa bilərsiniz.
RabbitMQ, klasterdəki birdən çox server eyni anda uğursuz olduqda etibarlılıq baxımından Kafkadan üstündür. Artıq dediyimiz kimi, RabbitMQ yalnız master və bütün güzgülər tərəfindən mesaj diskə yazıldıqdan sonra nəşriyyata təsdiq göndərir. Lakin bu, iki səbəbə görə əlavə gecikmə əlavə edir:
- fsync hər bir neçə yüz millisaniyədən bir
- Güzgünün nasazlığı yalnız hər bir node (şəbəkə işarəsi) mövcudluğunu yoxlayan paketlərin istifadə müddəti bitdikdən sonra müşahidə edilə bilər. Güzgü yavaşlayırsa və ya düşürsə, bu, gecikmə əlavə edir.
Kafkanın iddiası budur ki, əgər mesaj bir neçə qovşaqda saxlanılırsa, o, mesajları yaddaşa düşən kimi qəbul edə bilər. Buna görə də istənilən növ mesajların (hətta acks=hamısı, min.insync.replicas=2) eyni vaxtda nasazlıq olduqda.
Ümumilikdə, Kafka daha yaxşı proqram performansı nümayiş etdirir və klasterlər üçün sıfırdan hazırlanıb. Etibarlılıq üçün lazım gələrsə, izləyicilərin sayı 11-ə qədər artırıla bilər. Replikasiya faktoru 5 və sinxronizasiyada replikaların minimum sayı min.insync.replicas=3 mesaj itkisini çox nadir bir hadisəyə çevirəcək. Əgər infrastrukturunuz bu təkrarlama nisbətini və ehtiyat səviyyəsini dəstəkləyə bilirsə, onda siz bu seçimi seçə bilərsiniz.
RabbitMQ qruplaşması kiçik növbələr üçün yaxşıdır. Ancaq sıx trafik olduqda kiçik növbələr belə sürətlə böyüyə bilər. Növbələr böyüdükdən sonra əlçatanlıq və etibarlılıq arasında çətin seçim etməli olacaqsınız. RabbitMQ klasterləşməsi, RabbitMQ-nun çevikliyinin faydalarının onun qruplaşmasının hər hansı mənfi cəhətlərini üstələdiyi qeyri-adi vəziyyətlər üçün ən uyğundur.
RabbitMQ-nun böyük növbələrə qarşı həssaslığının bir panzehiri onları bir çox kiçik növbələrə bölməkdir. Bütün növbənin tam sifarişini tələb etmirsinizsə, ancaq müvafiq mesajlar (məsələn, müəyyən bir müştəridən gələn mesajlar) və ya ümumiyyətlə heç bir şey sifariş etmirsinizsə, bu seçim məqbuldur: layihəmə baxın növbəni bölmək (layihə hələ ilkin mərhələdədir).
Nəhayət, həm RabbitMQ, həm də Kafkanın klasterləşmə və replikasiya mexanizmlərindəki bir sıra səhvləri unutma. Zaman keçdikcə sistemlər daha yetkin və sabit hala gəldi, lakin heç bir mesaj itkidən 100% təhlükəsiz olmayacaq! Bundan əlavə, məlumat mərkəzlərində böyük miqyaslı qəzalar baş verir!
Nəyisə qaçırmışamsa, səhv etmişəmsə və ya hər hansı bir məqamla razı deyilsinizsə, şərh yazmaqdan və ya mənimlə əlaqə saxlamaqdan çekinmeyin.
Məndən tez-tez soruşurlar: “Nə seçmək lazımdır, Kafka və ya RabbitMQ?”, “Hansı platforma daha yaxşıdır?”. Həqiqət budur ki, bu, həqiqətən sizin vəziyyətinizdən, cari təcrübənizdən və s. asılıdır. Mən öz fikrimi bildirməyə tərəddüd edirəm, çünki bütün istifadə halları və mümkün məhdudiyyətlər üçün bir platforma tövsiyə etmək həddən artıq sadələşdirmə olardı. Bu silsilə yazıları ona görə yazdım ki, öz fikrinizi formalaşdırasınız.
Demək istəyirəm ki, hər iki sistem bu sahədə liderdir. Mən bir az qərəzli ola bilərəm, çünki layihələrlə bağlı təcrübəmə əsasən zəmanətli mesaj sifarişi və etibarlılıq kimi şeyləri qiymətləndirirəm.
Bu etibarlılığı və zəmanətli sifarişi olmayan digər texnologiyalar görürəm, sonra RabbitMQ və Kafkaya baxıram və bu sistemin hər ikisinin inanılmaz dəyərini dərk edirəm.
Mənbə: www.habr.com