В tulisan panungtung urang nempo RabbitMQ clustering pikeun kasabaran sesar sarta kasadiaan tinggi. Ayeuna hayu urang ngagali jero kana Apache Kafka.

Di dieu unit réplikasi nyaéta partisi. Unggal topik boga hiji atawa leuwih bagian. Tiap bagian boga pamingpin kalawan atawa tanpa pengikut. Nalika nyieun topik, anjeun nangtukeun jumlah partisi sareng koefisien réplikasi. Nilai biasa nyaéta 3, anu hartosna tilu réplika: hiji pamimpin sareng dua pengikut.

Sangu. 1. Opat bagian disebarkeun diantara tilu calo

Kabéh requests maca jeung nulis indit ka pamingpin. Pengikut périodik ngirim pamenta ka pamimpin pikeun nampi pesen panganyarna. Konsumén henteu kantos kéngingkeun pengikut; anu terakhir aya ngan ukur pikeun redundansi sareng kasabaran kasalahan.

Gagalna partisi

Nalika calo gagal, pamimpin sababaraha bagian sering gagal. Dina masing-masingna, pengikut ti titik anu sanés janten pamimpin. Kanyataanna, ieu teu salawasna jadi, sabab faktor sinkronisasi ogé mangaruhan: naha aya pengikut nyingkronkeun, sarta lamun henteu, teras naha ngaganti ka replika unsynchronized diwenangkeun. Tapi hayu urang teu ngahesekeun hal pikeun ayeuna.

Calo 3 ninggalkeun jaringan, sareng pamimpin anyar kapilih pikeun bagian 2 di calo 2.

Sangu. 2. Calo 3 maot sareng pengikut na dina calo 2 kapilih janten pamimpin anyar partisi 2

Teras calo 1 daun sareng bagian 1 ogé kaleungitan pamimpinna, anu peranna janten calo 2.

Sangu. 3. Aya hiji calo ditinggalkeun. Sadaya pamimpin aya dina hiji calo sareng nol redundancy

Nalika calo 1 datang deui online, éta nambihan opat pengikut, nyayogikeun sababaraha redundansi ka unggal partisi. Tapi sadayana pamimpin tetep tetep dina calo 2.

Sangu. 4. Pamingpin tetep dina calo 2

Nalika calo 3 asalna nepi, urang balik ka tilu réplika per partisi. Tapi sadayana pamimpin masih aya dina calo 2.

Sangu. 5. Teu saimbang panempatan pamingpin sanggeus restorasi calo 1 jeung 3

Kafka gaduh alat pikeun ngimbangan deui pamimpin anu langkung saé tibatan RabbitMQ. Di dinya, anjeun kedah nganggo plugin atanapi skrip pihak katilu anu ngarobih kawijakan pikeun migrasi master node ku cara ngirangan redundansi nalika migrasi. Sajaba ti éta, pikeun antrian badag urang kedah nampi unavailability salila sinkronisasi.

Kafka gaduh konsép "réplika anu dipikaresep" pikeun peran pamimpin. Nalika partisi topik didamel, Kafka nyobian ngadistribusikaeun pamimpin sacara merata dina titik-titik sareng nyirian pamimpin anu munggaran salaku anu dipikaresep. Kana waktu, alatan reboots server, gagal, sarta breakdowns konektipitas, pamingpin bisa mungkas nepi ka titik lianna, sakumaha dina kasus ekstrim ditétélakeun di luhur.

Pikeun ngalereskeun ieu, Kafka nawiskeun dua pilihan:

Pilihan auto.leader.rebalance.enable=true ngamungkinkeun titik controller pikeun otomatis reassign pamingpin deui réplika pikaresep jeung kukituna balikkeun sebaran seragam.
Administrator tiasa ngajalankeun naskah kafka-preferred-replica-election.sh pikeun reassignment manual.

Sangu. 6. Réplika sanggeus rebalancing

Ieu mangrupikeun versi saderhana tina kagagalan, tapi kanyataanana langkung rumit, sanaos teu aya anu rumit teuing di dieu. Éta sadayana turun ka réplika anu disingkronkeun (Replika In-Sync, ISR).

Réplika anu disingkronkeun (ISR)

ISR nyaéta sakumpulan réplika partisi anu dianggap "sinkronisasi" (in-sync). Aya pamingpin, tapi moal aya pengikut. Pengikut dianggap nyingkronkeun lamun geus nyieun salinan pasti sadaya pesen pamimpin saméméh interval kadaluwarsa. replica.lag.time.max.ms.

Pengikut dipiceun tina set ISR upami:

teu nyieun pamundut pikeun milih interval replica.lag.time.max.ms (disangka maot)
teu junun ngamutahirkeun salila interval replica.lag.time.max.ms (dianggap lambat)

Pengikut nyieun requests sampling dina interval replica.fetch.wait.max.ms, anu standarna ka 500ms.

Pikeun jelas ngajelaskeun tujuan ISR, urang kedah ningali konfirmasi ti produsén sareng sababaraha skenario gagal. Produser tiasa milih nalika calo ngirim konfirmasi:

acks = 0, konfirmasi teu dikirim
acks = 1, konfirmasi dikirim sanggeus pamimpin geus ditulis pesen ka log lokal na
acks = sadayana, konfirmasi dikirim saatos sadaya réplika dina ISR parantos nyerat pesen ka log lokal

Dina terminologi Kafka, upami ISR parantos nyimpen pesen, éta "komitmen". Acks = sadayana mangrupikeun pilihan anu paling aman, tapi ogé nambihan reureuh tambahan. Hayu urang tingali dua conto kagagalan sareng kumaha pilihan 'acks' anu béda berinteraksi sareng konsép ISR.

Acks = 1 jeung ISR

Dina conto ieu, urang bakal nempo yén lamun pamimpin teu ngadagoan unggal pesen ti sakabeh pengikut disimpen, lajeng leungitna data mungkin lamun pamimpin gagal. Napigasi ka pengikut anu teu disinkronkeun tiasa diaktipkeun atanapi ditumpurkeun ku netepkeun najis.pamimpin.pemilihan.ngaktifkeun.

Dina conto ieu, produsén boga nilai acks = 1. Bagian ieu disebarkeun ka sadaya tilu calo. Calo 3 aya di tukangeun, éta nyingkronkeun sareng pamimpin dalapan detik ka pengker sareng ayeuna 7456 pesen di tukangeun. calo 1 éta ngan hiji detik balik. Produser kami ngirim pesen sareng gancang nampi ack deui, tanpa overhead pengikut anu laun atanapi maot anu henteu ngantosan pamimpin.

Sangu. 7. ISR kalawan tilu réplika

calo 2 gagal sarta produser narima kasalahan sambungan. Saatos kapamimpinan lolos ka calo 1, urang leungit 123 pesen. The follower on calo 1 éta bagian tina ISR, tapi teu pinuh nyingkronkeun jeung pamimpin nalika murag.

Sangu. 8. Pesen leungit nalika ngadat

Dina konfigurasi bootstrap.servers Produsén ngagaduhan sababaraha calo anu didaptarkeun sareng tiasa naroskeun ka calo sanés anu mangrupikeun pamimpin bagian énggal. Ieu lajeng ngadegkeun sambungan ka calo 1 sarta terus ngirim pesen.

Sangu. 9. Ngirim pesen dihanca sanggeus putus pondok

calo 3 malah leuwih jauh. Éta ngajantenkeun pamenta dipulut tapi teu tiasa nyingkronkeun. Ieu bisa jadi alatan sambungan jaringan slow antara calo, masalah gudang, jsb Ieu dikaluarkeun tina ISR. Ayeuna ISR diwangun ku hiji réplika - pamimpin! Pabrikan terus ngirim pesen sareng nampi konfirmasi.

Sangu. 10. Follower on calo 3 dikaluarkeun tina ISR

Calo 1 turun sareng kalungguhan kapamimpinan ka calo 3 kalayan kaleungitan 15286 pesen! Pabrikan nampi pesen kasalahan sambungan. Transisi ka pamimpin di luar ISR ngan mungkin alatan setting najis.pamimpin.pamilihan.enable=leres. Lamun dipasang dina palsu, mangka transisi moal lumangsung sarta sakabeh requests maca jeung nulis bakal ditolak. Dina hal ieu, urang ngadagoan calo 1 balik kalawan data gembleng na di replica, nu deui bakal nyokot alih kapamimpinan.

Sangu. 11. calo 1 ragrag. Nalika gagalna lumangsung, sajumlah ageung seratan leungit

Produser ngadegkeun sambungan jeung calo panungtungan sarta nilik yén anjeunna ayeuna pamingpin bagian. Anjeunna mimiti ngirim pesen ka calo 3.

Sangu. 12. Saatos istirahat sakedap, pesen dikirim deui ka bagian 0

Urang nempo yén, sajaba ti interruptions pondok pikeun ngadegkeun sambungan anyar jeung neangan pamimpin anyar, produsén ieu terus ngirim pesen. Konfigurasi ieu ensures kasadiaan dina expense konsistensi (kaamanan data). Kafka kaleungitan rébuan pesen tapi teras nampi tulisan énggal.

Acks = sadayana sareng ISR

Hayu urang ngulang skenario ieu deui, tapi kalawan acks = sadayana. calo 3 boga latency rata-rata opat detik. Produsén ngirim pesen sareng acks = sadayana, sareng ayeuna henteu nampi réspon anu gancang. Pamimpin ngantosan pesen disimpen ku sadaya réplika dina ISR.

Sangu. 13. ISR kalawan tilu réplika. Salah sahijina lambat, nyababkeun telat ngarékam

Saatos opat detik reureuh tambahan, calo 2 ngirimkeun hiji ack. Sadaya réplika ayeuna parantos diropéa.

Sangu. 14. Sadaya réplika nyimpen pesen sareng ngirim ack

calo 3 ayeuna ragrag salajengna balik sarta dikaluarkeun tina ISR. Latency diréduksi sacara signifikan kusabab teu aya réplika anu laun dina ISR. Calo 2 ayeuna ngan ukur ngantosan calo 1, sareng anjeunna gaduh lag rata-rata 500 mdet.

Sangu. 15. The replica on calo 3 dikaluarkeun tina ISR

Lajeng calo 2 ragrag na kapamimpinan lolos ka calo 1 tanpa leungitna pesen.

Sangu. 16. calo 2 ragrag

Pabrikan mendakan pamimpin énggal sareng mimiti ngirim pesen ka anjeunna. Latensina dikirangan deui kusabab ISR ayeuna diwangun ku hiji réplika! Ku kituna pilihan acks = sadayana teu nambahan redundansi.

Sangu. 17. Replica on calo 1 nyokot kalungguhan tanpa kaleungitan pesen

Lajeng calo 1 nabrak sareng kalungguhan nuju ka calo 3 kalayan kaleungitan 14238 pesen!

Sangu. 18. calo 1 maot sarta transisi kapamimpinan kalawan setting najis ngakibatkeun leungitna data éksténsif

Urang teu bisa install pilihan najis.pamimpin.pemilihan.ngaktifkeun kana harti bener. Sacara standar éta sarua jeung palsu. Setélan acks = sadayana с najis.pamimpin.pamilihan.enable=leres nyadiakeun aksés kalawan sababaraha kaamanan data ditambahkeun. Tapi sakumaha anjeun tiasa ningali, urang masih tiasa leungit pesen.

Tapi kumaha upami urang hoyong ningkatkeun kaamanan data? Anjeun tiasa nempatkeun najis.pamimpin.pamilihan.ngaktifkeun = palsu, tapi ieu teu merta ngajaga urang tina leungitna data. Upami pamimpin murag sareng nyandak datana, teras pesen masih leungit, ditambah kasadiaan leungit dugi ka pangurus mulangkeun kaayaan.

Éta langkung saé pikeun mastikeun yén sadaya pesen kaleuleuwihan, sareng upami henteu miceun rékamanna. Lajeng, sahenteuna tina sudut pandang calo urang, leungitna data ngan mungkin dina acara dua atawa leuwih gagal sakaligus.

Acks=all, min.insync.replicas jeung ISR

Kalayan konfigurasi topik min.insync.replicas Kami ningkatkeun tingkat kaamanan data. Hayu urang balik ngaliwatan bagian panungtungan tina skenario saméméhna deui, tapi waktos ieu kalawan min.insync.replicas=2.

Janten calo 2 gaduh pamimpin réplika sareng pengikut dina calo 3 dikaluarkeun tina ISR.

Sangu. 19. ISR ti dua réplika

calo 2 ragrag na kapamimpinan lolos ka calo 1 tanpa leungitna pesen. Tapi ayeuna ISR diwangun ku ngan hiji réplika. Ieu teu minuhan jumlah minimum pikeun nampa rékaman, sarta ku kituna calo nu responds kana usaha nulis kalawan kasalahan TeuCukupReplika.

Sangu. 20. Jumlah ISR hiji leuwih handap dieusian dina min.insync.replicas

Konfigurasi ieu kurban kasadiaan pikeun konsistensi. Sateuacan ngaku pesen, kami mastikeun yén éta ditulis ka sahenteuna dua réplika. Ieu masihan produsén langkung kapercayaan. Di dieu, leungitna pesen ngan mungkin lamun dua réplika gagal sakaligus dina interval pondok dugi pesen ieu replicated ka pengikut tambahan, nu teu mungkin. Tapi lamun anjeun super paranoid, Anjeun tiasa nyetel faktor réplikasi ka 5, jeung min.insync.replicas ku 3. Di dieu tilu calo kudu ragrag dina waktos anu sareng leungit catetan! Tangtosna, anjeun mayar réliabilitas ieu dina latency tambahan.

Nalika aksésibilitas diperlukeun pikeun kaamanan data

saperti dina kasus kalawan RabbitMQ, kadang aksésibilitas diperlukeun pikeun kaamanan data. Ieu naon anu anjeun kedah pikirkeun:

Tiasa penerbit ngan saukur mulangkeun kasalahan sareng gaduh jasa hulu atanapi pangguna cobian deui engké?
Naha penerbit tiasa nyimpen pesen sacara lokal atanapi dina pangkalan data pikeun cobian deui engké?

Upami jawabanna henteu, teras ngaoptimalkeun kasadiaan ningkatkeun kaamanan data. Anjeun bakal leungit data kirang upami anjeun milih kasadiaan tinimbang henteu ngarékam. Ku kituna, eta sadayana turun ka manggihan kasaimbangan, sarta kaputusan gumantung kana situasi husus.

Harti ISR

ISR suite ngidinan Anjeun pikeun milih kasaimbangan optimal antara kaamanan data jeung latency. Contona, mastikeun kasadiaan dina acara gagalna mayoritas réplika, ngaminimalkeun dampak maot atanapi slow réplika dina watesan latency.

Urang milih sorangan hartina replica.lag.time.max.ms nurutkeun pangabutuh anjeun. Intina, parameter ieu hartina sabaraha reureuh kami daék nampa nalika acks = sadayana. Nilai standar nyaéta sapuluh detik. Upami ieu panjang teuing pikeun anjeun, anjeun tiasa ngiranganana. Teras frékuénsi parobihan dina ISR bakal ningkat, sabab pengikut bakal dipiceun sareng sering ditambah.

RabbitMQ ngan saukur sakumpulan kaca spion anu kedah ditiru. Eunteung slow ngenalkeun latency tambahan, sarta kaca spion maot bisa antosan nepi ka pakét nu mariksa kasadiaan unggal titik (net centang) ngabales. ISR mangrupikeun cara anu pikaresepeun pikeun ngahindarkeun masalah latency ieu. Tapi urang résiko kaleungitan redundansi saprak ISR ngan ukur tiasa nyusut ka pamimpin. Pikeun ngahindarkeun résiko ieu, paké setélan min.insync.replicas.

jaminan sambungan klien

Dina setélan bootstrap.servers produser sarta konsumen bisa nangtukeun sababaraha calo pikeun nyambungkeun klien. Gagasanna nyaéta nalika hiji titik turun, aya sababaraha cadangan anu tinggaleun dimana klien tiasa muka sambungan. Ieu teu merta pamingpin bagian, tapi ngan hiji springboard pikeun loading awal. Klién tiasa naroskeun aranjeunna mana titik anu janten pamimpin partisi baca / tulis.

Dina RabbitMQ, klien tiasa nyambung ka titik mana waé, sareng rute internal ngirimkeun pamundut ka tempat anu kedah dituju. Ieu ngandung harti yén anjeun tiasa masang pangimbang beban di payuneun RabbitMQ. Kafka meryogikeun klien pikeun nyambung ka titik anu janten tempat pamimpin partisi anu cocog. Dina kaayaan kitu, anjeun moal bisa masang load balancer. Daptar bootstrap.servers Penting pisan yén klien tiasa ngaksés sareng mendakan titik anu leres saatos gagal.

Arsitéktur Konsensus Kafka

Dugi ka ayeuna, kami henteu acan nganggap kumaha klaster diajar ngeunaan ragrag calo sareng kumaha pamimpin anyar kapilih. Pikeun ngartos kumaha Kafka dianggo sareng partisi jaringan, anjeun kedah ngartos arsitektur konsensus.

Unggal klaster Kafka disebarkeun babarengan sareng kluster Zookeeper, nyaéta layanan konsensus anu disebarkeun anu ngamungkinkeun sistem ngahontal konsensus dina sababaraha kaayaan anu dipasihkeun, prioritas konsistensi tibatan kasadiaan. Idin ti mayoritas titik Zookeeper diperlukeun pikeun approve operasi maca jeung nulis.

Zookeeper nyimpen kaayaan klaster:

Daptar jejer, bagian, konfigurasi, réplika pamimpin ayeuna, réplika pikaresep.
anggota kluster. Unggal calo pings kluster Zookeeper. Upami éta henteu nampi ping dina waktos anu ditangtukeun, maka Zookeeper ngarékam calo éta henteu sayogi.
Milih titik utama jeung cadang pikeun controller.

Titik pengontrol mangrupikeun salah sahiji calo Kafka anu tanggung jawab pikeun milih pamimpin réplika. Zookeeper ngirimkeun bewara ka controller ngeunaan kaanggotaan klaster sarta parobahan topik, sarta controller kudu meta dina parobahan ieu.

Contona, hayu urang nyandak hiji topik anyar kalawan sapuluh partitions sarta faktor réplikasi 3. controller kudu milih pamingpin pikeun tiap partisi, nyoba optimal ngadistribusikaeun pamingpin diantara calo.

Pikeun unggal bagian controller:

update informasi dina Zookeeper ngeunaan ISR jeung pamimpin;
Ngirimkeun LeaderAndISRCommand ka unggal calo anu ngagaduhan replika partisi ieu, nginpokeun ka calo ngeunaan ISR sareng pamimpin.

Nalika calo sareng pamimpin ragrag, Zookeeper ngirimkeun bewara ka controller, sareng éta milih pamimpin énggal. Deui, controller mimiti ngamutahirkeun Zookeeper lajeng ngirimkeun paréntah ka unggal calo ngawartosan aranjeunna ngeunaan parobahan kapamimpinan.

Unggal pamimpin tanggung jawab pikeun ngarekrut ISR. Setélan replica.lag.time.max.ms nangtukeun saha nu bakal asup ka dinya. Nalika parobahan ISR, pamimpin ngirimkeun inpormasi anyar ka Zookeeper.

Zookeeper sok diinformasikeun ngeunaan parobahan naon waé supados upami aya kagagalan, manajemén transisi lancar ka pamimpin énggal.

Sangu. 21. Konsensus Kafka

Protokol réplikasi

Ngartos detil réplikasi ngabantosan anjeun langkung ngartos skénario leungitna data poténsial.

Sampling queries, Log End Offset (LEO) jeung Highwater Mark (HW)

Urang nganggap yén pengikut périodik ngirim requests dipulut ka pamimpin. Interval standar nyaéta 500ms. Ieu béda ti RabbitMQ yén dina réplikasi RabbitMQ henteu diprakarsai ku eunteung antrian tapi ku master. Master ngadorong parobahan kana kaca spion.

Pamimpin sareng sadaya pengikut nyimpen Log End Offset (LEO) sareng labél Highwater (HW). Tanda LEO nyimpen offset pesen panungtungan dina réplika lokal, sarta HW nahan offset tina komitmen panungtungan. Émut yén pikeun status komitmen, pesen kedah diteruskeun dina sadaya réplika ISR. Ieu ngandung harti yén LEO biasana rada dihareupeun HW.

Nalika pamimpin nampi pesen, éta disimpen sacara lokal. Follower ngadamel pamundut dipulut ku ngirimkeun LEO na. Pamimpin teras ngirimkeun sakumpulan pesen mimitian ti LEO ieu sareng ogé ngirimkeun HW ayeuna. Nalika pamimpin narima informasi yén sakabéh réplika geus disimpen pesen dina offset dibikeun, ngalir tanda HW. Ngan pamimpin tiasa mindahkeun HW, sareng ku kituna sadaya pengikut bakal terang nilai ayeuna dina réspon kana pamundutana. Ieu ngandung harti yén pengikut tiasa katinggaleun pamimpin dina pesen sareng pangaweruh HW. Konsumén nampi pesen ngan ukur dugi ka HW ayeuna.

Catet yén "persisted" hartosna ditulis kana mémori, sanés kana disk. Pikeun pagelaran, Kafka nyingkronkeun kana disk dina interval nu tangtu. RabbitMQ ogé gaduh interval sapertos kitu, tapi bakal ngirim pangakuan ka penerbit ngan saatos master sareng sadaya kaca spion parantos nyerat pesen ka disk. Pamekar Kafka, pikeun alesan kinerja, mutuskeun pikeun ngirim hiji ack pas pesen ditulis ka memori. Kafka bet yén redundansi ngimbangan résiko nyimpen sakeudeung talatah diaku dina mémori wungkul.

Gagalna pamingpin

Nalika pamimpin ragrag, Zookeeper ngabéjaan controller nu, sarta eta milih replica pamimpin anyar. Pamimpin anyar nyetél tanda HW anyar numutkeun LEO na. Pengikut teras nampi inpormasi ngeunaan pamimpin énggal. Gumantung kana versi Kafka, pengikut bakal milih salah sahiji tina dua skenario:

Bakal truncate log lokal ka HW dipikawanoh sarta ngirim pamundut ka pamimpin anyar pikeun pesen sanggeus tanda ieu.
Bakal ngirim pamundut ka pamimpin pikeun manggihan HW dina waktos anjeunna kapilih pamimpin, lajeng truncate log ka offset ieu. Teras bakal ngawitan ngadamel pamenta dipulut périodik mimitian ti offset ieu.

Pengikut panginten kedah motong log kusabab alesan ieu:

Nalika pamimpin gagal, pengikut munggaran dina set ISR anu didaptarkeun sareng Zookeeper meunang pamilihan sareng janten pamimpin. Sadaya pengikut dina ISR, sanaos dianggap "singkronkeun," panginten henteu nampi salinan sadaya pesen ti tilas pamimpin. Éta kamungkinan yén pengikut anu diulas henteu gaduh salinan anu paling énggal. Kafka mastikeun yén teu aya bédana antara réplika. Ku kituna, pikeun ngahindarkeun discrepancies, unggal pengikut kudu truncate log na kana nilai HW sahiji pamimpin anyar dina waktu pamilihan na. Ieu alesan sejen naha setelan acks = sadayana jadi penting pikeun konsistensi.
Pesen anu périodik ditulis kana disk. Upami sadaya titik klaster gagal dina waktos anu sami, maka réplika sareng offset anu béda bakal disimpen dina disk. Aya kamungkinan yén nalika calo datang deui online, pamimpin anyar anu kapilih bakal aya di tukangeun pengikutna kusabab anjeunna disimpen kana disk sateuacan anu sanés.

Reuni jeung kluster

Nalika ngahijikeun deui kluster, réplika sami sareng nalika pamimpin gagal: aranjeunna pariksa réplika pamimpin sareng motong log ka HW na (dina waktos pamilihan). Salaku babandingan, RabbitMQ sami-sami ngarawat titik anu ngahijikeun deui salaku énggal. Dina duanana kasus, calo nu discards sagala kaayaan aya. Upami panyingkronan otomatis dianggo, maka master kedah ngayakeun réplikasi leres-leres sadaya kontén anu ayeuna ka eunteung énggal dina metode "hayu saalam dunya ngantosan". Master henteu nampi operasi maca atanapi nyerat salami operasi ieu. Pendekatan ieu nyiptakeun masalah dina antrian ageung.

Kafka mangrupikeun log anu disebarkeun sareng sacara umum nyimpen langkung seueur pesen tibatan antrian RabbitMQ, dimana data dipiceun tina antrian saatos dibaca. Antrian aktip kedah tetep relatif leutik. Tapi Kafka mangrupikeun log kalayan kabijakan ingetan sorangan, anu tiasa nyetél waktos dinten atanapi minggu. The blocking antrian jeung pendekatan sinkronisasi pinuh kacida unacceptable pikeun log disebarkeun. Gantina, pengikut Kafka saukur truncate log maranéhanana ka HW pamingpin (dina waktu pamilihan na) lamun salinan maranéhanana dihareupeun pamingpin. Dina kasus anu langkung dipikaresep, nalika pangikutna aya di tukangeun, éta ngan saukur ngamimitian ngadamel pamenta dipulut dimimitian ku LEO anu ayeuna.

Pengikut anyar atanapi gabung deui dimimitian di luar ISR sareng henteu ilubiung dina komitmen. Aranjeunna ngan ukur damel sareng grup, nampi pesen gancang-gancang dugi ka aranjeunna nyekel pamimpin sareng asup ka ISR. Henteu aya konci-in sareng henteu kedah ngalungkeun sadaya data anjeun.

Leungitna konektipitas

Kafka ngagaduhan langkung komponén tibatan RabbitMQ, janten gaduh set paripolah anu langkung kompleks nalika klusterna dipegatkeun. Tapi Kafka mimitina dirancang pikeun klaster, ku kituna solusina dipikiran pisan.

Di handap ieu aya sababaraha skenario gagalna konektipitas:

Skenario 1: Follower teu ningali pamimpin, tapi tetep ningali Zookeeper.
Skenario 2: Pamimpin henteu ningali pengikut, tapi tetep ningali Zookeeper.
Skenario 3: pengikut ningali pamimpin, tapi henteu ningali Zookeeper.
Skenario 4: Pamimpin ningali pengikut, tapi henteu ningali Zookeeper.
Skenario 5: Follower sagemblengna misah ti kadua titik Kafka sejen tur Zookeeper.
Skenario 6: Pamingpin sagemblengna misah ti kadua titik Kafka sejen tur Zookeeper.
Skenario 7: Titik pangendali Kafka teu tiasa ningali titik Kafka anu sanés.
Skenario 8: Kafka controller teu ningali Zookeeper.

Unggal skenario boga kabiasaan sorangan.

Skenario 1: Follower henteu ningali pamimpin, tapi tetep ningali Zookeeper

Sangu. 22. skenario 1: ISR tilu réplika

Kagagalan konektipitas misahkeun calo 3 ti calo 1 jeung 2, tapi teu Zookeeper. calo 3 euweuh bisa ngirim requests dipulut. Sanggeus waktu geus kaliwat replica.lag.time.max.ms eta dikaluarkeun tina ISR jeung teu ilubiung dina commits pesen. Sakali konektipitas dibalikeun, éta bakal neruskeun pamundut dipulut sareng gabung ka ISR nalika néwak pamimpin. Zookeeper bakal terus nampa pings sarta nganggap yen calo nu hirup jeung ogé.

Sangu. 23. Skenario 1: calo nu dikaluarkeun tina ISR lamun euweuh pamundut dipulut ditampi ti dinya dina interval replica.lag.time.max.ms

Henteu aya pamisah-otak atanapi gantung titik sapertos dina RabbitMQ. Gantina, redundancy diréduksi.

Skenario 2: Pamimpin henteu ningali pengikut, tapi tetep ningali Zookeeper

Sangu. 24. Skenario 2. Pamingpin jeung dua pengikut

A ngarecahna konektipitas jaringan misahkeun pamingpin ti pengikut, tapi calo nu masih bisa ningali Zookeeper. Sapertos dina skenario anu munggaran, ISR nyusut, tapi waktos ieu ngan ukur ka pamimpin sabab sadaya pengikut ngeureunkeun ngirim pamenta dipulut. Sakali deui, teu aya pembagian logis. Gantina, aya leungitna redundansi pikeun pesen anyar dugi konektipitas disimpen deui. Zookeeper terus narima pings sarta yakin yén calo nu hirup jeung ogé.

Sangu. 25. Skenario 2. ISR geus shrunk ngan ka pamingpin

Skenario 3. Follower ningali pamimpin, tapi henteu ningali Zookeeper

Follower dipisahkeun ti Zookeeper, tapi teu ti calo jeung pamimpin. Hasilna, pengikut terus nyieun requests dipulut sarta jadi anggota ISR. Zookeeper henteu deui nampi ping sareng ngadaptar kacilakaan calo, tapi kusabab éta ngan ukur pengikut, henteu aya akibat saatos pulih.

Sangu. 26. Skenario 3: The follower terus ngirim requests fetch ka pamingpin

Skenario 4. Pamimpin ningali pengikut, tapi henteu ningali Zookeeper

Sangu. 27. Skenario 4. Pamingpin jeung dua pengikut

Pamingpin dipisahkeun ti Zookeeper, tapi henteu ti calo sareng pengikut.

Sangu. 28. skenario 4: Pamimpin terasing ti Zookeeper

Saatos sababaraha waktos, Zookeeper bakal ngadaptarkeun gagalna calo sareng ngabéjaan ka controller ngeunaan éta. Anjeunna bakal milih pamingpin anyar diantara pengikut-Na. Sanajan kitu, pamimpin aslina bakal neruskeun pikir yén éta téh pamimpin sarta bakal terus nampa éntri ti aks = 1. Pengikutna henteu deui ngintunkeun anjeunna nyuhunkeun pamundut, janten anjeunna bakal nganggap aranjeunna maot sareng nyobian ngaleutikan ISR ka dirina. Tapi saprak éta teu boga sambungan kana Zookeeper, eta moal bisa ngalakukeun ieu, sarta dina titik nu bakal nolak narima sagala éntri salajengna.

Seratan acks = sadayana moal nampi pangakuan sabab ISR mimiti ngahurungkeun sadayana réplika, sareng pesen henteu dugi ka aranjeunna. Nalika pamimpin aslina nyobian ngahapus aranjeunna tina ISR, éta moal tiasa ngalakukeunana sareng bakal ngeureunkeun nampi pesen naon waé.

Klién pas perhatikeun parobahan pamimpin sareng ngawitan ngirim rékaman ka server énggal. Sakali jaringan dibalikeun, pamimpin aslina ningali yén éta henteu deui pamimpin sareng motong log na kana nilai HW anu pamimpin énggal dina waktos gagal pikeun nyegah divergence log. Ieu lajeng bakal ngamimitian ngirim requests dipulut ka pamimpin anyar. Sadaya catetan ti pamimpin asli anu henteu ditiru ka pamimpin énggal leungit. Nyaéta, pesen anu henteu diakui ku pamimpin asli dina sababaraha detik nalika dua pamimpin nuju damel bakal leungit.

Sangu. 29. Skenario 4. Pamimpin calo 1 janten pengikut saatos jaringan dibalikeun

Skenario 5: Follower sagemblengna misah ti kadua titik Kafka sejen tur Zookeeper

Follower lengkep terasing tina titik Kafka sareng Zookeeper anu sanés. Anjeunna saukur ngaluarkeun dirina tina ISR nepi ka jaringan dibalikeun, lajeng nyekel up kalawan batur.

Sangu. 30. Skenario 5: pengikut terasing dipiceun tina ISR

Skenario 6: Pamingpin sagemblengna misah ti kadua titik Kafka sejen tur Zookeeper

Sangu. 31. Skenario 6. Pamingpin jeung dua pengikut

Pamingpin sagemblengna terasing ti pengikut-Na, controller jeung Zookeeper. Pikeun periode pondok eta bakal terus nampa éntri ti aks = 1.

Sangu. 32. Skenario 6: Ngasingkeun pamimpin ti titik Kafka sareng Zookeeper anu sanés

Sanggeus teu narima requests sanggeus béakna replica.lag.time.max.ms, eta bakal nyoba ngaleutikan ISR ka sorangan, tapi moal bisa ngalakukeunana sabab teu aya komunikasi jeung Zookeeper, mangka bakal eureun narima nulis.

Samentara éta, Zookeeper bakal nandaan calo terasing salaku maot sarta controller bakal milih pamingpin anyar.

Sangu. 33. Skenario 6. Dua pamingpin

Pamimpin asli tiasa nampi éntri sababaraha detik, tapi teras lirén nampi pesen naon waé. Klién diropéa unggal 60 detik kalayan metadata panganyarna. Aranjeunna bakal diwartosan ngeunaan parobihan pamimpin sareng bakal mimiti ngirim éntri ka pamimpin énggal.

Sangu. 34. skenario 6: Produsén pindah ka pamimpin anyar

Kabéh éntri dikonfirmasi dijieun ku pamimpin aslina saprak leungitna konektipitas bakal leungit. Sakali jaringan dibalikeun, pamimpin asli bakal mendakan ngaliwatan Zookeeper yén éta henteu deui pamimpin. Lajeng bakal truncate log na ka HW sahiji pamimpin anyar dina waktu pamilihan tur mimitian ngirim requests salaku follower a.

Sangu. 35. Skenario 6: Pamimpin asli janten pengikut saatos konektipitas jaringan dibalikeun

Dina kaayaan ieu, separation logis bisa lumangsung pikeun periode pondok, tapi ngan lamun aks = 1 и min.insync.replicas oge 1. separation logis otomatis ends boh sanggeus jaringan dibalikeun, lamun pamimpin aslina nyadar yén anjeunna geus euweuh pamimpin, atawa lamun kabeh klien nyadar yén pamimpin geus robah tur mimitian nulis ka pamimpin anyar - whichever kajadian munggaran. Dina sagala hal, sababaraha seratan bakal leungit, tapi ngan kalawan aks = 1.

Aya varian sejen tina skenario ieu dimana, ngan méméh pamisah jaringan, pengikut murag balik sarta pamimpin dikomprés ISR ka ngan dirina. Teras janten terasing kusabab kaleungitan konektipitas. A pamimpin anyar kapilih, tapi pamimpin aslina terus narima entri, komo acks = sadayana, sabab teu aya batur di ISR iwal anjeunna. Rékaman ieu bakal leungit nalika jaringan dibalikeun. Hiji-hijina jalan pikeun nyingkahan pilihan ieu min.insync.replicas = 2.

Skenario 7: Kafka Controller Node Teu Bisa Ningali Kafka Node Lain

Sacara umum, nalika sambungan sareng titik Kafka leungit, controller moal tiasa ngirimkeun inpormasi parobihan pamimpin ka éta. Dina kasus awon, ieu bakal ngakibatkeun separation logis jangka pondok, sakumaha dina skenario 6. Beuki sering ti moal, calo nu saukur moal jadi calon kapamimpinan lamun dimungkinkeun gagal.

Skenario 8: Kafka controller teu ningali Zookeeper

Zookeeper moal nampi ping ti controller fallen sarta bakal milih titik Kafka anyar salaku controller. Controller asli tiasa teras-terasan nampilkeun dirina sapertos kitu, tapi éta henteu nampi béwara ti Zookeeper, janten éta moal ngagaduhan tugas anu kedah dilakukeun. Sakali jaringan dibalikeun, anjeunna bakal sadar yén anjeunna henteu deui controller, tapi parantos janten titik Kafka biasa.

Kacindekan tina skenario

Kami ningali yén leungitna konektipitas pengikut henteu nyababkeun leungitna pesen, tapi ngan saukur ngirangan redundansi samentawis dugi ka jaringan disimpen deui. Ieu, tangtosna, tiasa nyababkeun leungitna data upami hiji atanapi langkung titik leungit.

Upami pamimpin papisah sareng Zookeeper kusabab kaleungitan konektipitas, ieu tiasa nyababkeun pesen leungit tina aks = 1. Kurangna komunikasi sareng Zookeeper ngabalukarkeun pamisah logis ringkes sareng dua pamimpin. Masalah ieu direngsekeun ku parameter acks = sadayana.

parameter min.insync.replicas kana dua atawa leuwih réplika nyadiakeun jaminan tambahan yén skenario jangka pondok sapertos moal ngakibatkeun pesen leungit sakumaha dina Skenario 6.

Ringkesan Pesen Leungit

Hayu urang daptar sadaya cara anjeun tiasa leungit data dina Kafka:

Sakur gagal pamimpin upami pesen dikonfirmasi nganggo aks = 1
Sagala transisi najis kapamimpinan, nyaeta, ka follower luar ISR, sanajan kalawan acks = sadayana
Ngasingkeun pamimpin ti Zookeeper upami pesen dikonfirmasi nganggo aks = 1
Ngasingkeun lengkep pamimpin anu parantos ngirangan kelompok ISR ka dirina. Kabéh pesen bakal leungit, sanajan acks = sadayana. Ieu ngan bener lamun min.insync.replicas=1.
Gagal sakaligus sadaya titik partisi. Kusabab seratan diakuan tina mémori, sababaraha tiasa henteu acan ditulis kana disk. Saatos rebooting server, sababaraha seratan bisa leungit.

Transisi kapamimpinan anu henteu murni tiasa dihindari ku cara ngalarang aranjeunna atanapi mastikeun sahenteuna dua redundancies. Konfigurasi anu paling awét nyaéta kombinasi acks = sadayana и min.insync.replicas leuwih ti 1.

Perbandingan langsung tina réliabilitas RabbitMQ sareng Kafka

Pikeun mastikeun reliabilitas sareng kasadiaan anu luhur, duanana platform nerapkeun sistem réplikasi primér sareng sekundér. Nanging, RabbitMQ ngagaduhan keuneung Achilles. Nalika nyambungkeun deui saatos gagal, titik miceun datana sareng sinkronisasi diblokir. Whammy ganda ieu nyauran kana patarosan umur panjang antrian ageung di RabbitMQ. Anjeun kedah nampi ngirangan redundansi atanapi waktos meungpeuk anu panjang. Ngurangan redundansi ngaronjatkeun résiko leungitna data masif. Tapi lamun antrian anu leutik, teras demi redundancy, perioda pondok tina unavailability (sababaraha detik) bisa diurus ngagunakeun usaha sambungan ulang.

Kafka henteu ngagaduhan masalah ieu. Ieu discards data ngan tina titik divergénsi antara pamimpin jeung pengikut. Sadaya data anu dibagikeun disimpen. Salaku tambahan, réplikasi henteu ngahalangan sistem. Pamingpin terus narima tulisan bari pengikut anyar nyekel up, jadi pikeun devops, gabung atawa rejoining kluster janten tugas trivial. Tangtosna, masih aya masalah sapertos bandwidth jaringan nalika réplikasi. Upami anjeun nambihan sababaraha pengikut dina waktos anu sami, anjeun tiasa mendakan wates bandwidth.

RabbitMQ langkung unggul tibatan Kafka dina reliabilitas nalika sababaraha server dina klaster gagal dina waktos anu sami. Sakumaha anu parantos kami nyarios, RabbitMQ ngirim konfirmasi ka penerbit ngan saatos pesenna ditulis kana disk ku master sareng sadaya kaca spion. Tapi ieu nambihan latency tambahan pikeun dua alesan:

fsync unggal sababaraha ratus milidetik
Gagalna kaca spion ngan ukur tiasa ditingali saatos umur pakét anu mariksa kasadiaan unggal titik (net centang) parantos kadaluwarsa. Lamun eunteung slows turun atawa ragrag, ieu nambahan reureuh.

Taruhan Kafka nyaéta upami pesen disimpen dina sababaraha titik, éta tiasa ngaku pesen pas aranjeunna pencét mémori. Kusabab ieu, aya résiko kaleungitan pesen naon waé (sanajan acks = sadayana, min.insync.replicas=2) bisi gagal sakaligus.

Gemblengna, Kafka nunjukkeun kinerja parangkat lunak anu langkung saé sareng dirarancang tina dasar pikeun klaster. Jumlah pengikut tiasa dironjatkeun ka 11 upami diperyogikeun pikeun reliabilitas. Faktor réplikasi 5 jeung jumlah minimum réplika dina sinkronisasi min.insync.replicas=3 bakal nyieun leungitna pesen kajadian langka pisan. Upami infrastruktur anjeun tiasa ngadukung rasio réplikasi ieu sareng tingkat redundansi, maka anjeun tiasa milih pilihan ieu.

RabbitMQ clustering téh alus pikeun antrian leutik. Tapi sanajan antrian leutik bisa tumuwuh gancang lamun aya lalulintas beurat. Sakali antrian janten ageung, anjeun kedah ngadamel pilihan tangguh antara kasadiaan sareng reliabilitas. Klaster RabbitMQ paling cocog pikeun kaayaan anu henteu khas dimana kauntungan tina kalenturan RabbitMQ langkung ageung tibatan kalemahan tina klasterna.

Salah sahiji antidote pikeun kerentanan RabbitMQ kana antrian ageung nyaéta ngarobih aranjeunna janten antrian anu langkung alit. Upami anjeun henteu meryogikeun pesenan lengkep sadaya antrian, tapi ngan ukur pesen anu relevan (contona, pesen ti klien khusus), atanapi henteu mesen nanaon, maka pilihan ieu tiasa ditampi: tingali proyék kuring. Rebalancer pikeun ngabagi antrian (proyék masih dina tahap awal).

Tungtungna, ulah hilap ngeunaan sababaraha bug dina mékanisme clustering sareng réplikasi duanana RabbitMQ sareng Kafka. Kana waktu, sistem geus jadi leuwih dewasa sarta stabil, tapi euweuh pesen bakal pernah jadi 100% aman tina leungitna! Salaku tambahan, kacilakaan skala ageung lumangsung di pusat data!

Upami kuring sono, ngalakukeun kasalahan, atanapi anjeun teu satuju sareng salah sahiji titik, punten nyerat koméntar atanapi ngahubungi kuring.

Kuring sering ditaros: "Naon anu kedah dipilih, Kafka atanapi RabbitMQ?", "Platform mana anu langkung saé?". Kabeneran aya nu bener gumantung kana kaayaan anjeun, pangalaman ayeuna, jsb Abdi hesitant masihan pendapat abdi sabab bakal jadi teuing hiji oversimplification nyarankeun hiji platform pikeun sakabéh kasus pamakéan sarta watesan mungkin. Kuring nyerat séri tulisan ieu supados anjeun tiasa ngabentuk pendapat anjeun nyalira.

Abdi hoyong nyarios yén duanana sistem mangrupikeun pamimpin di daérah ieu. Kuring bisa jadi rada bias sabab tina pangalaman kuring jeung proyék kuring condong ngahargaan hal kawas pesen pesen dijamin jeung reliabilitas.

Kuring ningali téknologi sanés anu henteu tiasa dipercaya sareng ngajamin pesenan, teras kuring ningali RabbitMQ sareng Kafka sareng sadar nilai anu luar biasa tina duanana sistem ieu.

sumber: www.habr.com

RabbitMQ vs Kafka: Kasabaran Kasalahan sareng Kasadiaan Luhur