В gotara dawî me li komkirina RabbitMQ ji bo tolerasyona xeletî û hebûna bilind nihêrî. Niha em li Apache Kafka kûr bikolin.

Li vir yekeya replikasyonê dabeşkirin e. Her mijar yek an jî çend beşan heye. Her beş serokek bi şagirt an bê şagirt heye. Dema ku mijarek diafirîne, hûn jimareya dabeşan û rêjeya dubarekirinê diyar dikin. Nirxa asayî 3 ye, ku tê wateya sê kopiyan: yek serok û du şopîner.

Birinc. 1. Çar beş di nav sê brokeran de têne belav kirin

Hemî daxwazên xwendin û nivîsandinê diçin cem rêber. Şagirt bi periyodîk daxwaz ji serok re dişînin da ku peyamên herî dawî bistînin. Xerîdar tu carî serî li şagirtan nadin, yên paşîn tenê ji bo zêdebûn û tolerasyona xeletiyê hene.

Têkçûna dabeşkirinê

Gava ku brokerek têk diçe, serokên çend beşan bi gelemperî têk diçin. Di her yek ji wan de, şopînerek ji nodek din dibe serok. Bi rastî, ev her gav ne wusa ye, ji ber ku faktora hevdengkirinê jî bandor dike: gelo şopînerên hevdemkirî hene, û heke na, wê hingê guheztina li kopiyek nesenkronîzekirî destûr e. Lê bila niha tiştan tevlihev nekin.

Broker 3 ji torê derdikeve, û serokê nû ji bo beşa 2 li broker 2 tê hilbijartin.

Birinc. 2. Broker 3 dimire û şopînerê wî li ser broker 2 wekî serokê nû yê dabeşkirina 2 tê hilbijartin

Dûv re broker 1 derdikeve û beşa 1 jî serokê xwe winda dike, ku rola wî derbasî broker 2 dibe.

Birinc. 3. Yek broker maye. Hemî rêber li ser yek brokerek bi zewaca sifir in

Dema ku broker 1 vegere serhêl, ew çar şagirtan lê zêde dike, ji her partîsiyonê re hin zêdebûnê peyda dike. Lê hemî rêber hîn jî li ser broker 2 man.

Birinc. 4. Rêber li ser broker 2 dimînin

Dema ku broker 3 tê, em vedigerin sê kopiyên her dabeşkirinê. Lê hemî serok hîn jî li ser broker 2 ne.

Birinc. 5. Cihkirina nehevseng a rêberan piştî sererastkirina brokerên 1 û 3

Kafka ji RabbitMQ re amûrek ji nûvehevsengkirina rêberê çêtir heye. Li wir, pêdivî bû ku hûn pêvek an nivîsarek sêyemîn bikar bînin ku polîtîkayên ji bo koçkirina girêka sereke bi kêmkirina zêdebûnê di dema koçberiyê de diguhezîne. Digel vê yekê, ji bo rêzên mezin me neçar ma ku di dema hevdengkirinê de nebûna qebûl bikin.

Kafka ji bo rola serkirdeyê xwedan têgîna "replîkên bijartî" ye. Dema ku dabeşên mijaran têne çêkirin, Kafka hewl dide ku rêberan bi rengek wekhev li ser nokan belav bike û wan serokên pêşîn wekî bijartî nîşan bide. Bi demê re, ji ber rebootkirina serverê, têkçûn, û têkçûnên pêwendiyê, dibe ku rêber bi dawî bibin li ser girêkên din, wekî ku di doza giran de li jor hatî destnîşan kirin.

Ji bo rastkirina vê, Kafka du vebijark pêşkêş dike:

Dibe auto.leader.rebalance.enable=true destûrê dide girêk kontrolker ku bixweber rêberan vegerîne kopiyên bijarte û bi vî rengî dabeşkirina yekreng sererast bike.
Rêvebir dikare skrîptê bimeşîne kafka-preferred-replica-election.sh ji bo veavakirina manual.

Birinc. 6. Replicas piştî rebalancing

Ev guhertoyek hêsan a têkçûnê bû, lê rastî tevlihevtir e, her çend li vir tiştek pir tevlihev tune. Ew hemî bi kopiyên hevdemkirî tê (In-Sync Replicas, ISR).

Bersivên hevdemkirî (ISR)

ISR komek kopiyên dabeşek e ku "hevdemkirî" (di-senkronîzekirî) tê hesibandin. Rêberek heye, lê dibe ku şopînerên wan tune bin. Ger ku berî ku navber biqede kopiyek rast ji hemî peyamên rêber çêkiribe, şagirtek hevdem tê hesibandin. replica.lag.time.max.ms.

Şagirtek ji set ISR tê derxistin heke:

daxwazek ji bo hilbijartina navberê nekir replica.lag.time.max.ms (tê texmînkirin ku mirî ye)
di navberê de nekarî nûve bike replica.lag.time.max.ms (hêdî tê hesibandin)

Şagirt di navberê de daxwazên nimûneyê dikin replica.fetch.wait.max.ms, ku ji bo 500ms veguherandin.

Ji bo ku bi zelalî armanca ISR rave bikin, pêdivî ye ku em li pejirandinên hilberîner û hin senaryoyên têkçûnê binêrin. Hilberîner dikarin gava ku broker piştrastkirinê dişîne hilbijêrin:

acks=0, tesdîq nehat şandin
acks=1, piştî ku rêber peyamek ji têketina xweya herêmî re nivîsand, piştrastkirin tê şandin
acks=hemû, piştî ku hemî kopiyên di ISR-ê de peyam ji têketinên herêmî re nivîsandin, pejirandin tê şandin.

Di termînolojiya Kafka de, heke ISR peyamek xilas kiribe, ew "pêkhatî" ye. Acks=hemû vebijarka herî ewledar e, lê di heman demê de derengiya zêde jî zêde dike. Ka em li du mînakên têkçûnê binêrin û ka vebijarkên cûda yên 'acks' çawa bi têgîna ISR re têkildar in.

Acks=1 û ISR

Di vê nimûneyê de, em ê bibînin ku ger serok li bendê nemîne ku her peyamek ji hemî şagirtan were hilanîn, wê hingê windabûna daneyê gengaz e ku rêber têk bibe. Navîgasyon li şopînerek nesenkronîzekirî dikare bi mîhengê ve were çalak kirin an neçalak kirin nepaqij.leader.election.enable.

Di vê nimûneyê de, çêker nirxa acks=1 heye. Beş li her sê brokeran tê belav kirin. Broker 3 li paş e, ew heşt saniye berê bi rêberê re hevdeng bû û naha 7456 peyam li paş e. Broker 1 tenê yek duyemîn li paş bû. Hilberînerê me peyamek dişîne û bi lez erêyek paşde distîne, bêyî serkêşiya şopînerên hêdî an mirî ku rêber li benda wan namîne.

Birinc. 7. ISR bi sê replicas

Broker 2 têk diçe û çêker xeletiyek pêwendiyê distîne. Piştî ku serokatî ji broker 1 re derbas dibe, em 123 peyaman winda dikin. Şagirtê li ser broker 1 beşek ji ISR bû, lê dema ku ew ket bi tevahî bi rêber re hevdeng nebû.

Birinc. 8. Peyam dema ku diqelişe winda dibin

Di veavakirinê de bootstrap.servers Hilberîner çend brokerên navnîşkirî hene û dikare ji brokerek din bipirse ka kî serokê beşê nû ye. Dûv re ew pêwendiyek bi broker 1 re saz dike û şandina peyaman didomîne.

Birinc. 9. Şandina peyaman piştî navbereke kurt ji nû ve dest pê dike

Broker 3 hê bêtir li paş e. Daxwazên hilgirtinê dike lê nikare hevdeng bike. Dibe ku ev ji ber girêdana torê ya hêdî ya di navbera brokeran de, pirsgirêka hilanînê, hwd. Ji ISR tê derxistin. Naha ISR ji yek replica pêk tê - rêber! Hilberîner şandina peyaman û wergirtina piştrastkirinê berdewam dike.

Birinc. 10. Şoperê li ser broker 3 ji ISR tê derxistin

Broker 1 dadikeve û rola serokatiyê diçe broker 3 bi windakirina 15286 peyaman! Hilberîner peyamek xeletiya girêdanê distîne. Veguheztina rêberek li derveyî ISR tenê ji ber mîhengê gengaz bû unclean.leader.election.enable=true. Ger ew tê de were saz kirin şaş, wê hingê veguheztin çênabe û dê hemî daxwazên xwendin û nivîsandinê werin red kirin. Di vê rewşê de, em li bendê ne ku broker 1 bi daneyên xwe yên bêkêmasî vegere kopiyek, ku dê dîsa serokatiyê bigire.

Birinc. 11. Broker 1 dikeve. Dema ku têkçûnek çêbibe, hejmareke mezin ji peyaman winda dibin

Hilberîner bi brokerê paşîn re têkiliyek saz dike û dibîne ku ew naha serokê beşê ye. Ew dest bi şandina peyaman ji broker 3 re dike.

Birinc. 12. Piştî navberek kurt, peyam ji bo beşa 0 dîsa têne şandin

Me dît ku, ji xeynî qutkirinên kurt ji bo damezrandina girêdanên nû û lêgerîna serokek nû, çêker bi domdarî peyaman dişand. Ev veavakirin hebûna li ser hesabê hevgirtinê (ewlehiya daneyê) misoger dike. Kafka bi hezaran peyam wenda kir, lê dîsa jî nivîsên nû qebûl kir.

Acks=hemû û ISR

Ka em vê senaryoyê dîsa dubare bikin, lê bi dike=hemû. Broker 3 xwedan derengiya navîn a çar saniyeyan e. Hilberîner pê re peyamek dişîne dike=hemû, û naha bersivek bilez nagire. Rêber li bendê ye ku peyam ji hêla hemî kopiyên di ISR ve were xilas kirin.

Birinc. 13. ISR bi sê replicas. Yek hêdî e, di encamê de dereng tomarkirinê

Piştî çar saniyeyên derengiya zêde, broker 2 ackek dişîne. Hemî replica niha bi tevahî nûve kirin.

Birinc. 14. Hemî replica peyaman tomar dikin û qebûl dikin

Broker 3 naha bêtir li paş dimîne û ji ISR tê derxistin. Dereng bi girîngî kêm dibe ji ber ku di ISR-ê de kopiyên hêdî nemane. Broker 2 naha tenê li benda broker 1-ê dimîne, û derengiya wî ya navînî 500 ms heye.

Birinc. 15. Replica li ser broker 3 ji ISR tê derxistin

Dûv re broker 2 dikeve û serokatî bêyî windakirina peyaman derbasî broker 1 dibe.

Birinc. 16. Broker 2 dikeve

Hilberîner serokek nû dibîne û dest bi şandina peyaman ji wî re dike. Dereng kêm dibe ji ber ku ISR naha ji yek kopiyek pêk tê! Ji ber vê yekê vebijêrk dike=hemû zêde zêde nake.

Birinc. 17. Replica li ser broker 1 bêyî windakirina peyaman pêşengiyê dike

Dûv re broker 1 têk diçe û pêşengî bi windakirina 3 peyaman diçe broker 14238!

Birinc. 18. Broker 1 dimire û veguheztina serokatiyê bi mîhengê nepak dibe sedema windabûna daneya berfireh

Me nikaribû vebijêrkê saz bikin nepaqij.leader.election.enable nav wateyê de rast. Ji hêla xwerû ve ew wekhev e şaş. Settings dike=hemû с unclean.leader.election.enable=true gihîştina hin ewlehiya daneya zêde peyda dike. Lê wekî ku hûn dibînin, em hîn jî dikarin peyaman winda bikin.

Lê heke em dixwazin ewlehiya daneyê zêde bikin? Hûn dikarin bixin unclean.leader.election.enable = derewîn, lê ev ê ne hewce ye ku me ji windabûna daneyê biparêze. Ger rêber bi dijwarî ket û daneyan bi xwe re girt, wê hingê peyam hîn jî winda dibin, plus hebûna wenda dibe heya ku rêveber rewşê sererast bike.

Çêtir e ku meriv pê ewle bibe ku hemî peyam zêde ne, û wekî din tomarê bavêjin. Dûv re, bi kêmanî ji nêrîna brokerê, windabûna daneyê tenê di bûyera du an jî zêdetir têkçûna hevdem de gengaz e.

Acks=hemû, min.insync.replicas û ISR

Bi veavakirina mijarê min.insync.replicas Em asta ewlehiya daneyê zêde dikin. Ka em dîsa beşa paşîn a senaryoya berê derbas bikin, lê vê carê bi min.insync.replicas=2.

Ji ber vê yekê broker 2 xwedan serokê replica ye û şopînerê li ser broker 3 ji ISR tê derxistin.

Birinc. 19. ISR ji du replicas

Broker 2 dikeve û serokatî bêyî windakirina peyaman derbasî broker 1 dibe. Lê niha ISR tenê ji yek replica pêk tê. Ev hejmara herî kêm a wergirtina tomaran nagire, û ji ber vê yekê broker bi xeletiyek bersivê dide hewldana nivîsandinê NotEnoughReplicas.

Birinc. 20. Hejmara ISRyan yek ji ya ku di min.insync.replicas de hatî destnîşan kirin kêmtir e

Ev veavakirin hebûna xwe ji bo hevgirtinê dike qurban. Berî pejirandina peyamek, em piştrast dikin ku ew bi kêmî ve du kopiyan hatiye nivîsandin. Ev pêbaweriyek pir zêde dide hilberîner. Li vir, windabûna peyamê tenê mimkun e heke du replica bi hevdemî di navberek kurt de têk biçin heya ku peyam ji şagirtek din re were dubare kirin, ku ne mimkûn e. Lê heke hûn super paranoîd in, hûn dikarin faktora dubarekirinê li 5-ê destnîşan bikin, û min.insync.replicas bi 3. Li vir divê sê broker di heman demê de bikevin da ku qeydê winda bikin! Bê guman, hûn ji bo vê pêbaweriyê di derengiya zêde de didin.

Dema ku gihîştin ji bo ewlehiya daneyê hewce ye

Wekî ku di doza bi RabbitMQ, carinan gihîştin ji bo ewlehiya daneyê hewce ye. Li vir tiştê ku hûn hewce ne ku li ser bifikirin hene:

Ma weşanger tenê xeletiyek vegerîne û karûbarê jorîn an bikarhêner paşê dîsa biceribîne?
Ma weşanger dikare peyamê li herêmî an di databasek de hilîne da ku paşê dîsa biceribîne?

Ger bersiv na be, wê hingê xweşbînkirina hebûna ewlehiya daneyê baştir dike. Heke hûn li şûna ne tomarkirinê hebûna hilbijêrin hûn ê daneya hindik winda bikin. Bi vî rengî, ew hemî ji bo dîtina hevsengiyek tê, û biryar bi rewşa taybetî ve girêdayî ye.

Wateya ISR

Komek ISR dihêle hûn di navbera ewlehiya daneyê û derengiyê de hevsengiya çêtirîn hilbijêrin. Mînakî, di bûyera têkçûna piraniya kopiyan de hebûna peyda bikin, di warê derengbûnê de bandora kopiyên mirî an hêdî kêm bikin.

Em bi xwe wateyê hildibijêrin replica.lag.time.max.ms li gorî hewcedariyên we. Di bingeh de, ev parametre tê vê wateyê ku em amade ne kengê çiqas dereng bipejirînin dike=hemû. Nirxa xwerû deh saniye ye. Ger ev ji bo we pir dirêj be, hûn dikarin wê kêm bikin. Dûv re frekansa guhertinên di ISR-ê de dê zêde bibe, ji ber ku dê şopînerên pir caran werin rakirin û zêdekirin.

RabbitMQ bi tenê komek neynikên ku hewce ne ku bêne dubare kirin e. Neynikên hêdî hêdî derengmayînek zêde destnîşan dikin, û neynikên mirî dikarin li bendê bin heya ku pakêtên ku hebûna her girêkek (tikandina torê) kontrol dikin bisekinin ku bersivê bidin. ISR rêyek balkêş e ku meriv ji van pirsgirêkên derengbûnê dûr bixe. Lê em metirsiya windakirina zêdebûnê dikin ji ber ku ISR tenê dikare berbi serokê xwe ve bibe. Ji bo ku ji vê xetereyê dûr bixin, mîhengê bikar bînin min.insync.replicas.

Garantiya girêdana xerîdar

Di pergalê de bootstrap.servers hilberîner û xerîdar dikarin ji bo girêdana xerîdar gelek brokeran diyar bikin. Fikir ev e ku gava yek nodek dakeve, gelek yên yedek mane ku xerîdar bi wan re dikare têkiliyek veke. Ev ne hewce ne serokên beşê ne, lê tenê ji bo barkirina destpêkê rêgezek in. Xerîdar dikare ji wan bipirse ka kîjan node pêşengê dabeşkirina xwendin / nivîsandinê dike.

Di RabbitMQ de, xerîdar dikarin bi her girêkekê ve girêbidin, û rêça navxweyî daxwazê dişîne cihê ku ew hewce dike ku biçe. Ev tê vê wateyê ku hûn dikarin li ber RabbitMQ balansek barkirinê saz bikin. Kafka ji xerîdar hewce dike ku bi girêka ku pêşengê dabeşkirinê yê têkildar digire ve girêdin. Di rewşek weha de, hûn nekarin balansek barkirinê saz bikin. Rêzkirin bootstrap.servers Girîng e ku xerîdar piştî têkçûnekê bigihîjin girêkên rast û bibînin.

Mîmariya Lihevhatina Kafka

Heya nuha, me nehesiband ka kom çawa li ser hilweşîna broker fêr dibe û serokek nû çawa tê hilbijartin. Ji bo ku hûn fêm bikin ka Kafka çawa bi dabeşên torê re dixebite, pêşî hûn hewce ne ku mîmariya lihevhatinê fam bikin.

Her komek Kafka ligel komeke Zookeeper, ku karûbarek lihevhatinek belavkirî ye, ku destûrê dide pergalê ku li ser hin dewleta diyarkirî bigihîje lihevkirinê, pêşî li hevgirtinê digire li ser hebûna. Ji bo pejirandina xebatên xwendin û nivîsandinê razîbûna piraniya girêkên Zookeeper hewce ye.

Zookeeper rewşa komê hilîne:

Navnîşa mijaran, beşan, veavakirin, kopiyên rêberê heyî, kopiyên bijartî.
endamên Cluster. Her broker koma Zookeeper ping dike. Ger ew di nav demek diyarkirî de ping wernegire, wê hingê Zookeeper broker wekî ne berdest tomar dike.
Hilbijartina girêkên sereke û yedek ji bo kontrolker.

Girêk kontrolker yek ji brokerên Kafka ye ku ji hilbijartina serokên replica berpirsiyar e. Zookeeper di derbarê endametiya komê û guhertinên mijarê de agahdariyan ji kontrolker re dişîne, û divê kontrolker li ser van guhertinan tevbigere.

Mînakî, werin em mijarek nû bi deh dabeşan û faktorek dubarekirinê ya 3 bigirin. Divê kontrolker ji bo her dabeşkirinê serokek hilbijêre, hewl bide ku rêberan bi awayek çêtirîn di nav brokeran de belav bike.

Ji bo her kontrolkerê beşê:

agahdariya li Zookeeper di derbarê ISR û rêber de nûve dike;
LeaderAndISR Fermanek ji her brokerek re dişîne ku kopiyek vê dabeşkirinê digire, brokeran di derbarê ISR û rêber de agahdar dike.

Gava ku brokerek bi serokek dikeve, Zookeeper agahiyek ji kontrolker re dişîne, û ew serokek nû hildibijêre. Dîsa, kontrolker pêşî Zookeeper nûve dike û dûv re fermanek ji her broker re dişîne û wan ji guhertina serokatiyê agahdar dike.

Her serok berpirsiyar e ji bo peydakirina ISR. Settings replica.lag.time.max.ms diyar dike ku dê kî bikeve wir. Dema ku ISR diguhere, rêber agahdariya nû ji Zookeeper re dişîne.

Zookeeper her gav ji her guhertinan agahdar e da ku di bûyerek têkçûn de, rêveberî bi rêkûpêk derbasî serokek nû bibe.

Birinc. 21. Lihevhatina Kafka

Protokola Replication

Fêmkirina hûrguliyên dubarekirinê ji we re dibe alîkar ku hûn senaryoyên windabûna daneya potansiyel çêtir fam bikin.

Pirsên nimûneyê, Log End Offset (LEO) û Highwater Mark (HW)

Me fikir kir ku şagirt bi periyodîk daxwazên fethê ji rêber re dişînin. Navbera xwerû 500ms e. Ev ji RabbitMQ cûda dibe ku di RabbitMQ de dubarekirin ne ji hêla neynika rêzê lê ji hêla master ve tê destpêkirin. Mamoste guheztinan li neynikê dixe.

Rêber û hemî şagirtên Log End Offset (LEO) û etîketa Highwater (HW) xilas dikin. Nîşana LEO guheztina peyama paşîn di kopyaya herêmî de hilîne, û HW guheztina peywira paşîn digire. Bînin bîra xwe ku ji bo statûya peywirê, pêdivî ye ku peyam li hemî kopiyên ISR-ê were domandin. Ev tê vê wateyê ku LEO bi gelemperî hinekî li pêş HW ye.

Dema ku rêber peyamek distîne, ew wê li herêmî hilîne. Şagirt bi şandina LEO-ya xwe daxwazek hilgirtinê dike. Dûv re rêber komek peyaman ji vê LEO-yê dest pê dike û di heman demê de HW-ya heyî jî vediguhezîne. Dema ku rêber agahdarî distîne ku hemî kopyayan peyam li cîhê diyarkirî tomar kirine, ew nîşana HW dihejîne. Tenê rêber dikare HW bimeşîne, û ji ber vê yekê hemî şagirt dê nirxa heyî di bersivên daxwaza xwe de bizanibin. Ev tê vê wateyê ku şagirt dikarin hem di peyam û hem jî di zanîna HW de ji rêber paşde bimînin. Xerîdar tenê heya HW-ya heyî peyaman distînin.

Bala xwe bidinê ku "persisted" tê wateya ku li ser bîranînê hatî nivîsandin, ne li ser dîskê. Ji bo performansê, Kafka di navberek taybetî de bi dîskê re hevdeng dike. RabbitMQ jî navberek wusa heye, lê ew ê pejirandinek ji weşanger re bişîne tenê piştî ku master û hemî neynikên peyamê li ser dîskê binivîsin. Pêşdebirên Kafka, ji ber sedemên performansê, biryar dan ku gava ku peyam ji bîranînê re were nivîsandin, ackek bişînin. Kafka behîs dike ku zêdebûn rîska hilanîna bi kurtî peyamên pejirandî tenê di bîranînê de kêm dike.

Têkçûna rêber

Dema ku rêberek dikeve, Zookeeper kontrolker agahdar dike, û ew kopiyek serokê nû hildibijêre. Rêberê nû li gorî LEO-ya xwe nîşanek HW-ya nû destnîşan dike. Dûv re şagirt di derbarê serokê nû de agahdarî distînin. Li gorî guhertoya Kafka, şagirt dê yek ji du senaryoyan hilbijêrin:

Ew ê têketina herêmî li HW-ya naskirî qut bike û ji serokê nû re ji bo peyamên piştî vê nîşanê daxwazek bişîne.
Dê daxwazek ji serok re bişîne da ku HW-ê di dema ku ew wekî serok hate hilbijartin bibîne, û dûv re têketinê li ser vê yekê qut bike. Dûv re ew ê dest bi çêkirina daxwazên hilanîna periyodîk bike ku ji vê veqetandinê dest pê dike.

Dibe ku şagirtek hewce bike ku têketinê ji ber sedemên jêrîn qut bike:

Dema ku rêberek têk diçe, yekem şopînerê di koma ISR de ku bi Zookeeper re qeydkirî ye, di hilbijartinê de bi ser dikeve û dibe serok. Hemî şopînerên li ser ISR, her çend "bi hevdem" têne hesibandin, dibe ku kopiyên hemî peyaman ji serokê berê wernegirin. Bi tevahî gengaz e ku şopînerê diyarkirî kopiyek herî nûjen tune. Kafka piştrast dike ku di navbera replikayan de cûdahî tune. Bi vî rengî, ji bo ku ji nakokiyan dûr nekevin, divê her şagirt di dema hilbijartina wî de loga xwe ji nirxa HW ya serokê nû qut bike. Ev sedemek din e ku çima sazkirinê ye dike=hemû ji bo hevgirtinê pir girîng e.
Mesaj bi awayekî periyodîk li ser dîskê têne nivîsandin. Ger hemî girêkên komê di heman demê de bisernekevin, wê hingê kopiyên bi veqetandekên cûda dê li ser dîskan werin hilanîn. Mimkun e ku dema ku broker vegerin serhêl, serokê nû yê ku tê hilbijartin dê li pişt şagirtên xwe be ji ber ku ew berî yên din li dîskê hate xilas kirin.

Hevdîtina bi komê re

Dema ku ji nû ve tevlî komê dibin, replika heman tiştî dikin dema ku rêberek têk diçe: ew kopya rêber kontrol dikin û têketina xwe li HW-ya wê qut dikin (di dema hilbijartinê de). Di berhevdanê de, RabbitMQ bi heman rengî girêkên hevgirtî wekî bi tevahî nû derman dike. Di her du rewşan de, broker dewletek heyî ji holê radike. Ger hevdemkirina otomatîkî were bikar anîn, wê hingê pêdivî ye ku master bi rêbazek "bila hemî cîhan li bendê bimîne" bi tevahî naveroka heyî li neynika nû dubare bike. Mamoste di dema vê operasyonê de ti operasyonên xwendin û nivîsandinê qebûl nake. Ev nêzîkatî di dorên mezin de pirsgirêkan çêdike.

Kafka têketinek belavkirî ye û bi gelemperî ew ji rêzika RabbitMQ bêtir peyaman hildide, ku piştî xwendinê dane ji rêzê têne rakirin. Rêzên çalak divê nisbeten piçûk bimînin. Lê Kafka bi sîyaseta xwe ya ragirtinê têketinek e, ku dikare heyamek roj an hefteyan destnîşan bike. Astengkirina rêzê û nêzîkatiya hevdemkirinê ya tevahî ji bo têketinek belavkirî bi tevahî nayê qebûl kirin. Di şûna wê de, şagirtên Kafka bi tenê loga xwe ji HW-ya rêber (di dema hilbijartina wî de) qut dikin heke kopiya wan li pêş serok be. Di rewşek pirtir de, dema ku şopîner li paş be, ew bi LEO-ya xweya heyî dest pê dike bi tenê dest bi çêkirina daxwazên hilgirtinê dike.

Şagirtên nû yan jî yên ku ji nû ve tevlî bûne li derveyî ISR-ê dest pê dikin û beşdarî kiryaran nabin. Ew bi tenê li kêleka komê dixebitin, bi lez û bez peyaman distînin heya ku ew bi rêber re bigihîjin û têkevin ISR. Qefilandin tune û ne hewce ye ku hemî daneyên xwe bavêjin.

Wendabûna girêdanê

Kafka ji RabbitMQ bêtir pêkhateyên xwe hene, ji ber vê yekê dema ku kom ji hev qut dibe xwedan komek tevgerên tevlihevtir e. Lê Kafka bi eslê xwe ji bo koman hatiye çêkirin, ji ber vê yekê çareserî pir baş têne fikirîn.

Li jêr çend senaryoyên têkçûna girêdanê hene:

Senaryo 1: Şagirt rêber nabîne, lê dîsa jî Zookeeper dibîne.
Senaryo 2: Rêber tu şagirtan nabîne, lê dîsa jî Zookeeper dibîne.
Senaryo 3: Şagirt rêber dibîne, lê Zookeeper nabîne.
Senaryo 4: Rêber şagirtan dibîne, lê Zookeeper nabîne.
Senaryo 5: Şopdar bi tevahî ji her du girêkên Kafka yên din û ji Zookeeper cuda ye.
Senaryo 6: Rêber ji her du girêkên Kafka û Zookeeper bi tevahî veqetandî ye.
Senaryo 7: Girêk kontrolkerê Kafka nikare nodek Kafka din bibîne.
Senaryo 8: Kontrolkerê Kafka Zookeeper nabîne.

Her senaryo tevgerek xwe heye.

Senaryo 1: Şopdar rêber nabîne, lê dîsa jî Zookeeper dibîne

Birinc. 22. Senaryo 1: ISR ji sê replicas

Têkçûna pêwendiyê broker 3 ji brokerên 1 û 2 veqetîne, lê ne ji Zookeeper. Broker 3 êdî nikare daxwazên hilgirtinê bişîne. Piştî ku dem derbas bû replica.lag.time.max.ms ew ji ISR tê derxistin û beşdarî peywirên peyaman nabe. Dema ku girêdan ji nû ve were vegerandin, ew ê ji nû ve daxwazên hilanînê ji nû ve bide destpêkirin û gava ku ew bi rêber re bigihîje beşdarî ISR bibe. Zookeeper dê berdewamiya wergirtina pingan bike û texmîn bike ku broker sax û sax e.

Birinc. 23. Senaryo 1: Broker ji ISR tê derxistin heke di navbera replica.lag.time.max.ms de daxwazek jêgirtinê jê neyê wergirtin.

Mîna di RabbitMQ de sekinandina mejî an girêkek perçebûyî tune. Di şûna wê de, zêdebûn kêm dibe.

Senaryo 2: Rêber tu şagirtan nabîne, lê dîsa jî Zookeeper dibîne

Birinc. 24. Senaryo 2. Rêber û du peyrew

Dabeşbûnek di girêdana torê de rêber ji şagirtan vediqetîne, lê broker hîn jî dikare Zookeeper bibîne. Mîna ku di senaryoya yekem de, ISR piçûk dibe, lê vê carê tenê ji rêber re ji ber ku hemî şopîner şandina daxwazên hilanînê rawestînin. Dîsa, dabeşkirina mentiqî tune. Di şûna wê de, ji bo peyamên nû windabûna zêdebûnê heye heya ku pêwendî were nûve kirin. Zookeeper wergirtina pingan berdewam dike û bawer dike ku broker sax û sax e.

Birinc. 25. Senaryo 2. ISR tenê li ser rêber kêm bûye

Senaryo 3. Şopdar rêber dibîne, lê Zookeeper nabîne

Şagirt ji Zookeeper veqetandî ye, lê ne ji brokerê bi rêber re. Wekî encamek, şagirt berdewam dike ku daxwazên hilgirtinê bike û bibe endamê ISR. Zookeeper êdî ping distîne û têkçûnek broker tomar dike, lê ji ber ku ew tenê şopînerek e, piştî başbûnê ti encam tune.

Birinc. 26. Senaryo 3: Şopdar şandina daxwazên gihandinê ji serok re didomîne

Senaryo 4. Rêber şagirtan dibîne, lê Zookeeper nabîne

Birinc. 27. Senaryo 4. Rêber û du peyrew

Rêber ji Zookeeper veqetandî ye, lê ne ji brokerên bi şagirtan re.

Birinc. 28. Senaryo 4: Rêber ji Zookeeper veqetandî

Piştî demekê, Zookeeper dê têkçûnek broker tomar bike û li ser wê kontrolker agahdar bike. Ew ê di nav şagirtên xwe de rêberek nû hilbijêre. Lêbelê, rêberê orîjînal dê berdewam bike ku bifikire ku ew serok e û dê berdewam bike ku navnîşan qebûl bike acks=1. Şopdar êdî ji wî re daxwazên gihandinê naşînin, ji ber vê yekê ew ê wan mirî bihesibîne û hewl bide ku ISR ji xwe re kêm bike. Lê ji ber ku pêwendiya wê bi Zookeeper re tune ye, ew ê nikaribe vê yekê bike, û di wê gavê de ew ê red bike ku têketinên din qebûl bike.

Messages dike=hemû dê pejirandinek nestîne ji ber ku ISR pêşî li hemî kopiyan vedigire, û peyam nagihîjin wan. Gava ku rêberê eslî hewl dide ku wan ji ISR derxîne, ew ê nikaribe wiya bike û dê bi tevahî dev ji qebûl kirina peyaman berde.

Xerîdar di demek nêzîk de guheztina rêberiyê digirin û dest bi şandina tomaran ji servera nû dikin. Dema ku tor ji nû ve were sererast kirin, serokê eslî dibîne ku ew êdî ne serokek e û têketina xwe ji nirxa HW ya ku serokê nû di dema têkçûnê de hebû qut dike da ku ji cûdahiya têketinê dûr bixe. Dûv re ew ê dest bi şandina daxwazên hilanînê ji serokê nû re bike. Hemî tomarên ji rêberê eslî yên ku ji serokê nû re nayên dubare kirin winda dibin. Ango peyamên ku ji hêla rêberê eslî ve nehatine pejirandin di wan çend saniyeyan de dema ku du rêber dixebitin dê winda bibin.

Birinc. 29. Senaryo 4. Rêberê li ser brokera 1 piştî ku torê hate sererast kirin dibe şopînerê

Senaryo 5: Şopdar bi tevahî ji her du girêkên Kafka yên din û ji Zookeeper cuda ye

Şopdar bi tevahî ji herdu girêkên Kafka yên din û ji Zookeeper veqetandî ye. Ew bi tenê xwe ji ISR-ê derdixe heya ku torê were nûve kirin, û dûv re jî bi yên din re digire.

Birinc. 30. Senaryo 5: Şagirtê îzolekirî ji ISR tê derxistin

Senaryo 6: Rêber ji her du girêkên Kafka û Zookeeper bi tevahî veqetandî ye

Birinc. 31. Senaryo 6. Rêber û du peyrew

Rêber bi tevahî ji şagirtên xwe, kontrolker û Zookeeper veqetandî ye. Ji bo demek kurt ew ê berdewamiya pejirandina navnîşan ji acks=1.

Birinc. 32. Senaryoya 6: Veqetandina rêber ji girêkên din ên Kafka û Zookeeper

Piştî bidawîbûnê serlêdan negirtine replica.lag.time.max.ms, ew ê hewl bide ku ISR ji xwe re piçûk bike, lê dê nikaribe wiya bike ji ber ku bi Zookeeper re têkilî tune, wê hingê ew ê dev ji pejirandina nivîsandinê berde.

Di vê navberê de, Zookeeper dê brokerê veqetandî wekî mirî nîşan bide û kontrolker dê serokek nû hilbijêrin.

Birinc. 33. Senaryo 6. Du rêber

Dibe ku rêberê orîjînal ji bo çend saniyan navnîşan bipejirîne, lê paşê qebûl kirina peyaman rawestîne. Xerîdar her 60 saniyeyan bi metadata herî dawî têne nûve kirin. Ew ê ji guhertina rêber agahdar bibin û dê dest bi şandina navnîşan ji serokê nû re bikin.

Birinc. 34. Senaryo 6: Hilberîner berbi serokekî nû ve diçin

Hemî navnîşên pejirandî yên ku ji hêla rêberê orîjînal ve hatine çêkirin ji ber windabûna pêwendiyê dê winda bibin. Dema ku torê were nûve kirin, serokê orîjînal dê bi riya Zookeeper kifş bike ku ew êdî ne serok e. Dûv re ew ê di dema hilbijartinê de qeyda xwe ji HW-ya serokê nû re qut bike û wekî şopdar dest bi şandina daxwazan bike.

Birinc. 35. Senaryoya 6: Rêberê eslî piştî ku girêdana torê vegere dibe şopînerê

Di vê rewşê de, veqetandina mentiqî dikare ji bo demek kurt çêbibe, lê tenê heke acks=1 и min.insync.replicas her weha 1. Veqetandina mentiqî bixweber bi dawî dibe yan piştî ku torê were vegerandin, dema ku serokê eslî pê dihese ku ew êdî ne serok e, an jî dema ku hemî xerîdar pê dihesin ku rêber guherî ye û dest bi nivîsandina rêberê nû dikin - kîjan pêşî bibe. Di her rewşê de, hin peyam dê winda bibin, lê tenê bi acks=1.

Guhertoyek din a vê senaryoyê heye ku, hema berî dabeşbûna torê, şagirt li dû xwe ketin û rêber ISR tenê li xwe teng kir. Dûv re ji ber windabûna girêdanê îzole dibe. Rêberek nû tê hilbijartin, lê serokê eslî jî berdewam dike ku navnîşan qebûl bike dike=hemû, ji ber ku di ISR de ji bilî wî kesek din tune. Dema ku torê were sererast kirin dê ev tomar winda bibin. Yekane riya ku ji vê vebijarkê dûr dikeve ev e min.insync.replicas = 2.

Senaryo 7: Nodeya Kontrolkerê Kafka Nikare Nodek Kafkaya Din Bibîne

Bi gelemperî, gava ku pêwendiya bi girêka Kafka re winda bibe, dê kontrolker nikaribe agahdariya guhertina rêber jê re bişîne. Di rewşa herî xirab de, ev dê bibe sedema veqetînek mantiqî ya demkurt, wekî di senaryoya 6 de. Pir caran, broker dê bi tenê nebe berendamê serokatiyê heke ya paşîn biser nekeve.

Senaryo 8: Kontrolkerê Kafka Zookeeper nabîne

Zookeeper dê pingek ji kontrolkerê ketî wernegire û dê girêka Kafka ya nû wekî kontrolker hilbijêrin. Kontrolkerê orîjînal dikare berdewam bike ku xwe bi vî rengî nîşan bide, lê ew ji Zookeeper agahiyê nagire, ji ber vê yekê ew ê çu karan tune ku bike. Dema ku torê were vegerandin, ew ê fêm bike ku ew êdî ne kontrolker e, lê bûye girêka Kafka ya birêkûpêk.

Encamên ji senaryoyan

Em dibînin ku windabûna pêwendiya şopînerê ne di encama windabûna peyamê de ye, lê tenê bi demkî zêdebûnê kêm dike heya ku torê were sererast kirin. Ev, bê guman, dibe ku bibe sedema windabûna daneyê ger yek an jî bêtir girêk winda bibin.

Ger serok ji ber windabûna pêwendiyê ji Zookeeper veqete, ev dikare bibe sedema windabûna peyaman ji acks=1. Nebûna pêwendiya bi Zookeeper re dibe sedema qutbûnek mantiqî ya bi her du rêberan re. Ev pirsgirêk ji hêla pîvanê ve tê çareser kirin dike=hemû.

Parîsê min.insync.replicas di du an bêtir kopiyan de piştrastiyek din peyda dike ku senaryoyên weha kurt-kurt dê wekî di Senaryoya 6-ê de di peyamên winda de nebin.

Kurteya Peyamên Wenda

Ka em hemî awayên ku hûn dikarin di Kafka de daneyan winda bikin navnîş bikin:

Ger peyam bi kar were pejirandin her têkçûnek rêber acks=1
Her veguheztina nepak a serokatiyê, ango ji şagirtek li derveyî ISR re, tewra bi dike=hemû
Ger ku bi karanîna peyaman were pejirandin rêber ji Zookeeper veqetînin acks=1
Tecrîdkirina bêkêmasî ya rêberê ku berê koma ISR ji xwe re xwar kiriye. Hemî peyam dê winda bibin, tewra dike=hemû. Ev tenê heke rast e min.insync.replicas=1.
Têkçûnên hevdem ên hemî girêkên dabeşkirinê. Ji ber ku peyam ji bîranînê têne pejirandin, dibe ku hin hîn li ser dîskê neyên nivîsandin. Piştî ji nû ve destpêkirina pêşkêşkeran, dibe ku hin peyam winda bibin.

Veguheztinên serokatiyê yên nepak bi qedexekirina wan an jî misogerkirina bi kêmî ve du zêdebûnê ve têne dûr kirin. Veavakirina herî domdar hevokek e dike=hemû и min.insync.replicas ji 1 zêdetir.

Berhevdana rasterast a pêbaweriya RabbitMQ û Kafka

Ji bo pêbawerî û hebûna bilind, her du platform pergalek dubarekirina seretayî û duyemîn pêk tînin. Lêbelê, RabbitMQ pêçek Achilles heye. Dema ku piştî têkçûnek ji nû ve tê girêdan, girêk daneyên xwe diavêjin û hevdengkirin tê asteng kirin. Ev ducarî dirêjahiya rêzikên mezin ên li RabbitMQ dixe nav pirsê. Hûn neçar in ku kêmbûna zêdebûnê an demên dirêj ên astengkirinê qebûl bikin. Kêmkirina zêdebûnê xetera windabûna daneya girseyî zêde dike. Lê heke rêz piçûk bin, wê hingê ji bo zêdebûnê, demên kurt ên neberdestbûnê (çend saniye) dikarin bi karanîna hewildanên girêdanê yên dubare werin çareser kirin.

Kafka ev pirsgirêk nîne. Ew daneyan tenê ji cihê cihêbûna di navbera serok û şopînerê de vedişêre. Hemî daneyên hevpar têne tomar kirin. Wekî din, dubarekirina pergalê asteng nake. Rêber berdewam dike ku postan dipejirîne dema ku şopînerê nû digihîje, ji ber vê yekê ji bo devops, tevlêbûn an jî ji nû ve tevlêbûna komê dibe karek piçûk. Bê guman, di dema dubarekirinê de hîn jî pirsgirêkên wekî bandwidahiya torê hene. Ger hûn di heman demê de gelek şagirtan lê zêde bikin, dibe ku hûn bi sînorek bandfirehiyê re rû bi rû bibin.

RabbitMQ di pêbaweriyê de ji Kafka bilindtir e dema ku gelek pêşkêşkerên di komekê de di heman demê de têk diçin. Wekî ku me berê jî got, RabbitMQ tenê piştî ku peyam ji hêla master û hemî neynikê ve li ser dîskê were nivîsandin, piştrastiyek ji weşanger re dişîne. Lê ev ji ber du sedeman derengiya zêde zêde dike:

her çend sed milî çirkeyan carekê fsync bike
Têkçûna neynikê tenê piştî ku emrê pakêtên ku hebûna her girêkekê kontrol dikin (tîka torê) bi dawî dibe, tê dîtin. Ger neynik hêdî bibe an bikeve, ev dereng zêde dike.

Behîsa Kafka ev e ku heke peyamek li gelek girêkan were hilanîn, ew dikare gava ku ew peyaman di bîra xwe de bipejirîne. Ji ber vê yekê, xetera windakirina peyamên her celebî heye (heta dike=hemû, min.insync.replicas=2) di rewşa têkçûna hevdem de.

Bi tevayî, Kafka performansa nermalavê çêtir nîşan dide û ji bingehê ve ji bo koman hatî sêwirandin. Ger hewce be ji bo pêbaweriyê hejmara şopîneran dikare bibe 11. Faktora dubarekirinê 5 û hejmara hindiktirîn kopiyan di hevdemkirinê de min.insync.replicas=3 dê windakirina peyamê bibe bûyerek pir kêm. Ger binesaziya we dikare vê rêjeya dubarekirinê û asta zêdebûnê piştgirî bike, wê hingê hûn dikarin vê vebijarkê hilbijêrin.

Komkirina RabbitMQ ji bo rêzikên piçûk baş e. Lê dema ku seyrûsefera giran hebe rêzên piçûk jî dikarin zû mezin bibin. Dema ku rêz mezin bibin, hûn ê neçar in ku di navbera hebûna û pêbaweriyê de bijartên dijwar bikin. Komkirina RabbitMQ ji bo rewşên ne-tîpîkî yên ku feydeyên nermbûna RabbitMQ ji her dezawantajên komkirina wê mezintir e çêtirîn e.

Yek antîdotek li hember qelsbûna RabbitMQ ji rêzên mezin ev e ku wan di gelek dorên piçûktir de veqetîne. Heke hûn ne hewce ne ku hûn bi tevahî rêzika rêzê, lê tenê peyamên têkildar (mînakî, peyamên ji xerîdarek taybetî), an jî qet tiştek ferman nekin, wê hingê ev vebijark tê qebûl kirin: li projeya min binêrin Rebalancer ji bo dabeşkirina dorê (proje hîn di qonaxek destpêkê de ye).

Di dawiyê de, di mekanîzmayên komkirin û dubarekirina RabbitMQ û Kafka de çend xeletiyan ji bîr nekin. Bi demê re, pergal gihîştî û aramtir bûne, lê ti peyam 100% ji windabûnê ewle nabe! Wekî din, qezayên mezin di navendên daneyê de çêdibin!

Ger min tiştek ji bîr kir, xeletiyek kir, an hûn bi yek ji xalan re napejirînin, ji kerema xwe şîroveyek binivîsin an bi min re têkilî daynin.

Pir caran ji min tê pirsîn: "Çi hilbijêrin, Kafka an RabbitMQ?", "Kîjan platform çêtir e?". Rastî ev e ku ew bi rastî bi rewşa we, ezmûna heyî, hwd ve girêdayî ye. Ez dudil im ku nerîna xwe bidim ji ber ku ew ê pir hêsan be ku meriv platformek ji bo hemî rewşên karanîna û sînorên gengaz pêşniyar bike. Min ev rêze gotaran nivîsand da ku hûn ramana xwe çêbikin.

Ez dixwazim bibêjim ku her du sîstem jî di vî warî de pêşeng in. Dibe ku ez hinekî alîgir bim ji ber ku ji ezmûna xwe ya bi projeyan re ez meyldar im ku qîmetê bidim tiştên mîna fermankirina peyama garantî û pêbaweriyê.

Ez teknolojiyên din ên ku ji vê pêbaweriyê û fermana garantîkirî ne dibînim, dûv re ez li RabbitMQ û Kafka dinêrim û nirxa bêhempa ya van her du pergalan fam dikim.

Source: www.habr.com

RabbitMQ vs Kafka: Tolerasyona xelet û hebûna bilind