В artikel pungkasan kita katon ing RabbitMQ clustering kanggo toleransi fault lan kasedhiyan dhuwur. Saiki ayo digali jero menyang Apache Kafka.

Ing kene unit replikasi yaiku partisi. Saben topik nduweni siji utawa luwih bagean. Saben bagean nduweni pimpinan kanthi pengikut utawa tanpa. Nalika nggawe topik, sampeyan nemtokake jumlah partisi lan koefisien replikasi. Nilai biasane 3, tegese telung replika: siji pimpinan lan loro pengikut.

Gabah. 1. Sekawan bagean disebarake ing antarane telung makelar

Kabeh panjalukan maca lan nulis menyang pimpinan. Para pengikut ngirim panjalukan kanthi periodik menyang pimpinan kanggo nampa pesen paling anyar. Konsumen ora tau pindhah menyang pengikut; sing terakhir mung ana kanggo redundansi lan toleransi kesalahan.

Gagal pemisahan

Nalika broker gagal, pimpinan sawetara bagean asring gagal. Ing saben wong, pengikut saka simpul liyane dadi pimpinan. Nyatane, iki ora mesthi kedadeyan, amarga faktor sinkronisasi uga duwe pengaruh: apa ana pengikut sing disinkronake, lan yen ora, mula diijini ngalih menyang replika sing ora disinkronake. Nanging aja nganti nggawe rumit.

Broker 3 ninggalake jaringan, lan pimpinan anyar dipilih kanggo bagean 2 ing broker 2.

Gabah. 2. Broker 3 mati lan pengikute ing broker 2 kapilih dadi pimpinan partisi 2 sing anyar

Banjur broker 1 ninggalake lan bagean 1 uga kelangan pimpinane, sing peran dadi broker 2.

Gabah. 3. Ana siji makelar sing isih ana. Kabeh pimpinan ana ing siji makelar kanthi nol redundansi

Nalika broker 1 bali online, nambah patang pengikut, nyedhiyakake sawetara redundansi kanggo saben partisi. Nanging kabeh pimpinan isih tetep ana ing broker 2.

Gabah. 4. Pemimpin tetep dadi broker 2

Nalika broker 3 muncul, kita bali menyang telung replika saben partisi. Nanging kabeh pimpinan isih ana ing broker 2.

Gabah. 5. Penempatan pimpinan sing ora seimbang sawise pemugaran broker 1 lan 3

Kafka duwe alat kanggo ngimbangi maneh pimpinan sing luwih apik tinimbang RabbitMQ. Ing kana, sampeyan kudu nggunakake plugin utawa skrip pihak katelu sing ngganti kabijakan kanggo migrasi simpul master kanthi nyuda redundansi sajrone migrasi. Kajaba iku, kanggo antrian gedhe, kita kudu nampa ora kasedhiya sajrone sinkronisasi.

Kafka duwe konsep "replika sing disenengi" kanggo peran pimpinan. Nalika partisi topik digawe, Kafka nyoba nyebarake pimpinan kanthi merata ing simpul lan menehi tandha pimpinan pisanan kasebut minangka pilihan. Sajrone wektu, amarga reboots server, gagal, lan gangguan konektivitas, pimpinan bisa uga ana ing simpul liyane, kaya ing kasus ekstrem sing kasebut ing ndhuwur.

Kanggo ndandani iki, Kafka nawakake rong pilihan:

Pilihan auto.leader.rebalance.enable=true ngidini simpul controller kanthi otomatis reassign pemimpin bali menyang replika preferred lan kanthi mangkono mulihake distribusi seragam.
Administrator bisa mbukak skrip kafka-preferred-replica-election.sh kanggo reassignment manual.

Gabah. 6. Replika sawise rebalancing

Iki minangka versi kegagalan sing disederhanakake, nanging kasunyatane luwih rumit, sanajan ora ana sing rumit banget ing kene. Iku kabeh mudhun kanggo replika sing disinkronake (In-Sync Replicas, ISR).

Replika Sinkronisasi (ISR)

ISR minangka sakumpulan replika partisi sing dianggep "sinkronisasi" (in-sync). Ana pimpinan, nanging bisa uga ora ana pengikut. Pengikut dianggep disinkronake yen wis nggawe salinan persis kabeh pesen pimpinan sadurunge interval kadaluwarsa replica.lag.time.max.ms.

Pengikut dibusak saka set ISR yen:

ora nggawe panjalukan kanggo milih interval replica.lag.time.max.ms (dianggep mati)
ora bisa nganyari sajrone interval replica.lag.time.max.ms (dianggap alon)

Pengikut nggawe panjalukan sampling ing interval replica.fetch.wait.max.ms, sing standar kanggo 500ms.

Kanggo nerangake kanthi jelas tujuan ISR, kita kudu ndeleng konfirmasi saka produser lan sawetara skenario kegagalan. Produser bisa milih nalika makelar ngirim konfirmasi:

acks = 0, konfirmasi ora dikirim
acks = 1, konfirmasi dikirim sawise pimpinan wis nulis pesen menyang log lokal
acks=all, konfirmasi dikirim sawise kabeh replika ing ISR wis nulis pesen menyang log lokal

Ing terminologi Kafka, yen ISR wis nyimpen pesen, iku "komit". Acks=all iku pilihan paling aman, nanging uga nambah wektu tundha tambahan. Ayo goleki rong conto kegagalan lan kepiye pilihan 'acks' beda karo konsep ISR.

Acks = 1 lan ISR

Ing conto iki, kita bakal weruh yen pimpinan ora ngenteni saben pesen saka kabeh pandherekipun disimpen, banjur mundhut data bisa yen pimpinan gagal. Navigasi menyang pengikut sing ora disinkronake bisa diaktifake utawa dipateni kanthi nyetel najis.pemimpin.pemilihan.aktif.

Ing conto iki, pabrikan nduweni nilai acks=1. Bagean kasebut disebarake ing kabeh telung makelar. Broker 3 ana ing mburi, disinkronake karo pimpinan wolung detik kepungkur lan saiki ana 7456 pesen. Broker 1 mung siji detik ing mburi. Produser kita ngirim pesen lan cepet nampa ack bali, tanpa overhead saka pandherekipun alon utawa mati sing pimpinan ora nunggu.

Gabah. 7. ISR karo telung replika

Broker 2 gagal lan produser nampa kesalahan sambungan. Sawise kepemimpinan liwat broker 1, kita ilang 123 pesen. Pengikut ing broker 1 minangka bagéan saka ISR, nanging ora disinkronake kanthi lengkap karo pimpinan nalika tiba.

Gabah. 8. Pesen ilang nalika tubrukan

Ing konfigurasi bootstrap.servers Pabrikan duwe sawetara makelar sing kadhaptar lan bisa takon broker liyane sing dadi pimpinan bagean anyar. Banjur nggawe sambungan menyang broker 1 lan terus ngirim pesen.

Gabah. 9. Ngirim pesen diterusake sawise break cendhak

Broker 3 malah luwih konco. Iku nggawe panjalukan njupuk nanging ora bisa nyelarasake. Iki bisa uga amarga sambungan jaringan alon ing antarane makelar, masalah panyimpenan, lan liya-liyane. Saiki ISR kasusun saka siji replika - pimpinan! Pabrikan terus ngirim pesen lan nampa konfirmasi.

Gabah. 10. Follower ing broker 3 dibusak saka ISR

Broker 1 mudhun lan peran kepemimpinan dadi broker 3 kanthi mundhut 15286 pesen! Pabrikan nampa pesen kesalahan sambungan. Transisi menyang pimpinan njaba ISR mung bisa amarga setelan najis.leader.election.enable=bener. Yen wis diinstal ing palsu, banjur transisi ora bakal kelakon lan kabeh panjalukan maca lan nulis bakal ditolak. Ing kasus iki, kita ngenteni broker 1 bali karo data sing utuh ing replika, sing bakal njupuk alih kepemimpinan maneh.

Gabah. 11. Broker 1 tiba. Nalika gagal, akeh pesen sing ilang

Produser nggawe sambungan karo broker pungkasan lan weruh yen dheweke saiki dadi pimpinan bagean kasebut. Dheweke wiwit ngirim pesen menyang broker 3.

Gabah. 12. Sawise istirahat sedhela, pesen dikirim maneh menyang bagean 0

Kita weruh manawa, kajaba interupsi cendhak kanggo nggawe sambungan anyar lan golek pimpinan anyar, pabrikan terus-terusan ngirim pesen. Konfigurasi iki njamin kasedhiyan kanthi biaya konsistensi (keamanan data). Kafka ilang ewonan pesen nanging terus nampa tulisan anyar.

Acks = kabeh lan ISR

Ayo dadi mbaleni skenario iki maneh, nanging karo acks = kabeh. Broker 3 duwe latensi rata-rata patang detik. Produsèn ngirim pesen karo acks = kabeh, lan saiki ora nampa respon cepet. Pimpinan ngenteni pesen sing disimpen dening kabeh replika ing ISR.

Gabah. 13. ISR karo telung replika. Salah sijine alon, nyebabake telat ngrekam

Sawise patang detik wektu tundha tambahan, broker 2 ngirim ack. Kabeh replika saiki dianyari kanthi lengkap.

Gabah. 14. Kabeh replika nyimpen pesen lan ngirim ack

Broker 3 saiki luwih mundur lan dicopot saka ISR. Latency suda sacara signifikan amarga ora ana replika alon ing ISR. Broker 2 saiki mung ngenteni broker 1, lan dheweke duwe lag rata-rata 500 ms.

Gabah. 15. Replika ing broker 3 dibusak saka ISR

Banjur broker 2 tiba lan kepemimpinan liwat menyang broker 1 tanpa mundhut pesen.

Gabah. 16. Broker 2 tiba

Pabrikan nemokake pimpinan anyar lan wiwit ngirim pesen marang dheweke. Latensi luwih suda amarga ISR saiki kalebu siji replika! Mulane pilihan acks = kabeh ora nambah redundansi.

Gabah. 17. Replika ing broker 1 njupuk timbal tanpa kelangan pesen

Banjur broker 1 tabrakan lan timbal menyang broker 3 kanthi mundhut 14238 pesen!

Gabah. 18. Broker 1 mati lan transisi kepemimpinan kanthi setelan najis nyebabake mundhut data sing akeh

Kita ora bisa nginstal pilihan najis.pemimpin.pemilihan.aktif menyang makna bener. Kanthi gawan iku witjaksono kanggo palsu. Setelan acks = kabeh с najis.leader.election.enable=bener nyedhiyakake aksesibilitas karo sawetara keamanan data sing ditambahake. Nanging sampeyan bisa ndeleng, kita isih bisa ilang pesen.

Nanging apa yen kita pengin nambah keamanan data? Sampeyan bisa sijine najis.pemimpin.pemilihan.aktif = palsu, nanging iki ora kudu nglindhungi kita saka mundhut data. Yen pimpinan ambruk hard lan njupuk data karo, banjur pesen isih ilang, plus kasedhiyan ilang nganti administrator mulihake kahanan.

Iku luwih apik kanggo mesthekake yen kabeh pesen sing keluwih, lan digunakake discard rekaman. Banjur, paling ora saka sudut pandang broker, mundhut data mung bisa ditindakake yen ana loro utawa luwih gagal bebarengan.

Acks=all, min.insync.replicas lan ISR

Kanthi konfigurasi topik min.insync.replicas Kita nambah tingkat keamanan data. Ayo dadi liwat bagean pungkasan saka skenario sadurungé maneh, nanging wektu iki karo min.insync.replicas=2.

Dadi broker 2 duwe pimpinan replika lan pengikut ing broker 3 dicopot saka ISR.

Gabah. 19. ISR saka rong réplika

Broker 2 tiba lan kepemimpinan ngliwati broker 1 tanpa mundhut pesen. Nanging saiki ISR kasusun saka mung siji replika. Iki ora ketemu nomer minimal kanggo nampa cathetan, lan mulane broker nanggapi nyoba nulis karo kesalahan Ora CukupReplika.

Gabah. 20. Jumlah ISR luwih murah tinimbang sing ditemtokake ing min.insync.replicas

Konfigurasi iki kurban kasedhiyan kanggo konsistensi. Sadurunge ngakoni pesen, kita mesthekake yen ditulis paling ora rong replika. Iki menehi kapercayan pabrikan luwih akeh. Ing kene, mundhut pesen mung bisa ditindakake yen rong replika gagal bebarengan ing interval sing cendhak nganti pesen kasebut ditiru menyang pengikut tambahan, sing ora mungkin. Nanging yen sampeyan super paranoid, sampeyan bisa nyetel faktor réplikasi kanggo 5, lan min.insync.replicas dening 3. Kene telung makelar kudu tiba ing wektu sing padha ilang rekaman! Mesthi, sampeyan mbayar linuwih iki ing latensi tambahan.

Nalika aksesibilitas perlu kanggo keamanan data

Kaya ing kasus karo RabbitMQ, kadhangkala aksesibilitas perlu kanggo keamanan data. Mangkene sing kudu sampeyan pikirake:

Apa penerbit mung bisa ngasilake kesalahan lan njaluk layanan hulu utawa pangguna nyoba maneh mengko?
Apa penerbit bisa nyimpen pesen kasebut sacara lokal utawa ing basis data kanggo nyoba maneh mengko?

Yen jawabane ora, banjur ngoptimalake kasedhiyan nambah keamanan data. Sampeyan bakal kelangan kurang data yen sampeyan milih kasedhiyan tinimbang ora ngrekam. Mangkono, iku kabeh teka mudhun kanggo nemokake imbangan, lan kaputusan gumantung ing kahanan tartamtu.

Makna saka ISR

Sakumpulan ISR ngidini sampeyan milih imbangan optimal antarane keamanan data lan latensi. Contone, mesthekake kasedhiyan ing acara Gagal mayoritas replika, minimalake impact mati utawa alon replika ing syarat-syarat latensi.

Kita milih makna dhewe replica.lag.time.max.ms miturut kabutuhan sampeyan. Ateges, parameter iki tegese wektu tundha sing arep ditampa nalika acks = kabeh. Nilai standar yaiku sepuluh detik. Yen iki dawa banget kanggo sampeyan, sampeyan bisa nyuda. Banjur frekuensi owah-owahan ing ISR bakal nambah, amarga para pengikut bakal dibusak lan ditambahake luwih asring.

RabbitMQ mung minangka set pangilon sing kudu ditiru. Pangilon alon ngenalake latensi tambahan, lan pangilon mati bisa ngenteni nganti paket sing mriksa kasedhiyan saben simpul (net obah) nanggapi. ISR minangka cara sing menarik kanggo ngindhari masalah latensi kasebut. Nanging kita risiko kelangan redundansi amarga ISR mung bisa nyilikake pimpinan. Kanggo ngindhari risiko iki, gunakake setelan kasebut min.insync.replicas.

Jaminan sambungan klien

Ing setelan bootstrap.servers produser lan konsumen bisa nemtokake sawetara makelar kanggo nyambungake klien. Ide kasebut yaiku nalika siji simpul mudhun, ana sawetara sing isih ana sing bisa dibukak dening klien. Iki ora kudu pimpinan bagean, nanging mung springboard kanggo loading dhisikan. Klien bisa takon simpul endi sing dadi pimpinan partisi maca / nulis.

Ing RabbitMQ, klien bisa nyambung menyang simpul apa wae, lan rute internal ngirim panjalukan menyang ngendi wae. Iki tegese sampeyan bisa nginstal load balancer ing ngarep RabbitMQ. Kafka mbutuhake klien nyambung menyang simpul sing dadi pimpinan partisi sing cocog. Ing kahanan kaya mengkono, sampeyan ora bisa nginstal load balancer. Dhaptar bootstrap.servers Penting yen klien bisa ngakses lan nemokake simpul sing bener sawise gagal.

Arsitektur Konsensus Kafka

Nganti saiki, kita durung nganggep kepiye kluster sinau babagan kejatuhan broker lan kepiye pimpinan anyar dipilih. Kanggo ngerti cara kerja Kafka karo partisi jaringan, sampeyan kudu ngerti arsitektur konsensus.

Saben kluster Kafka disebarake bebarengan karo kluster Zookeeper, yaiku layanan konsensus sing disebarake sing ngidini sistem tekan konsensus ing sawetara negara, prioritas konsistensi tinimbang kasedhiyan. Idin saka mayoritas simpul Zookeeper dibutuhake kanggo nyetujoni operasi maca lan nulis.

Zookeeper nyimpen status kluster:

Dhaptar topik, bagean, konfigurasi, replika pimpinan saiki, replika sing disenengi.
Anggota kluster. Saben makelar ping kluster Zookeeper. Yen ora nampa ping ing wektu tartamtu, Zookeeper nyathet makelar kasebut ora kasedhiya.
Milih kelenjar utama lan cadangan kanggo controller.

Node pengontrol minangka salah sawijining makelar Kafka sing tanggung jawab kanggo milih pimpinan replika. Zookeeper ngirim kabar menyang controller babagan anggota kluster lan owah-owahan topik, lan controller kudu tumindak ing owah-owahan iki.

Contone, ayo njupuk topik anyar kanthi sepuluh partisi lan faktor replikasi 3. Kontroler kudu milih pimpinan kanggo saben partisi, nyoba nyebarake pimpinan kanthi optimal ing antarane para makelar.

Kanggo saben bagean controller:

nganyari informasi ing Zookeeper babagan ISR lan pimpinan;
Ngirim LeaderAndISRCmand kanggo saben broker sing dadi replika partisi iki, ngandhani makelar babagan ISR lan pimpinan.

Nalika makelar karo pimpinan tiba, Zookeeper ngirim kabar menyang controller, lan milih pimpinan anyar. Maneh, controller nganyari Zookeeper pisanan lan banjur ngirim printah kanggo saben makelar menehi kabar babagan owah-owahan kepemimpinan.

Saben pimpinan tanggung jawab kanggo ngrekrut ISR. Setelan replica.lag.time.max.ms nemtokake sapa sing bakal mlebu ing kana. Nalika owah-owahan ISR, pimpinan ngirim informasi anyar kanggo Zookeeper.

Zookeeper tansah dilaporake babagan owah-owahan supaya yen ana kegagalan, manajemen transisi lancar menyang pimpinan anyar.

Gabah. 21. Konsensus Kafka

Protokol replikasi

Ngerteni rincian replikasi mbantu sampeyan luwih ngerti kemungkinan skenario mundhut data.

Pitakonan sampling, Log End Offset (LEO) lan Highwater Mark (HW)

Kita nganggep manawa para pengikut ngirim panjalukan njupuk menyang pimpinan kanthi periodik. Interval standar yaiku 500ms. Iki beda karo RabbitMQ amarga replikasi RabbitMQ ora diwiwiti dening pangilon antrian nanging dening master. Master nyurung owah-owahan menyang pangilon.

Pimpinan lan kabeh pengikut nyimpen Log End Offset (LEO) lan label Highwater (HW). Tandha LEO nyimpen offset pesen pungkasan ing replika lokal, lan HW nahan offset saka komitmen pungkasan. Elinga yen kanggo status commit, pesen kudu tetep ing kabeh replika ISR. Iki tegese LEO biasane rada ahead saka HW.

Nalika pimpinan nampa pesen, iku nyimpen ing lokal. Pengikut nggawe panjaluk njupuk kanthi ngirim LEO. Pimpinan banjur ngirim pesen sing diwiwiti saka LEO iki lan uga ngirim HW saiki. Nalika pimpinan nampa informasi sing kabeh replika wis disimpen pesen ing offset diwenehi, gerakane tandha HW. Mung pimpinan bisa mindhah HW, lan kabeh pandherekipun bakal ngerti nilai saiki ing respon kanggo panjalukan sing. Iki tegese pandherekipun bisa ketinggalan pimpinan ing loro pesen lan kawruh HW. Konsumen nampa pesen mung nganti HW saiki.

Elinga yen "terus-terusan" tegese ditulis ing memori, dudu menyang disk. Kanggo kinerja, Kafka nyinkronake menyang disk ing interval tartamtu. RabbitMQ uga duwe interval kasebut, nanging bakal ngirim pangakuan menyang penerbit mung sawise master lan kabeh pangilon wis nulis pesen menyang disk. Pangembang Kafka, amarga alasan kinerja, mutusake ngirim ack sanalika pesen kasebut ditulis ing memori. Kafka taruhan yen redundansi ngimbangi risiko nyimpen sedhela pesen sing diakoni mung ing memori.

Gagal pimpinan

Nalika pimpinan tiba, Zookeeper ngabari controller, lan milih tiron pimpinan anyar. Pimpinan anyar nyetel tandha HW anyar miturut LEO. Para pengikut banjur nampa informasi babagan pimpinan anyar. Gumantung ing versi Kafka, pengikut bakal milih salah siji saka rong skenario:

Iku bakal truncate log lokal kanggo HW dikenal lan ngirim panjalukan kanggo pimpinan anyar kanggo pesen sawise tandha iki.
Bakal ngirim panjalukan kanggo pimpinan kanggo mangerteni HW nalika dheweke kapilih dadi pimpinan, banjur truncate log menyang offset iki. Banjur bakal miwiti nggawe panjalukan njupuk periodik wiwit offset iki.

Pengikut bisa uga kudu ngethok log amarga alasan ing ngisor iki:

Nalika pimpinan gagal, pengikut pisanan ing set ISR sing didaftar karo Zookeeper menang pemilihan lan dadi pimpinan. Kabeh pandherekipun ing ISR, sanajan dianggep "sinkronisasi," bisa uga ora nampa salinan kabeh pesen saka mantan pimpinan. Sampeyan bisa uga manawa pengikut sing ditampilake ora duwe salinan paling anyar. Kafka mesthekake yen ora ana bedane antarane replika. Dadi, kanggo ngindhari bedo, saben pengikut kudu ngethok log menyang nilai HW pimpinan anyar nalika pemilihan. Iki minangka alesan liyane ngapa setelan acks = kabeh dadi penting kanggo konsistensi.
Pesen ditulis sacara periodik menyang disk. Yen kabeh simpul kluster gagal ing wektu sing padha, banjur replika kanthi offset sing beda bakal disimpen ing disk. Bisa uga nalika makelar bali online, pimpinan anyar sing dipilih bakal ana ing mburi para pengikut amarga disimpen ing disk sadurunge liyane.

Reuni karo kluster

Nalika gabung maneh ing kluster, replika nindakake kaya nalika pimpinan gagal: mriksa replika pimpinan lan ngethok log menyang HW (nalika pemilihan). Dibandhingake, RabbitMQ padha nganggep simpul sing digabung maneh minangka anyar. Ing kasus loro, makelar mbuwang negara sing ana. Yen sinkronisasi otomatis digunakake, master kudu niru pancen kabeh isi saiki menyang pangilon anyar ing "supaya donya ngenteni kabeh". Master ora nampa operasi maca utawa nulis sajrone operasi iki. Pendekatan iki nggawe masalah ing antrian gedhe.

Kafka minangka log sing disebarake lan umume nyimpen pesen luwih akeh tinimbang antrian RabbitMQ, ing ngendi data dibusak saka antrian sawise diwaca. Antrian aktif kudu tetep relatif cilik. Nanging Kafka minangka log kanthi kabijakan penylametan dhewe, sing bisa nyetel wektu dina utawa minggu. Pamblokiran antrian lan pendekatan sinkronisasi lengkap pancen ora bisa ditampa kanggo log sing disebarake. Nanging, para pengikut Kafka mung ngethok log menyang HW pimpinan (nalika pemilihane) yen salinane luwih dhisik tinimbang pimpinan. Ing kasus sing luwih akeh, nalika pengikut ana ing mburi, mula nggawe panjaluk njupuk diwiwiti karo LEO saiki.

Para pengikut anyar utawa gabung maneh wiwit ing njaba ISR lan ora melu komitmen. Dheweke mung kerja bareng karo grup kasebut, nampa pesen kanthi cepet nganti bisa nyekel pimpinan lan mlebu ISR. Ora ana kunci lan ora perlu mbuwang kabeh data sampeyan.

Kelangan panyambungan

Kafka nduweni komponen luwih akeh tinimbang RabbitMQ, saengga nduweni prilaku sing luwih rumit nalika kluster dadi pedhot. Nanging Kafka wiwitane dirancang kanggo klompok, mula solusi kasebut dipikirake kanthi apik.

Ing ngisor iki sawetara skenario kegagalan konektivitas:

Skenario 1: Pengikut ora weruh pimpinan, nanging isih weruh Zookeeper.
Skenario 2: Pimpinan ora weruh pengikut, nanging isih ndeleng Zookeeper.
Skenario 3: Pengikut ndeleng pimpinan, nanging ora weruh Zookeeper.
Skenario 4: Pemimpin ndeleng para pengikut, nanging ora weruh Zookeeper.
Skenario 5: Pengikut wis kapisah saka loro simpul Kafka liyane lan Zookeeper.
Skenario 6: Pimpinan pancen kapisah saka simpul Kafka lan Zookeeper liyane.
Skenario 7: Node pengontrol Kafka ora bisa ndeleng simpul Kafka liyane.
Skenario 8: Kafka controller ora weruh Zookeeper.

Saben skenario duwe prilaku dhewe.

Skenario 1: Follower ora ndeleng pimpinan, nanging isih ndeleng Zookeeper

Gabah. 22. Skenario 1: ISR saka telung replika

Gagal konektivitas misahake broker 3 saka makelar 1 lan 2, nanging ora saka Zookeeper. Broker 3 ora bisa ngirim panjalukan njupuk maneh. Sawise wektu wis liwati replica.lag.time.max.ms iku dibusak saka ISR lan ora melu pesen commits. Sawise konektivitas dibalèkaké, bakal nerusake njupuk panjalukan lan gabung karo ISR nalika nyekel pimpinan. Zookeeper bakal terus nampa ping lan nganggep yen makelar kasebut urip lan sehat.

Gabah. 23. Skenario 1: Broker dibusak saka ISR yen ora ana panjalukan njupuk sing ditampa saka ing interval replica.lag.time.max.ms

Ora ana penundaan pamisah-otak utawa simpul kaya ing RabbitMQ. Nanging, redundansi dikurangi.

Skenario 2: Pemimpin ora weruh pengikut, nanging isih ndeleng Zookeeper

Gabah. 24. Skenario 2. Pimpinan lan loro pandherekipun

A risak ing panyambungan jaringan misahake pimpinan saka pandherekipun, nanging makelar isih bisa ndeleng Zookeeper. Kaya ing skenario pisanan, ISR nyusut, nanging wektu iki mung kanggo pimpinan amarga kabeh pengikut mandheg ngirim panjaluk njupuk. Maneh, ora ana divisi logis. Nanging, ana kelangan redundansi kanggo pesen anyar nganti konektivitas dibalekake. Zookeeper terus nampa ping lan percaya yen makelar kasebut urip lan sehat.

Gabah. 25. Skenario 2. ISR wis nyusut mung kanggo pimpinan

Skenario 3. Follower ndeleng pimpinan, nanging ora weruh Zookeeper

Pengikut dipisahake saka Zookeeper, nanging ora saka broker karo pimpinan. Akibaté, pengikut terus nggawe panjalukan njupuk lan dadi anggota ISR. Zookeeper ora nampa ping maneh lan ndhaptar kacilakan broker, nanging amarga mung dadi pengikut, ora ana akibat sawise pulih.

Gabah. 26. Skenario 3: Pandherekipun terus ngirim panjalukan fetch dhateng pimpinan

Skenario 4. Pimpinan ndeleng pandherekipun, nanging ora weruh Zookeeper

Gabah. 27. Skenario 4. Pimpinan lan loro pandherekipun

Pimpinan dipisahake saka Zookeeper, nanging ora saka makelar karo pengikut.

Gabah. 28. Skenario 4: Pemimpin diisolasi saka Zookeeper

Sawise sawetara wektu, Zookeeper bakal ndhaptar gagal broker lan menehi kabar marang pengontrol babagan kasebut. Dheweke bakal milih pimpinan anyar ing antarane para pengikute. Nanging, pimpinan asli bakal terus mikir yen iku pimpinan lan bakal terus nampa entri saka aks = 1. Para pengikut ora ngirim panjaluk njupuk maneh, mula dheweke bakal nganggep dheweke wis mati lan nyoba nyuda ISR dhewe. Nanging wiwit iku ora duwe sambungan kanggo Zookeeper, iku ora bakal bisa nindakake iki, lan ing titik bakal nolak kanggo nampa entri luwih.

Pesen acks = kabeh ora bakal nampa pangakuan amarga ISR pisanan nguripake kabeh réplika, lan pesen ora tekan wong. Nalika pimpinan asli nyoba nyopot saka ISR, dheweke ora bisa nindakake lan bakal mandheg nampa pesen apa wae.

Klien enggal sok dong mirsani owah-owahan ing pimpinan lan wiwit ngirim cathetan menyang server anyar. Sawise jaringan dibalèkaké, pimpinan asli weruh sing ora ana maneh pimpinan lan truncates log menyang Nilai HW sing pimpinan anyar ing wektu Gagal supaya log divergence. Banjur bakal miwiti ngirim panjalukan njupuk menyang pimpinan anyar. Kabeh cathetan saka pimpinan asli sing ora ditiru dadi pimpinan anyar bakal ilang. Tegese, pesen sing ora diakoni dening pimpinan asli sajrone sawetara detik nalika rong pimpinan lagi kerja bakal ilang.

Gabah. 29. Skenario 4. Pimpinan ing broker 1 dadi pengikut sawise jaringan dipulihake

Skenario 5: Pengikut wis kapisah saka loro simpul Kafka liyane lan Zookeeper

Pengikut wis terisolasi saka loro simpul Kafka liyane lan Zookeeper. Dheweke mung mbusak dhewe saka ISR nganti jaringan dibalekake, lan banjur nyekel wong liya.

Gabah. 30. Skenario 5: pengikut sing diisolasi dibusak saka ISR

Skenario 6: Pimpinan pancen kapisah saka simpul Kafka lan Zookeeper liyane

Gabah. 31. Skenario 6. Pimpinan lan loro pandherekipun

Pimpinan wis terisolasi saka pandherekipun, controller lan Zookeeper. Kanggo wektu cendhak bakal terus nampa entri saka aks = 1.

Gabah. 32. Skenario 6: Ngisolasi pimpinan saka simpul Kafka lan Zookeeper liyane

Duwe ora nampa panjalukan sawise kadaluwarsa replica.lag.time.max.ms, bakal nyoba kanggo nyilikake ISR kanggo dhewe, nanging ora bakal bisa kanggo nindakake amarga ora ana komunikasi karo Zookeeper, banjur bakal mandheg nampa nulis.

Sauntara kuwi, Zookeeper bakal menehi tandha yen broker sing terisolasi wis mati lan pengontrol bakal milih pimpinan anyar.

Gabah. 33. Skenario 6. Loro pimpinan

Pimpinan asli bisa nampa entri sawetara detik, nanging banjur mandheg nampa pesen apa wae. Klien dianyari saben 60 detik kanthi metadata paling anyar. Dheweke bakal dilaporake babagan owah-owahan pimpinan lan bakal miwiti ngirim entri menyang pimpinan anyar.

Gabah. 34. Skenario 6: Produsen ngalih menyang pimpinan anyar

Kabeh entri dikonfirmasi digawe dening pimpinan asli wiwit mundhut saka panyambungan bakal ilang. Sawise jaringan dipulihake, pimpinan asli bakal nemokake liwat Zookeeper yen ora dadi pimpinan maneh. Banjur bakal truncate log menyang HW pimpinan anyar nalika pemilihan lan wiwit ngirim panjaluk minangka pengikut.

Gabah. 35. Skenario 6: Pimpinan asli dadi pengikut sawise konektivitas jaringan dibalekake

Ing kahanan iki, pemisahan logis bisa kedadeyan kanggo wektu sing cendhak, nanging mung yen aks = 1 и min.insync.replicas uga 1. pamisahan logis kanthi otomatis ends salah siji sawise jaringan dibalèkaké, nalika pimpinan asli nyadari sing ora ana maneh pimpinan, utawa nalika kabeh klien éling sing pimpinan wis diganti lan miwiti nulis kanggo pimpinan anyar - whichever mengkono pisanan. Ing kasus apa wae, sawetara pesen bakal ilang, nanging mung karo aks = 1.

Ana varian liya saka skenario iki, ing ngendi, sadurunge pamisah jaringan, para pengikut ambruk lan pimpinan ngompres ISR mung kanggo awake dhewe. Banjur dadi terisolasi amarga kelangan panyambungan. A pimpinan anyar kapilih, nanging pimpinan asli terus nampa entri, malah acks = kabeh, amarga ora ana wong liya ing ISR kajaba dheweke. Cathetan iki bakal ilang sawise jaringan dipulihake. Cara mung kanggo ngindhari pilihan iki yaiku min.insync.replicas = 2.

Skenario 7: Node Controller Kafka Ora Bisa Deleng Node Kafka Liyane

Umumé, yen sambungan karo simpul Kafka ilang, pengontrol ora bakal bisa ngirim informasi pangowahan pimpinan. Ing kasus sing paling awon, iki bakal nyebabake pemisahan logis jangka pendek, kaya ing skenario 6. Luwih kerep tinimbang ora, makelar mung ora bakal dadi calon pimpinan yen sing terakhir gagal.

Skenario 8: Kafka controller ora weruh Zookeeper

Zookeeper ora bakal nampa ping saka controller tiba lan bakal milih simpul Kafka anyar minangka controller. Kontroler asli bisa terus nampilake dhewe, nanging ora nampa kabar saka Zookeeper, mula ora ana tugas sing kudu ditindakake. Sawise jaringan dipulihake, dheweke bakal ngerti yen dheweke ora dadi pengontrol maneh, nanging wis dadi simpul Kafka biasa.

Kesimpulan saka skenario

Kita weruh yen mundhut panyambungan pengikut ora nyebabake mundhut pesen, nanging mung nyuda redundansi sementara nganti jaringan dipulihake. Iki, mesthi, bisa mimpin kanggo mundhut data yen siji utawa luwih kelenjar ilang.

Yen pimpinan dadi pisah saka Zookeeper amarga kelangan konektivitas, iki bisa nyebabake pesen ilang saka aks = 1. Kurang komunikasi karo Zookeeper nyebabake pamisah logis singkat karo loro pimpinan kasebut. Masalah iki ditanggulangi dening parameter acks = kabeh.

Parameter min.insync.replicas dadi loro utawa luwih replika menehi jaminan tambahan manawa skenario jangka pendek kasebut ora bakal nyebabake pesen ilang kaya ing Skenario 6.

Ringkesan Pesen Ilang

Ayo dhaptar kabeh cara sampeyan bisa ilang data ing Kafka:

Sembarang kegagalan pimpinan yen pesen dikonfirmasi nggunakake aks = 1
Sembarang transisi najis saka Kepemimpinan, sing, kanggo pandherekipun njaba ISR, malah karo acks = kabeh
Ngisolasi pimpinan saka Zookeeper yen pesen dikonfirmasi nggunakake aks = 1
Isolasi lengkap pimpinan sing wis nyuda klompok ISR dadi awake dhewe. Kabeh pesen bakal ilang, malah acks = kabeh. Iki mung bener yen min.insync.replicas=1.
Gagal simultan kabeh simpul partisi. Amarga pesen diakoni saka memori, sawetara bisa uga durung ditulis ing disk. Sawise urip maneh server, sawetara pesen bisa uga ilang.

Transisi kepemimpinan sing ora murni bisa dihindari kanthi nglarang utawa njamin paling ora rong redundansi. Konfigurasi sing paling awet yaiku kombinasi acks = kabeh и min.insync.replicas liwat 1.

Perbandingan langsung saka linuwih RabbitMQ lan Kafka

Kanggo njamin linuwih lan kasedhiyan dhuwur, loro platform kasebut ngetrapake sistem replikasi primer lan sekunder. Nanging, RabbitMQ duwe tumit Achilles. Nalika nyambungake maneh sawise gagal, simpul mbuwang data lan sinkronisasi diblokir. Iki dobel whammy nelpon pitakonan umur dawa saka antrian gedhe ing RabbitMQ. Sampeyan kudu nampa redundansi suda utawa wektu pamblokiran dawa. Ngurangi redundansi mundhak risiko mundhut data massive. Nanging yen antrian cilik, banjur kanggo redundansi, wektu cendhak ora kasedhiya (sawetara detik) bisa ditangani kanthi nggunakake nyoba sambungan bola-bali.

Kafka ora duwe masalah iki. Mbusak data mung saka titik divergensi antarane pimpinan lan pandherekipun. Kabeh data sing dienggo bareng disimpen. Kajaba iku, replikasi ora ngalangi sistem. Pimpinan terus nampa kiriman nalika pengikut anyar nyekel, mula kanggo devops, gabung utawa gabung maneh ing kluster dadi tugas sing ora pati penting. Mesthi, isih ana masalah kayata bandwidth jaringan sajrone replikasi. Yen sampeyan nambahake akeh pengikut ing wektu sing padha, sampeyan bisa nemokake watesan bandwidth.

RabbitMQ luwih unggul tinimbang Kafka ing linuwih nalika sawetara server ing kluster gagal ing wektu sing padha. Kaya sing wis dingerteni, RabbitMQ ngirim konfirmasi menyang penerbit mung sawise pesen kasebut ditulis ing disk dening master lan kabeh pangilon. Nanging iki nambah latensi tambahan amarga rong alasan:

fsync saben sawetara atus milidetik
Gagal pangilon mung bisa dideleng sawise umur paket sing mriksa kasedhiyan saben simpul (net obah) wis kadaluwarsa. Yen pangilon alon utawa tiba, iki nambah wektu tundha.

Taruhan Kafka yaiku yen pesen disimpen ing pirang-pirang simpul, bisa ngakoni pesen sanalika tekan memori. Amarga iki, ana risiko kelangan pesen apa wae (malah acks = kabeh, min.insync.replicas=2) ing kasus gagal simultan.

Sakabèhé, Kafka nampilake kinerja piranti lunak sing luwih apik lan dirancang saka wiwitan kanggo kluster. Jumlah pengikut bisa ditambah dadi 11 yen perlu kanggo linuwih. Faktor replikasi 5 lan jumlah minimal replika ing sinkronisasi min.insync.replicas=3 bakal nggawe mundhut pesen acara arang banget. Yen infrastruktur sampeyan bisa ndhukung rasio replikasi lan tingkat redundansi iki, sampeyan bisa milih pilihan iki.

RabbitMQ clustering apik kanggo antrian cilik. Nanging malah antrian cilik bisa tuwuh cepet nalika ana lalu lintas abot. Sawise antrian dadi gedhe, sampeyan kudu nggawe pilihan angel antarane kasedhiyan lan linuwih. Pengelompokan RabbitMQ paling cocog kanggo kahanan sing ora khas ing ngendi keuntungan saka keluwesan RabbitMQ luwih gedhe tinimbang kekurangan saka pengelompokan kasebut.

Salah sawijining antidote kanggo kerentanan RabbitMQ kanggo antrian gedhe yaiku ngrusak antrian kasebut dadi antrian sing luwih cilik. Yen sampeyan ora mbutuhake pesenan lengkap kabeh antrian, nanging mung pesen sing cocog (contone, pesen saka klien tartamtu), utawa ora pesen apa-apa, banjur pilihan iki bisa ditampa: deleng proyekku Rebalancer kanggo pamisah antrian (proyèk isih ing tataran awal).

Pungkasan, aja lali babagan sawetara kewan omo ing mekanisme clustering lan replikasi loro RabbitMQ lan Kafka. Swara wektu, sistem wis dadi luwih diwasa lan stabil, nanging ora ana pesen bakal 100% aman saka mundhut! Kajaba iku, kacilakan skala gedhe dumadi ing pusat data!

Yen aku ora kejawab, nggawe kesalahan, utawa sampeyan ora setuju karo salah sawijining poin, aja ragu-ragu nulis komentar utawa hubungi kula.

Aku asring takon: "Apa sing kudu dipilih, Kafka utawa RabbitMQ?", "Platform sing luwih apik?". Bebener iku pancene gumantung ing kahanan, pengalaman saiki, etc.. Aku mangu-mangu kanggo menehi mratelakake panemume amarga iku bakal kakehan oversimplification kanggo menehi rekomendasi siji platform kanggo kabeh kasus panggunaan lan bisa watesan. Aku nulis seri artikel iki supaya sampeyan bisa nggawe pendapat sampeyan dhewe.

Aku pengin ngomong yen loro sistem iku pimpinan ing wilayah iki. Aku bisa uga rada bias amarga saka pengalaman karo proyek aku cenderung ngormati prekara kaya pesen pesen sing dijamin lan linuwih.

Aku weruh teknologi liyane sing kurang linuwih iki lan pesenan dijamin, banjur aku ndeleng RabbitMQ lan Kafka lan éling Nilai luar biasa saka loro sistem iki.

Source: www.habr.com

RabbitMQ vs Kafka: Toleransi Fault lan Kasedhiyan Dhuwur