В lasta artikolo ni rigardis RabbitMQ-grupon por faŭltoleremo kaj alta havebleco. Nun ni enprofundu en Apache Kafka.

Ĉi tie la unuo de reproduktado estas la sekcio. Ĉiu temo havas unu aŭ plurajn sekciojn. Ĉiu sekcio havas gvidanton kun aŭ sen sekvantoj. Kreante temon, vi specifas la nombron da sekcioj kaj la replika koeficiento. La kutima valoro estas 3, kio signifas tri kopiojn: unu gvidanto kaj du sekvantoj.

Rizo. 1. Kvar sekcioj estas distribuitaj inter tri makleristoj

Ĉiuj lego- kaj skribpetoj iras al la gvidanto. Partianoj periode sendas petojn al la gvidanto por ricevi la plej novajn mesaĝojn. Konsumantoj neniam turnas sin al adeptoj; ĉi-lastaj ekzistas nur por redundo kaj mistoleremo.

Malsukceso de la sekcio

Kiam makleristo malsukcesas, la gvidantoj de pluraj sekcioj ofte malsukcesas. En ĉiu el ili, sekvanto de alia nodo iĝas la gvidanto. Fakte, tio ne ĉiam okazas, ĉar la sinkroniga faktoro ankaŭ influas: ĉu estas sinkronigitaj sekvantoj, kaj se ne, ĉu tiam ŝanĝado al nesinkronigita kopio estas permesita. Sed ni ne kompliku la aferojn nuntempe.

Makleristo 3 forlasas la reton, kaj nova gvidanto estas elektita por sekcio 2 ĉe makleristo 2.

Rizo. 2. Makleristo 3 mortas kaj lia sekvanto sur makleristo 2 estas elektita kiel la nova gvidanto de sekcio 2

Tiam makleristo 1 foriras kaj sekcio 1 ankaŭ perdas sian gvidanton, kies rolo pasas al makleristo 2.

Rizo. 3. Restas unu makleristo. Ĉiuj gvidantoj estas sur unu makleristo kun nula redundo

Kiam makleristo 1 revenas interrete, ĝi aldonas kvar sekvantojn, provizante iom da redundo al ĉiu sekcio. Sed ĉiuj gvidantoj ankoraŭ restis ĉe makleristo 2.

Rizo. 4. Gvidantoj restas ĉe makleristo 2

Kiam makleristo 3 aperas, ni revenas al tri kopioj per sekcio. Sed ĉiuj gvidantoj ankoraŭ estas sur makleristo 2.

Rizo. 5. Malekvilibra lokigo de gvidantoj post la restarigo de makleristoj 1 kaj 3

Kafka havas ilon por pli bona gvidanto-rebalancado ol RabbitMQ. Tie, vi devis uzi aldonaĵon aŭ skripton de triaj, kiuj ŝanĝis la politikojn por migrado de la majstra nodo reduktante redundon dum migrado. Krome, por grandaj vicoj ni devis akcepti malhaveblecon dum sinkronigado.

Kafka havas la koncepton de "preferataj kopioj" por la gvidrolo. Kiam temsekcioj estas kreitaj, Kafka provas distribui gvidantojn egale tra nodoj kaj markas tiujn unuajn gvidantojn kiel preferatajn. Kun la tempo, pro servilaj rekomencoj, misfunkciadoj kaj konekteblecaj paneoj, gvidantoj povas alveni sur aliaj nodoj, kiel en la ekstrema kazo priskribita supre.

Por ripari ĉi tion, Kafka ofertas du eblojn:

• Opcio auto.leader.rebalance.enable=vera permesas al la regilnodo aŭtomate reasigni gvidantojn reen al preferataj kopioj kaj tiel restarigi unuforman distribuon.
• La administranto povas ruli la skripton kafka-preferred-replica-election.sh por mana reasignado.

Rizo. 6. Replikoj post rebalancado

Ĉi tio estis simpligita versio de la fiasko, sed la realo estas pli kompleksa, kvankam estas nenio tro komplika ĉi tie. Ĉio dependas de sinkronigitaj kopioj (In-Sync Replicas, ISR).

Sinkronigitaj Kopioj (ISR)

ISR estas aro de kopioj de sekcio, kiu estas konsiderata "sinkronigita" (sinkronigita). Estas gvidanto, sed eble ne estas sekvantoj. Sekvanto estas konsiderita sinkronigita se ĝi faris precizajn kopiojn de ĉiuj mesaĝoj de la gvidanto antaŭ ol la intervalo eksvalidiĝas replica.lag.time.max.ms.

Ano estas forigita de la ISR-aro se ĝi:

• ne faris peton elekti por la intervalo replica.lag.time.max.ms (supoze morta)
• ne sukcesis ĝisdatigi dum la intervalo replica.lag.time.max.ms (konsiderata malrapida)

Partianoj faras specimenajn petojn en la intervalo replica.fetch.wait.max.ms, kiu defaŭlte al 500ms.

Por klare klarigi la celon de ISR, ni devas rigardi konfirmojn de la produktanto kaj iujn malsukcesajn scenarojn. Produktantoj povas elekti kiam la makleristo sendas konfirmon:

• acks=0, konfirmo ne estas sendita
• acks=1, konfirmo estas sendita post kiam la gvidanto skribis mesaĝon al sia loka protokolo
• acks=all, konfirmo estas sendita post kiam ĉiuj kopioj en la ISR skribis la mesaĝon al la lokaj protokoloj

En Kafka terminologio, se la ISR konservis mesaĝon, ĝi estas "engaĝita". Acks=all estas la plej sekura opcio, sed ankaŭ aldonas plian prokraston. Ni rigardu du ekzemplojn de fiasko kaj kiel la malsamaj 'acks'-opcioj interagas kun la ISR-koncepto.

Acks=1 kaj ISR

En ĉi tiu ekzemplo, ni vidos, ke se la gvidanto ne atendas ke ĉiu mesaĝo de ĉiuj sekvantoj estos konservita, tiam perdo de datumoj eblas se la gvidanto malsukcesas. Navigado al nesinkronigita sekvanto povas esti ebligita aŭ malŝaltita per agordo malpura.gvidanto.elekto.ebligi.

En ĉi tiu ekzemplo, la fabrikanto havas la valoron acks=1. La sekcio estas distribuita tra ĉiuj tri makleristoj. Broker 3 estas malantaŭe, ĝi sinkronigis kun la gvidanto antaŭ ok sekundoj kaj nun estas 7456 mesaĝoj malantaŭe. Makleristo 1 estis nur unu sekundo malantaŭe. Nia produktanto sendas mesaĝon kaj rapide ricevas akon reen, sen la ŝarĝo de malrapidaj aŭ mortaj sekvantoj, kiujn la gvidanto ne atendas.

Rizo. 7. ISR kun tri kopioj

Broker 2 malsukcesas kaj la produktanto ricevas konektan eraron. Post kiam gvidado pasas al makleristo 1, ni perdas 123 mesaĝojn. La sekvanto sur makleristo 1 estis parto de la ISR, sed ne estis plene sinkronigita kun la gvidanto kiam ĝi falis.

Rizo. 8. Mesaĝoj estas perditaj kiam ĝi kraŝas

En agordo bootstrap.serviloj La fabrikanto havas plurajn makleristojn listigitaj kaj povas demandi alian makleriston kiu estas la nova sekcia gvidanto. Ĝi tiam establas konekton al makleristo 1 kaj daŭre sendas mesaĝojn.

Rizo. 9. Sendado de mesaĝoj rekomencas post mallonga paŭzo

Broker 3 estas eĉ pli malantaŭe. Ĝi faras preni petojn sed ne povas sinkronigi. Ĉi tio povas esti pro malrapida reto-konekto inter makleristoj, stokado-problemo, ktp. Ĝi estas forigita de la ISR. Nun la ISR konsistas el unu kopio - la gvidanto! La fabrikanto daŭre sendas mesaĝojn kaj ricevas konfirmojn.

Rizo. 10. Sekvanto sur makleristo 3 estas forigita de la ISR

Makleristo 1 falas kaj la gvida rolo iras al makleristo 3 kun la perdo de 15286 mesaĝoj! La fabrikanto ricevas konektan erarmesaĝon. La transiro al gvidanto ekster la ISR estis nur ebla pro la fikso unclean.leader.election.enable=vera. Se ĝi estas instalita en falsa, tiam la transiro ne okazus kaj ĉiuj lego- kaj skribpetoj estus malakceptitaj. En ĉi tiu kazo, ni atendas ke makleristo 1 revenos kun siaj sendifektaj datumoj en la kopio, kiu denove transprenos gvidadon.

Rizo. 11. Makleristo 1 falas. Kiam malsukceso okazas, granda nombro da mesaĝoj estas perditaj

La produktanto establas ligon kun la lasta makleristo kaj vidas, ke li nun estas la gvidanto de la sekcio. Li komencas sendi mesaĝojn al makleristo 3.

Rizo. 12. Post mallonga paŭzo, mesaĝoj estas senditaj denove al sekcio 0

Ni vidis, ke krom mallongaj interrompoj por establi novajn konektojn kaj serĉi novan gvidanton, la fabrikanto senĉese sendis mesaĝojn. Ĉi tiu agordo certigas haveblecon koste de konsistenco (datumsekureco). Kafka perdis milojn da mesaĝoj sed daŭre akceptis novajn skribaĵojn.

Acks=all kaj ISR

Ni ripetu ĉi tiun scenaron denove, sed kun acks=all. Makleristo 3 havas averaĝan latentecon de kvar sekundoj. La fabrikanto sendas mesaĝon kun acks=all, kaj nun ne ricevas rapidan respondon. La gvidanto atendas ke la mesaĝo estu konservita per ĉiuj kopioj en la ISR.

Rizo. 13. ISR kun tri kopioj. Unu estas malrapida, rezultigante registradprokrastojn

Post kvar sekundoj da plia prokrasto, makleristo 2 sendas ack. Ĉiuj kopioj nun estas plene ĝisdatigitaj.

Rizo. 14. Ĉiuj kopioj konservas mesaĝojn kaj sendu ack

Makleristo 3 nun restas pli malantaŭe kaj estas forigita de la ISR. Latenteco estas signife reduktita ĉar ekzistas neniuj malrapidaj kopioj forlasitaj en la ISR. Makleristo 2 nun atendas nur makleristo 1, kaj li havas averaĝan malfruon de 500 ms.

Rizo. 15. La kopio sur makleristo 3 estas forigita de la ISR

Tiam makleristo 2 falas kaj gvidado pasas al makleristo 1 sen perdo de mesaĝoj.

Rizo. 16. Makleristo 2 falas

La fabrikanto trovas novan gvidanton kaj komencas sendi mesaĝojn al li. La latenteco estas plu reduktita ĉar la ISR nun konsistas el unu kopio! Tial la opcio acks=all ne aldonas redundon.

Rizo. 17. Repliko sur makleristo 1 prenas la gvidon sen perdi mesaĝojn

Tiam makleristo 1 kraŝas kaj la antaŭeco iras al makleristo 3 kun perdo de 14238 mesaĝoj!

Rizo. 18. Makleristo 1 mortas kaj gvida transiro kun malpura agordo rezultigas ampleksan perdon de datumoj

Ni ne povis instali la opcion malpura.gvidanto.elekto.ebligi en signifon veraj. Defaŭlte ĝi estas egala falsa. Agordoj acks=all с unclean.leader.election.enable=vera provizas alireblecon kun iom da plia datumsekureco. Sed kiel vi povas vidi, ni ankoraŭ povas perdi mesaĝojn.

Sed kio se ni volas pliigi la sekurecon de datumoj? Vi povas meti unclean.leader.election.enable = malvera, sed ĉi tio ne nepre protektos nin kontraŭ datumperdo. Se la gvidanto forte falis kaj kunportis la datumojn, tiam mesaĝoj ankoraŭ perdiĝas, kaj la havebleco perdiĝas ĝis la administranto restarigas la situacion.

Pli bone estas certigi, ke ĉiuj mesaĝoj estas superfluaj, kaj alie forĵeti la registradon. Tiam, almenaŭ el la vidpunkto de la makleristo, perdo de datumoj nur eblas en la okazo de du aŭ pli samtempaj fiaskoj.

Acks=all, min.insync.replicas kaj ISR

Kun temo-agordo min.insync.replicas Ni pliigas la nivelon de sekureco de datumoj. Ni trairu la lastan parton de la antaŭa scenaro denove, sed ĉi-foje kun min.insync.replicas=2.

Do makleristo 2 havas kopian gvidanton kaj la sekvanto sur makleristo 3 estas forigita de la ISR.

Rizo. 19. ISR el du kopioj

Makleristo 2 falas kaj gvidado pasas al makleristo 1 sen perdo de mesaĝoj. Sed nun la ISR konsistas el nur unu kopio. Ĉi tio ne renkontas la minimuman nombron por ricevi rekordojn, kaj tial la makleristo respondas al la skribprovo per eraro NotEnoughReplicas.

Rizo. 20. La nombro da ISR-oj estas unu pli malalta ol specifita en min.insync.replicas

Ĉi tiu agordo oferas haveblecon por konsistenco. Antaŭ ol agnoski mesaĝon, ni certigas, ke ĝi estas skribita al almenaŭ du kopioj. Ĉi tio donas al la fabrikanto multe pli da fido. Ĉi tie, mesaĝperdo estas nur ebla se du kopioj malsukcesas samtempe en mallonga intervalo ĝis la mesaĝo estas reproduktita al plia sekvanto, kio estas neverŝajna. Sed se vi estas super paranoja, vi povas agordi la reproduktan faktoron al 5, kaj min.insync.replicas per 3. Ĉi tie tri makleristoj devas fali samtempe por perdi la rekordon! Kompreneble, vi pagas por ĉi tiu fidindeco en plia latenteco.

Kiam alirebleco estas necesa por sekureco de datumoj

Kiel en kazo kun RabbitMQ, foje alirebleco estas necesa por sekureco de datumoj. Jen kion vi devas pensi pri:

• Ĉu la eldonisto povas simple resendi eraron kaj havi la kontraŭfluan servon aŭ uzanton provi denove poste?
• Ĉu la eldonisto povas konservi la mesaĝon loke aŭ en datumbazo por provi denove poste?

Se la respondo estas ne, tiam optimumigi haveblecon plibonigas datumsekurecon. Vi perdos malpli da datumoj se vi elektas haveblecon anstataŭ ne registri. Tiel, ĉio estas trovi ekvilibron, kaj la decido dependas de la specifa situacio.

La signifo de ISR

La ISR-suito permesas al vi elekti la optimuman ekvilibron inter datumsekureco kaj latenteco. Ekzemple, certigu haveblecon en la okazo de fiasko de la plimulto de kopioj, minimumigante la efikon de mortintaj aŭ malrapidaj kopioj laŭ latenteco.

Ni mem elektas la signifon replica.lag.time.max.ms laŭ viaj bezonoj. Esence, ĉi tiu parametro signifas kiom da prokrasto ni pretas akcepti kiam acks=all. La defaŭlta valoro estas dek sekundoj. Se ĉi tio estas tro longa por vi, vi povas redukti ĝin. Tiam la ofteco de ŝanĝoj en la ISR pliiĝos, ĉar sekvantoj estos forigitaj kaj aldonitaj pli ofte.

RabbitMQ estas simple aro de speguloj, kiuj devas esti reproduktitaj. Malrapidaj speguloj enkondukas plian latentecon, kaj mortaj speguloj povas atendi ĝis la pakaĵetoj, kiuj kontrolas la haveblecon de ĉiu nodo (reta tiktako) por respondi. ISR estas interesa maniero eviti ĉi tiujn problemojn pri latenteco. Sed ni riskas perdi redundon ĉar la ISR povas nur ŝrumpi al la gvidanto. Por eviti ĉi tiun riskon, uzu la agordon min.insync.replicas.

Garantio pri kliento-konekto

En la agordoj bootstrap.serviloj produktanto kaj konsumanto povas specifi plurajn makleristojn por ligado de klientoj. La ideo estas, ke kiam unu nodo malleviĝas, restas pluraj rezervaj, per kiuj la kliento povas malfermi konekton. Ĉi tiuj ne nepre estas sekciestroj, sed simple saltotabulo por komenca ŝarĝo. La kliento povas demandi al ili, kiu nodo gastigas la lego-/skriban sekciogvidanton.

En RabbitMQ, klientoj povas konektiĝi al iu ajn nodo, kaj interna vojigo sendas la peton al kie ĝi devas iri. Ĉi tio signifas, ke vi povas instali ŝarĝbalancilon antaŭ RabbitMQ. Kafka postulas klientojn konekti al la nodo kiu gastigas la respondan sekciogvidanton. En tia situacio, vi ne povas instali ŝarĝbalancilon. Listo bootstrap.serviloj Estas kritike, ke klientoj povas aliri kaj trovi la ĝustajn nodojn post fiasko.

Kafka Interkonsenta Arkitekturo

Ĝis nun, ni ne konsideris kiel la areto lernas pri la falo de la makleristo kaj kiel nova gvidanto estas elektita. Por kompreni kiel Kafka funkcias kun retaj sekcioj, vi unue devas kompreni la konsentan arkitekturon.

Ĉiu Kafka-areto estas deplojita kune kun Zookeeper-areto, kio estas distribuita interkonsentservo kiu permesas al la sistemo atingi interkonsenton pri iu antaŭfiksita ŝtato, prioritatante konsistencon super havebleco. La konsento de plimulto de Zookeeper-nodoj estas postulata por aprobi legi kaj skribi operaciojn.

Zookeeper stokas la staton de la areto:

• Listo de temoj, sekcioj, agordo, nunaj gvidaj kopioj, preferataj kopioj.
• Aretmembroj. Ĉiu makleristo pingas la Zookeeper-areton. Se ĝi ne ricevas pingon ene de difinita tempodaŭro, tiam Zookeeper registras la makleriston kiel neatingebla.
• Elektante la ĉefajn kaj rezervajn nodojn por la regilo.

La regila nodo estas unu el la Kafka makleristoj, kiu respondecas pri elektado de kopiaj gvidantoj. Zookeeper sendas sciigojn al la regilo pri aretmembreco kaj temoŝanĝoj, kaj la regilo devas agi pri tiuj ŝanĝoj.

Ekzemple, ni prenu novan temon kun dek sekcioj kaj reproduktadfaktoro de 3. La regilo devas elekti gvidanton por ĉiu sekcio, provante optimume distribui gvidantojn inter la makleristoj.

Por ĉiu sekcia regilo:

• ĝisdatigas informojn en Zookeeper pri ISR ​​kaj gvidanto;
• Sendas LeaderAndISRCommand al ĉiu makleristo kiu gastigas kopion de ĉi tiu sekcio, informante la makleristojn pri la ISR kaj la gvidanto.

Kiam makleristo kun gvidanto falas, Zookeeper sendas sciigon al la regilo, kaj ĝi elektas novan gvidanton. Denove, la regilo unue ĝisdatigas Zookeeper kaj poste sendas komandon al ĉiu makleristo sciigante ilin pri la gvida ŝanĝo.

Ĉiu gvidanto respondecas pri rekrutado de ISRoj. Agordoj replica.lag.time.max.ms determinas kiu eniros tien. Kiam la ISR ŝanĝiĝas, la gvidanto elsendas novajn informojn al Zookeeper.

Zookeeper ĉiam estas informita pri ajnaj ŝanĝoj tiel ke en kazo de malsukceso, administrado transiras glate al nova gvidanto.

Rizo. 21. Kafka Interkonsento

Replika protokolo

Kompreni la detalojn de reproduktado helpas vin pli bone kompreni eblajn datumajn perdojn.

Specimendemandoj, Log End Offset (LEO) kaj Highwater Mark (HW)

Ni konsideris, ke adeptoj periode sendas alportpetojn al la gvidanto. La defaŭlta intervalo estas 500ms. Tio devias de RabbitMQ en tio en RabbitMQ reproduktado ne estas iniciatita per la atendovicspegulo sed de la majstro. La majstro puŝas ŝanĝojn al la speguloj.

La gvidanto kaj ĉiuj sekvantoj konservas la Log End Offset (LEO) kaj la Highwater (HW) etikedon. La LEO-marko konservas la ofseton de la lasta mesaĝo en la loka kopio, kaj la HW tenas la ofseton de la lasta transdono. Memoru, ke por commit statuso, la mesaĝo devas esti daŭrigita tra ĉiuj ISR-kopioj. Ĉi tio signifas, ke LEO estas kutime iomete antaŭ HW.

Kiam la gvidanto ricevas mesaĝon, ĝi konservas ĝin loke. La sekvanto faras aĉetpeton transdonante sian LEO. La gvidanto tiam sendas aron da mesaĝoj komencante de ĉi tiu LEO kaj ankaŭ transdonas la nunan HW. Kiam la gvidanto ricevas informojn, ke ĉiuj kopioj konservis la mesaĝon ĉe la donita ofseto, ĝi movas la HW-markon. Nur la gvidanto povas movi la HW, kaj do ĉiuj sekvantoj scios la nunan valoron en la respondoj al sia peto. Ĉi tio signifas, ke sekvantoj povas postresti la gvidanton en kaj mesaĝo kaj HW-scio. Konsumantoj ricevas mesaĝojn nur ĝis la nuna HW.

Notu ke "persis" signifas skribita al memoro, ne al disko. Por efikeco, Kafka sinkronigas al disko je specifa intervalo. RabbitMQ ankaŭ havas tian intervalon, sed ĝi sendos agnoskon al la eldonisto nur post kiam la majstro kaj ĉiuj speguloj skribis la mesaĝon al disko. La programistoj de Kafka, pro agado-kialoj, decidis sendi ackon tuj kiam la mesaĝo estas skribita al memoro. Kafka vetas ke redundo kompensas la riskon de mallonge konservi agnoskitajn mesaĝojn nur en memoro.

Gvidanto fiasko

Kiam gvidanto falas, Zookeeper sciigas la regilon, kaj ĝi elektas novan ĉefkopion. La nova gvidanto metas novan HW-markon laŭ sia LEO. Sekvantoj tiam ricevas informojn pri la nova gvidanto. Depende de la versio de Kafka, la sekvanto elektos unu el du scenaroj:

1. Ĝi detranĉos la lokan protokolon al konata HW kaj sendos peton al la nova gvidanto por mesaĝoj post ĉi tiu marko.
2. Sendos peton al la gvidanto por ekscii la HW en la tempo kiam li estis elektita gvidanto, kaj tiam detranĉos la protokolon al ĉi tiu ofseto. Ĝi tiam komencos fari periodajn preni petojn ekde ĉi tiu ofseto.

Sekvanto eble bezonos detranĉi la protokolon pro la sekvaj kialoj:

• Kiam gvidanto malsukcesas, la unua ano en la ISR-aro registrita kun Zookeeper venkas en la elekto kaj iĝas la gvidanto. Ĉiuj sekvantoj en ISR, kvankam konsiderataj "sinkronigitaj", eble ne ricevis kopiojn de ĉiuj mesaĝoj de la antaŭa gvidanto. Estas tute eble, ke la elstara sekvanto ne havas la plej ĝisdatigitan kopion. Kafka certigas, ke ne ekzistas diverĝo inter kopioj. Tiel, por eviti diferencojn, ĉiu sekvanto devas detranĉi sian protokolon al la HW-valoro de la nova gvidanto en la momento de sia elekto. Ĉi tio estas alia kialo kial fikso acks=all tiom grava por konsistenco.
• Mesaĝoj estas periode skribitaj al disko. Se ĉiuj grapolnodoj malsukcesas samtempe, tiam kopioj kun malsamaj ofsetoj estos stokitaj sur la diskoj. Eblas, ke kiam makleristoj revenas interrete, la nova gvidanto, kiu estas elektita, estos malantaŭ siaj sekvantoj ĉar li estis konservita al disko antaŭ la aliaj.

Reunuiĝo kun la areto

Dum rekuniĝo al la areto, la kopioj faras same kiel kiam gvidanto malsukcesas: ili kontrolas la kopion de la gvidanto kaj detranĉas sian tagalon al ĝia HW (dum elekto). Kompare, RabbitMQ egale traktas reunuigitajn nodojn kiel tute novajn. En ambaŭ kazoj, la makleristo forĵetas ajnan ekzistantan ŝtaton. Se aŭtomata sinkronigo estas uzata, tiam la majstro devas reprodukti absolute la tutan aktualan enhavon al la nova spegulo en metodo "lasi la tutan mondon atendi". La majstro ne akceptas ajnajn legajn aŭ skribajn operaciojn dum ĉi tiu operacio. Ĉi tiu aliro kreas problemojn en grandaj atendovicoj.

Kafka estas distribuita protokolo, kaj ĝenerale ĝi stokas pli da mesaĝoj ol RabbitMQ-vico, kie datumoj estas forigitaj de la atendovico post kiam ĝi estas legita. Aktivaj vostoj devus resti relative malgrandaj. Sed Kafka estas ŝtipo kun propra retenpolitiko, kiu povas agordi periodon de tagoj aŭ semajnoj. La atendovicblokado kaj plena sinkroniga aliro estas absolute neakcepteblaj por distribuita protokolo. Anstataŭe, Kafka-anoj simple detranĉas sian tagalon al la HW de la gvidanto (dum lia elekto) se ilia kopio estas antaŭ la gvidanto. En la pli verŝajna kazo, kiam la sekvanto estas malantaŭe, ĝi simple komencas fari preni petojn komencante kun sia nuna LEO.

Novaj aŭ aliĝintaj sekvantoj komenciĝas ekster la ISR kaj ne partoprenas en komitoj. Ili simple laboras kune kun la grupo, ricevante mesaĝojn kiel eble plej rapide ĝis ili atingas la gvidanton kaj eniras la ISR. Ne estas blokado kaj ne necesas forĵeti ĉiujn viajn datumojn.

Perdo de konektebleco

Kafka havas pli da komponentoj ol RabbitMQ, do ĝi havas pli kompleksan aron de kondutoj kiam la areto malkonektiĝas. Sed Kafka estis origine desegnita por aretoj, do la solvoj estas tre bone pripensitaj.

Malsupre estas pluraj scenaroj de fiasko de konektebleco:

• Scenaro 1: La sekvanto ne vidas la gvidanton, sed ankoraŭ vidas la Zookeeper.
• Scenaro 2: La gvidanto ne vidas iujn sekvantojn, sed ankoraŭ vidas Zookeeper.
• Scenaro 3: La sekvanto vidas la gvidanton, sed ne vidas la Zookeeper.
• Scenaro 4: La gvidanto vidas la anojn, sed ne vidas la Zookeeper.
• Scenaro 5: La sekvanto estas tute aparta de ambaŭ aliaj Kafkaj nodoj kaj Zookeeper.
• Scenaro 6: La gvidanto estas tute aparta de kaj aliaj Kafkaj nodoj kaj Zookeeper.
• Scenaro 7: La Kafka regilo nodo ne povas vidi alian Kafka nodo.
• Scenaro 8: Kafka regilo ne vidas Zookeeper.

Ĉiu scenaro havas sian propran konduton.

Scenaro 1: Sekvanto ne vidas la gvidanton, sed ankoraŭ vidas Zookeeper

Rizo. 22. Scenaro 1: ISR de tri kopioj

La konektebleco disigas makleriston 3 de makleristoj 1 kaj 2, sed ne de Zookeeper. Makleristo 3 ne plu povas sendi preni petojn. Post kiam la tempo pasis replica.lag.time.max.ms ĝi estas forigita de la ISR kaj ne partoprenas en mesaĝkomisioj. Post kiam konektebleco estas restarigita, ĝi rekomencos preni petojn kaj aliĝos al la ISR kiam ĝi renkontos la gvidanton. Zookeeper daŭre ricevos ping-ojn kaj supozos, ke la makleristo vivas kaj bone.

Rizo. 23. Scenaro 1: La makleristo estas forigita de la ISR se neniu preni peton estas ricevita de ĝi ene de la replica.lag.time.max.ms intervalo

Ne ekzistas disig-cerba aŭ noda suspendo kiel en RabbitMQ. Anstataŭe, redundo estas reduktita.

Scenaro 2: Gvidanto ne vidas iujn sekvantojn, sed ankoraŭ vidas Zookeeper

Rizo. 24. Scenaro 2. Gvidanto kaj du sekvantoj

Malsukceso en reto-konekto apartigas la gvidanton de la sekvantoj, sed la makleristo ankoraŭ povas vidi Zookeeper. Kiel en la unua scenaro, la ISR ŝrumpas, sed ĉi-foje nur al la gvidanto ĉar ĉiuj sekvantoj ĉesas sendi preni petojn. Denove, ne ekzistas logika divido. Anstataŭe, estas perdo de redundo por novaj mesaĝoj ĝis konektebleco estas restarigita. Zookeeper daŭre ricevas ping-ojn kaj kredas ke la makleristo vivas kaj bone.

Rizo. 25. Scenaro 2. ISR ŝrumpis nur al la gvidanto

Scenaro 3. Sekvanto vidas la gvidanton, sed ne vidas la Zookeeper

La sekvanto estas apartigita de Zookeeper, sed ne de la makleristo kun la gvidanto. Kiel rezulto, la sekvanto daŭre faras preni petojn kaj estas membro de la ISR. Zookeeper ne plu ricevas ping-ojn kaj registras broker-kraŝon, sed ĉar ĝi estas nur sekvanto, ne estas sekvoj post reakiro.

Rizo. 26. Scenaro 3: La sekvanto daŭre sendas preni petojn al la gvidanto

Scenaro 4. Gvidanto vidas sekvantojn, sed ne vidas Zookeeper

Rizo. 27. Scenaro 4. Gvidanto kaj du sekvantoj

La gvidanto estas apartigita de Zookeeper, sed ne de la makleristoj kun sekvantoj.

Rizo. 28. Scenaro 4: Gvidanto izolita de Zookeeper

Post iom da tempo, Zookeeper registros malsukceson de makleristo kaj sciigos la regilon pri ĝi. Li elektos novan gvidanton inter siaj sekvantoj. Tamen, la origina gvidanto daŭre pensos, ke ĝi estas la gvidanto kaj daŭre akceptos enskribojn de akoj=1. Partianoj ne plu sendas al li petojn por preni al li, do li konsideros ilin mortaj kaj provos ŝrumpi la ISR al si mem. Sed ĉar ĝi ne havas konekton al Zookeeper, ĝi ne povos fari tion, kaj tiam rifuzos akcepti pliajn enskribojn.

mesaĝojn acks=all ne ricevos agnoskon ĉar la ISR unue enŝaltas ĉiujn kopiojn, kaj mesaĝoj ne atingas ilin. Kiam la origina gvidanto provos forigi ilin de la ISR, ĝi ne povos fari tion kaj ĉesos akcepti ajnajn mesaĝojn entute.

Klientoj baldaŭ rimarkas la ŝanĝon en gvidanto kaj komencas sendi rekordojn al la nova servilo. Post kiam la reto estas restarigita, la origina gvidanto vidas ke ĝi ne plu estas gvidanto kaj stumpigas sian tagalon al la HW-valoro kiun la nova gvidanto havis dum malsukceso eviti tagalan diverĝon. Ĝi tiam komencos sendi preni petojn al la nova gvidanto. Ĉiuj rekordoj de la origina gvidanto kiuj ne estas reproduktitaj al la nova gvidanto estas perditaj. Tio estas, mesaĝoj kiuj ne estis agnoskitaj de la origina gvidanto en tiuj malmultaj sekundoj kiam du gvidantoj laboris, estos perditaj.

Rizo. 29. Scenaro 4. La gvidanto sur makleristo 1 iĝas sekvanto post kiam la reto estas restarigita

Scenaro 5: La sekvanto estas tute aparta de ambaŭ aliaj Kafkaj nodoj kaj Zookeeper

La sekvanto estas tute izolita de kaj aliaj Kafkaj nodoj kaj Zookeeper. Li simple forigas sin de la ISR ĝis la reto estas reestigita, kaj tiam atingas la aliajn.

Rizo. 30. Scenaro 5: Izolita sekvanto estas forigita de ISR

Scenaro 6: La gvidanto estas tute aparta de kaj aliaj Kafkaj nodoj kaj Zookeeper

Rizo. 31. Scenaro 6. Gvidanto kaj du sekvantoj

La gvidanto estas tute izolita de siaj sekvantoj, la regilo kaj Zookeeper. Por mallonga periodo ĝi daŭre akceptos enskribojn de akoj=1.

Rizo. 32. Scenaro 6: Izolante la gvidanton de aliaj Kafka kaj Zookeeper nodoj

Ne ricevinte petojn post eksvalidiĝo replica.lag.time.max.ms, ĝi provos ŝrumpi la ISR al si, sed ne povos fari tion ĉar ne ekzistas komunikado kun Zookeeper, tiam ĝi ĉesos akcepti skribojn.

Dume, Zookeeper markos la izolitan makleriston kiel mortinta kaj la regilo elektos novan gvidanton.

Rizo. 33. Scenaro 6. Du gvidantoj

La origina gvidanto povas akcepti enskribojn dum kelkaj sekundoj, sed poste ĉesas akcepti ajnajn mesaĝojn. Klientoj estas ĝisdatigitaj ĉiujn 60 sekundojn kun la plej novaj metadatenoj. Ili estos informitaj pri la gvidanto-ŝanĝo kaj komencos sendi enskribojn al la nova gvidanto.

Rizo. 34. Scenaro 6: Fabrikistoj ŝanĝas al nova gvidanto

Ĉiuj konfirmitaj enskriboj faritaj de la origina gvidanto ekde la perdo de konektebleco estos perditaj. Post kiam la reto estas restarigita, la origina gvidanto malkovros per Zookeeper ke ĝi ne plu estas la gvidanto. Tiam ĝi detranĉos sian protokolon al la HW de la nova gvidanto en la momento de la elekto kaj komencos sendi petojn kiel sekvanto.

Rizo. 35. Scenaro 6: La originala gvidanto fariĝas sekvanto post kiam reto-konekto estas restarigita

En ĉi tiu situacio, logika disiĝo povas okazi por mallonga periodo, sed nur se akoj=1 и min.insync.replicas ankaŭ 1. Logika disiĝo aŭtomate finiĝas aŭ post kiam la reto estas restarigita, kiam la origina gvidanto rimarkas, ke li ne plu estas la gvidanto, aŭ kiam ĉiuj klientoj rimarkas, ke la gvidanto ŝanĝiĝis kaj komencas skribi al la nova gvidanto - kio okazas unue. Ĉiukaze, iuj mesaĝoj estos perditaj, sed nur kun akoj=1.

Estas alia varianto de ĉi tiu scenaro kie, ĵus antaŭ la reto disiĝo, la sekvantoj malfruis kaj la gvidanto kunpremis la ISR al si mem. Ĝi tiam iĝas izolita pro perdo de konektebleco. Nova gvidanto estas elektita, sed la origina gvidanto daŭre akceptas eniĝojn, eĉ acks=all, ĉar estas neniu alia en ISR krom li. Ĉi tiuj rekordoj estos perditaj post kiam la reto estos restarigita. La sola maniero eviti ĉi tiun opcion estas min.insync.replicas = 2.

Scenaro 7: Kafka Controller Node Ne Povas Vidi Alian Kafkan Nodon

Ĝenerale, post kiam la konekto kun Kafka nodo estas perdita, la regilo ne povos transdoni ajnan gvidan ŝanĝinformon al ĝi. En la plej malbona kazo, ĉi tio kondukos al mallongdaŭra logika disiĝo, kiel en scenaro 6. Pli ofte ol ne, la makleristo simple ne fariĝos kandidato por gvidado se ĉi-lasta malsukcesos.

Scenaro 8: Kafka regilo ne vidas Zookeeper

Zookeeper ne ricevos pingon de la falinta regilo kaj elektos novan Kafkan nodon kiel la regilon. La origina regilo povas daŭre prezenti sin kiel tia, sed ĝi ne ricevas sciigojn de Zookeeper, do ĝi ne havos taskojn por plenumi. Post kiam la reto estas restarigita, li rimarkos, ke li ne plu estas regilo, sed fariĝis regula Kafka nodo.

Konkludoj el la scenaroj

Ni vidas, ke la perdo de sekvanto-konektebleco ne rezultigas mesaĝon perdon, sed simple provizore reduktas redundon ĝis la reto estas restarigita. Ĉi tio, kompreneble, povas konduki al datumperdo se unu aŭ pluraj nodoj estas perditaj.

Se la gvidanto disiĝas de Zookeeper pro perdo de konektebleco, tio povus rezultigi mesaĝojn perdantaj de akoj=1. Manko de komunikado kun Zookeeper kaŭzas mallongan logikan disigon kun la du gvidantoj. Ĉi tiu problemo estas solvita per la parametro acks=all.

Parametro min.insync.replicas en du aŭ pli da kopioj provizas plian certigon, ke tiaj mallongperspektivaj scenaroj ne rezultigos perditajn mesaĝojn kiel en Scenaro 6.

Resumo de Perditaj Mesaĝoj

Ni listigu ĉiujn manierojn kiel vi povas perdi datumojn en Kafka:

• Ajna gvidanto fiasko se mesaĝoj estis konfirmitaj uzante akoj=1
• Ajna malpura transiro de gvidado, tio estas, al sekvanto ekster la ISR, eĉ kun acks=all
• Izolante la gvidanton de Zookeeper se mesaĝoj estis konfirmitaj uzante akoj=1
• Kompleta izoliteco de la gvidanto, kiu jam ŝrumpis la ISR-grupon al si mem. Ĉiuj mesaĝoj estos perditaj, eĉ acks=all. Ĉi tio estas nur vera se min.insync.replicas=1.
• Samtempaj fiaskoj de ĉiuj dispartigaj nodoj. Ĉar mesaĝoj estas agnoskitaj de memoro, iuj eble ankoraŭ ne estas skribitaj al disko. Post rekomenco de la serviloj, iuj mesaĝoj eble mankas.

Malpuraj gvidaj transiroj povas esti evititaj aŭ malpermesante ilin aŭ certigante almenaŭ du redundojn. La plej daŭrema agordo estas kombinaĵo acks=all и min.insync.replicas pli ol 1.

Rekta komparo de la fidindeco de RabbitMQ kaj Kafka

Por certigi fidindecon kaj altan haveblecon, ambaŭ platformoj efektivigas primaran kaj sekundaran reproduktadsistemon. Tamen, RabbitMQ havas Aĥilan kalkanon. Rekonektante post malsukceso, nodoj forĵetas siajn datumojn kaj sinkronigado estas blokita. Ĉi tiu duobla frapo pridubas la longvivecon de grandaj atendovicoj en RabbitMQ. Vi devos akcepti aŭ reduktitan redundon aŭ longajn bloktempojn. Redukti redundon pliigas la riskon de amasa datumperdo. Sed se la atendovicoj estas malgrandaj, tiam pro redundo, mallongaj periodoj de nehavebleco (kelkaj sekundoj) povas esti traktitaj uzante ripetajn konektajn provojn.

Kafka ne havas ĉi tiun problemon. Ĝi forĵetas datumojn nur de la punkto de diverĝo inter la gvidanto kaj la sekvanto. Ĉiuj komunaj datumoj estas konservitaj. Krome, reproduktado ne blokas la sistemon. La gvidanto daŭre akceptas afiŝojn dum la nova sekvanto atingas, do por devopoj, aliĝi aŭ aliĝi al la areto fariĝas bagatela tasko. Kompreneble, ankoraŭ ekzistas problemoj kiel reta bendolarĝo dum reproduktado. Se vi aldonas plurajn sekvantojn samtempe, vi eble renkontos larĝan limon.

RabbitMQ estas pli alta ol Kafka en fidindeco kiam pluraj serviloj en areto malsukcesas samtempe. Kiel ni jam diris, RabbitMQ sendas konfirmon al la eldonisto nur post kiam la mesaĝo estas skribita al disko de la majstro kaj ĉiuj speguloj. Sed ĉi tio aldonas plian latentecon pro du kialoj:

• fsync ĉiujn kelkcent milisekundojn
• La fiasko de la spegulo povas esti rimarkita nur post kiam la vivdaŭro de la pakaĵetoj kiuj kontrolas la haveblecon de ĉiu nodo (net tick) eksvalidiĝis. Se la spegulo malrapidiĝas aŭ falas, tio aldonas malfruon.

La veto de Kafka estas, ke se mesaĝo estas konservita trans pluraj nodoj, ĝi povas agnoski mesaĝojn tuj kiam ili trafos memoron. Pro tio, ekzistas risko perdi mesaĝojn de ajna tipo (eĉ acks=all, min.insync.replicas=2) en kazo de samtempa fiasko.

Ĝenerale, Kafka elmontras pli bonan programaran efikecon kaj estas dizajnita de la grundo por aretoj. La nombro da sekvantoj povas esti pliigita al 11 se necese por fidindeco. Reproduktadfaktoro 5 kaj minimuma nombro da kopioj en sinkronigado min.insync.replicas=3 faros mesaĝperdon tre malofta evento. Se via infrastrukturo povas subteni ĉi tiun reproduktan rilatumon kaj nivelon de redundo, tiam vi povas elekti ĉi tiun opcion.

RabbitMQ-grupo estas bona por malgrandaj atendovicoj. Sed eĉ malgrandaj atendovicoj povas kreski rapide kiam estas peza trafiko. Post kiam vicoj grandiĝos, vi devos fari malfacilajn elektojn inter havebleco kaj fidindeco. RabbitMQ-grupo estas plej taŭga por ne-tipaj situacioj kie la avantaĝoj de la fleksebleco de RabbitMQ superas iujn ajn malavantaĝojn de sia grupigo.

Unu antidoto al la vundebleco de RabbitMQ al grandaj atendovicoj estas disigi ilin en multajn pli malgrandajn vicojn. Se vi ne postulas kompletan mendon de la tuta vico, sed nur la koncernajn mesaĝojn (ekzemple mesaĝojn de specifa kliento), aŭ tute nenion mendas, tiam ĉi tiu opcio estas akceptebla: rigardu mian projekton. Rebalancilo disigi la vicon (la projekto ankoraŭ estas en frua stadio).

Fine, ne forgesu pri kelkaj cimoj en la amasigaj kaj reproduktaj mekanismoj de kaj RabbitMQ kaj Kafka. Kun la tempo, sistemoj fariĝis pli maturaj kaj stabilaj, sed neniu mesaĝo iam estos 100% sekura kontraŭ perdo! Krome, grandskalaj akcidentoj okazas en datumcentroj!

Se mi maltrafis ion, faris eraron, aŭ vi malkonsentas pri iu ajn el la punktoj, bonvolu skribi komenton aŭ kontakti min.

Ofte oni demandas min: "Kion elekti, Kafka aŭ RabbitMQ?", "Kiu platformo estas pli bona?". La vero estas, ke ĝi vere dependas de via situacio, nuna sperto, ktp. Mi hezitas doni mian opinion ĉar estus tro tro simpligo rekomendi unu platformon por ĉiuj uzkazoj kaj eblaj limigoj. Mi skribis ĉi tiun serion de artikoloj por ke vi povu formi vian propran opinion.

Mi volas diri, ke ambaŭ sistemoj estas gvidantoj en ĉi tiu areo. Mi povas esti iom partia ĉar laŭ mia sperto kun projektoj mi emas taksi aferojn kiel garantiita mesaĝo mendado kaj fidindeco.

Mi vidas aliajn teknologiojn al kiuj mankas ĉi tiu fidindeco kaj garantiita mendo, tiam mi rigardas RabbitMQ kaj Kafka kaj rimarkas la nekredeblan valoron de ambaŭ ĉi tiuj sistemoj.

fonto: www.habr.com