В erthygl olaf buom yn edrych ar glystyru RabbitMQ ar gyfer goddef diffygion ac argaeledd uchel. Nawr, gadewch i ni gloddio'n ddwfn i Apache Kafka.

Yma yr uned atgynhyrchu yw'r rhaniad. Mae gan bob pwnc un neu fwy o adrannau. Mae gan bob adran arweinydd gyda neu heb ddilynwyr. Wrth greu pwnc, rydych chi'n nodi nifer y rhaniadau a'r cyfernod atgynhyrchu. Y gwerth arferol yw 3, sy'n golygu tri atgynhyrchiad: un arweinydd a dau ddilynwr.

Reis. 1. Mae pedair adran yn cael eu dosbarthu ymhlith tri brocer

Mae pob cais darllen ac ysgrifennu yn mynd at yr arweinydd. O bryd i'w gilydd mae dilynwyr yn anfon ceisiadau at yr arweinydd i dderbyn y negeseuon diweddaraf. Nid yw defnyddwyr byth yn troi at ddilynwyr; mae'r olaf yn bodoli dim ond ar gyfer dileu swyddi a goddef diffygion.

Methiant rhaniad

Pan fydd brocer yn methu, mae arweinwyr sawl adran yn aml yn methu. Ym mhob un ohonynt, mae dilynwr o nod arall yn dod yn arweinydd. Mewn gwirionedd, nid yw hyn bob amser yn wir, gan fod y ffactor cydamseru hefyd yn dylanwadu: a oes dilynwyr cydamserol, ac os nad oes, yna a ganiateir newid i replica heb ei gydamseru. Ond gadewch i ni beidio â chymhlethu pethau am y tro.

Mae Brocer 3 yn gadael y rhwydwaith, ac etholir arweinydd newydd ar gyfer adran 2 yn brocer 2.

Reis. 2. Brocer 3 yn marw a'i ddilynwr ar frocer 2 yn cael ei ethol yn arweinydd newydd rhaniad 2

Yna mae brocer 1 yn gadael ac mae adran 1 hefyd yn colli ei harweinydd, y mae ei rôl yn trosglwyddo i frocer 2.

Reis. 3. Mae un brocer ar ôl. Mae pob arweinydd ar un brocer heb unrhyw ddiswyddiad

Pan ddaw brocer 1 yn ôl ar-lein, mae'n ychwanegu pedwar dilynwr, gan ddarparu rhywfaint o ddiswyddiad i bob rhaniad. Ond roedd yr holl arweinwyr yn dal i fod ar frocer 2.

Reis. 4. Mae'r arweinwyr yn aros ar frocer 2

Pan ddaw brocer 3 i fyny, rydym yn ôl i dri atgynhyrchiad fesul rhaniad. Ond mae'r holl arweinwyr yn dal i fod ar frocer 2.

Reis. 5. Lleoliad anghytbwys o arweinwyr ar ôl adfer broceriaid 1 a 3

Mae gan Kafka offeryn ar gyfer ail-gydbwyso arweinwyr yn well na RabbitMQ. Yno, bu'n rhaid i chi ddefnyddio ategyn neu sgript trydydd parti a newidiodd y polisïau ar gyfer mudo'r prif nod trwy leihau diswyddiad yn ystod mudo. Yn ogystal, ar gyfer ciwiau mawr roedd yn rhaid i ni dderbyn nad oedd ar gael yn ystod cydamseru.

Mae gan Kafka y cysyniad o “replicas a ffefrir” ar gyfer rôl yr arweinydd. Pan fydd rhaniadau pwnc yn cael eu creu, mae Kafka yn ceisio dosbarthu arweinwyr yn gyfartal ar draws nodau ac yn nodi'r arweinwyr cyntaf hynny fel y mae'n well ganddynt. Dros amser, oherwydd ailgychwyn gweinyddwyr, methiannau, a diffyg cysylltedd, gall arweinwyr gyrraedd nodau eraill, fel yn yr achos eithafol a ddisgrifir uchod.

I drwsio hyn, mae Kafka yn cynnig dau opsiwn:

Opsiwn auto.leader.rebalance.enable=gwir yn caniatáu i nod y rheolydd ailbennu arweinwyr yn awtomatig yn ôl i'r copïau a ffefrir a thrwy hynny adfer dosbarthiad unffurf.
Gall y gweinyddwr redeg y sgript kafka-preferred-replica-election.sh ar gyfer ailbennu â llaw.

Reis. 6. Atgynyrchiadau ar ôl ail-gydbwyso

Roedd hwn yn fersiwn symlach o'r methiant, ond mae'r realiti yn fwy cymhleth, er nad oes dim byd rhy gymhleth yma. Mae'r cyfan yn dibynnu ar gopïau wedi'u cydamseru (Replicas In-Sync, ISR).

Replicas Cydamserol (ISR)

Mae ISR yn set o atgynyrchiadau o raniad a ystyrir yn “gydamserol” (mewn cydamseriad). Mae yna arweinydd, ond efallai na fydd dilynwyr. Ystyrir bod dilynwr wedi'i gysoni os yw wedi gwneud copïau union o holl negeseuon yr arweinydd cyn i'r egwyl ddod i ben replica.lag.time.max.ms.

Mae dilynwr yn cael ei dynnu o'r set ISR os yw'n:

ni wnaeth gais i ddewis ar gyfer yr egwyl replica.lag.time.max.ms (tybiedig marw)
ni lwyddodd i ddiweddaru yn ystod yr egwyl replica.lag.time.max.ms (ystyrir yn araf)

Mae dilynwyr yn gwneud ceisiadau samplu yn yr egwyl replica.fetch.wait.max.ms, sy'n rhagosod i 500ms.

Er mwyn egluro pwrpas ISR yn glir, mae angen inni edrych ar gadarnhad gan y cynhyrchydd a rhai senarios methiant. Gall cynhyrchwyr ddewis pryd y bydd y brocer yn anfon cadarnhad:

acks=0, ni anfonir cadarnhad
acks=1, anfonir cadarnhad ar ôl i'r arweinydd ysgrifennu neges i'w log lleol
acks=all, anfonir cadarnhad ar ôl i bob atgynhyrchiad yn yr ISR ysgrifennu'r neges i'r logiau lleol

Yn nherminoleg Kafka, os yw'r ISR wedi arbed neges, mae'n “ymrwymedig”. Acks=all yw'r opsiwn mwyaf diogel, ond mae hefyd yn ychwanegu oedi ychwanegol. Edrychwn ar ddwy enghraifft o fethiant a sut mae'r gwahanol opsiynau 'mynd' yn rhyngweithio â'r cysyniad ISR.

Acks=1 ac ISR

Yn yr enghraifft hon, byddwn yn gweld, os na fydd yr arweinydd yn aros i bob neges gan yr holl ddilynwyr gael ei chadw, yna mae'n bosibl colli data os bydd yr arweinydd yn methu. Gellir galluogi neu analluogi llywio i ddilynwr heb ei gysoni trwy osod aflan.arweinydd.etholiad.

Yn yr enghraifft hon, mae gan y gwneuthurwr y gwerth acks = 1. Dosberthir yr adran ar draws y tri brocer. Mae Brocer 3 ar ei hôl hi, fe'i cydamserodd â'r arweinydd wyth eiliad yn ôl ac mae bellach 7456 o negeseuon ar ei hôl hi. Dim ond eiliad ar ei hôl hi oedd Brocer 1. Mae ein cynhyrchydd yn anfon neges ac yn derbyn ack yn ôl yn gyflym, heb orbenion dilynwyr araf neu farw nad yw'r arweinydd yn aros amdano.

Reis. 7. ISR gyda thri atgynhyrchiad

Brocer 2 yn methu ac mae'r cynhyrchydd yn derbyn gwall cysylltiad. Ar ôl i arweinyddiaeth basio i frocer 1, rydym yn colli 123 o negeseuon. Roedd y dilynwr ar frocer 1 yn rhan o'r ISR, ond ni chafodd ei gydamseru'n llawn â'r arweinydd pan syrthiodd.

Reis. 8. Negeseuon yn cael eu colli pan mae'n damweiniau

Mewn cyfluniad bootstrap.servers Mae gan y gwneuthurwr sawl brocer wedi'u rhestru a gall ofyn i frocer arall pwy yw'r arweinydd adran newydd. Yna mae'n sefydlu cysylltiad â brocer 1 ac yn parhau i anfon negeseuon.

Reis. 9. Mae anfon negeseuon yn ailddechrau ar ôl seibiant byr

Mae Brocer 3 hyd yn oed ymhellach ar ei hôl hi. Mae'n gwneud ceisiadau nôl ond nid oes modd cysoni. Gall hyn fod oherwydd cysylltiad rhwydwaith araf rhwng broceriaid, mater storio, ac ati Mae'n cael ei dynnu o'r ISR. Nawr mae'r ISR yn cynnwys un replica - yr arweinydd! Mae'r gwneuthurwr yn parhau i anfon negeseuon a derbyn cadarnhad.

Reis. 10. Mae dilynwr ar frocer 3 yn cael ei dynnu o'r ISR

Mae Brocer 1 yn mynd i lawr ac mae'r rôl arweinyddiaeth yn mynd i frocer 3 gyda cholli negeseuon 15286! Mae'r gwneuthurwr yn derbyn neges gwall cysylltiad. Dim ond oherwydd y lleoliad yr oedd trosglwyddo i arweinydd y tu allan i'r ISR yn bosibl unclean.leader.election.enable=gwir. Os caiff ei osod yn ffug, yna ni fyddai'r trawsnewid yn digwydd a byddai pob cais darllen ac ysgrifennu yn cael ei wrthod. Yn yr achos hwn, rydym yn aros i frocer 1 ddychwelyd gyda'i ddata cyfan yn y replica, a fydd unwaith eto yn cymryd drosodd yr arweinyddiaeth.

Reis. 11. brocer 1 syrthio. Pan fydd methiant yn digwydd, mae nifer fawr o negeseuon yn cael eu colli

Mae'r cynhyrchydd yn sefydlu cysylltiad â'r brocer olaf ac yn gweld ei fod bellach yn arweinydd yr adran. Mae'n dechrau anfon negeseuon at frocer 3.

Reis. 12. Ar ôl seibiant byr, anfonir negeseuon eto i adran 0

Gwelsom, ar wahân i ymyriadau byr i sefydlu cysylltiadau newydd a chwilio am arweinydd newydd, fod y gwneuthurwr yn anfon negeseuon yn gyson. Mae'r cyfluniad hwn yn sicrhau argaeledd ar draul cysondeb (diogelwch data). Collodd Kafka filoedd o negeseuon ond parhaodd i dderbyn ysgrifen newydd.

Acks=pawb ac ISR

Gadewch i ni ailadrodd y senario hwn eto, ond gyda acks=i gyd. Mae gan Brocer 3 hwyrni cyfartalog o bedair eiliad. Mae'r gwneuthurwr yn anfon neges gyda acks=i gyd, ac nid yw bellach yn cael ymateb cyflym. Mae'r arweinydd yn aros i'r neges gael ei hachub gan bob atgynhyrchiad yn yr ISR.

Reis. 13. ISR gyda thri atgynhyrchiad. Mae un yn araf, gan arwain at oedi wrth gofnodi

Ar ôl pedair eiliad o oedi ychwanegol, mae brocer 2 yn anfon ack. Mae'r holl atgynhyrchiadau bellach wedi'u diweddaru'n llawn.

Reis. 14. Mae pob replicas yn arbed negeseuon ac yn anfon yn ôl

Mae Brocer 3 bellach yn syrthio ymhellach ar ei hôl hi ac yn cael ei dynnu o'r ISR. Mae hwyrni yn cael ei leihau'n sylweddol oherwydd nad oes unrhyw atgynyrchiadau araf ar ôl yn yr ISR. Mae Brocer 2 bellach yn aros am frocer 1 yn unig, ac mae ganddo oedi cyfartalog o 500 ms.

Reis. 15. Mae'r atgynhyrchiad ar frocer 3 yn cael ei dynnu o'r ISR

Yna mae brocer 2 yn cwympo ac mae arweinyddiaeth yn pasio i frocer 1 heb golli negeseuon.

Reis. 16. Brocer 2 yn disgyn

Mae'r gwneuthurwr yn dod o hyd i arweinydd newydd ac yn dechrau anfon negeseuon ato. Mae'r hwyrni yn cael ei leihau ymhellach oherwydd bod yr ISR bellach yn cynnwys un replica! Felly yr opsiwn acks=i gyd nid yw'n ychwanegu diswyddiad.

Reis. 17. Mae replica ar brocer 1 yn cymryd yr awenau heb golli negeseuon

Yna mae brocer 1 yn damwain ac mae'r arweiniad yn mynd i frocer 3 gyda cholli negeseuon 14238!

Reis. 18. Brocer 1 yn marw ac mae trosglwyddo arweinyddiaeth gyda lleoliad aflan yn arwain at golli data yn helaeth

Ni allem osod yr opsiwn aflan.arweinydd.etholiad i mewn i ystyr yn wir. Yn ddiofyn, mae'n gyfartal ffug. Gosodiadau acks=i gyd с unclean.leader.election.enable=gwir yn darparu hygyrchedd gyda rhywfaint o ddiogelwch data ychwanegol. Ond fel y gwelwch, gallwn golli negeseuon o hyd.

Ond beth os ydym am gynyddu diogelwch data? Gallwch chi roi unclean.leader.election.enable = ffug, ond ni fydd hyn o reidrwydd yn ein hamddiffyn rhag colli data. Pe bai'r arweinydd yn cwympo'n galed ac yn mynd â'r data gydag ef, yna mae negeseuon yn dal i gael eu colli, ac mae argaeledd yn cael ei golli nes bod y gweinyddwr yn adfer y sefyllfa.

Mae'n well sicrhau bod pob neges yn ddiangen, a thaflu'r recordiad fel arall. Yna, o leiaf o safbwynt y brocer, dim ond os bydd dau neu fwy o fethiannau cydamserol y mae colli data yn bosibl.

Acs=pawb, min.insync.replicas ac ISR

Gyda chyfluniad pwnc min.insync.replicas Rydym yn cynyddu lefel diogelwch data. Gadewch i ni fynd trwy ran olaf y senario blaenorol eto, ond y tro hwn gyda min.insync.replicas=2.

Felly mae gan brocer 2 replica arweinydd ac mae'r dilynwr ar frocer 3 yn cael ei dynnu o'r ISR.

Reis. 19. ISR o ddau atgynhyrchiad

Brocer 2 yn disgyn ac arweinyddiaeth yn pasio i frocer 1 heb golli negeseuon. Ond nawr mae'r ISR yn cynnwys un atgynhyrchiad yn unig. Nid yw hyn yn bodloni'r nifer lleiaf i dderbyn cofnodion, ac felly mae'r brocer yn ymateb i'r ymgais i ysgrifennu gyda gwall NotDigon Replicas.

Reis. 20. Mae nifer yr ISRs un yn is na'r hyn a nodir yn min.insync.replicas

Mae'r cyfluniad hwn yn aberthu argaeledd er cysondeb. Cyn cydnabod neges, rydym yn sicrhau ei bod yn cael ei hysgrifennu at o leiaf ddau atgynhyrchiad. Mae hyn yn rhoi llawer mwy o hyder i'r gwneuthurwr. Yma, mae colli neges ond yn bosibl os bydd dau atgynhyrchiad yn methu ar yr un pryd mewn cyfnod byr nes bod y neges yn cael ei hailadrodd i ddilynwr ychwanegol, sy'n annhebygol. Ond os ydych chi'n hynod baranoiaidd, gallwch chi osod y ffactor atgynhyrchu i 5, a min.insync.replicas erbyn 3. Yma mae'n rhaid i dri brocer ddisgyn ar yr un pryd i golli'r record! Wrth gwrs, rydych chi'n talu am y dibynadwyedd hwn mewn hwyrni ychwanegol.

Pan fo hygyrchedd yn angenrheidiol ar gyfer diogelwch data

Fel yn achos gyda RabbitMQ, weithiau mae hygyrchedd yn angenrheidiol ar gyfer diogelwch data. Dyma beth sydd angen i chi feddwl amdano:

A all y cyhoeddwr ddychwelyd gwall a chael y gwasanaeth neu'r defnyddiwr i fyny'r afon i roi cynnig arall arni yn nes ymlaen?
A all y cyhoeddwr gadw'r neges yn lleol neu mewn cronfa ddata i geisio eto yn nes ymlaen?

Os nad yw'r ateb, yna mae optimeiddio argaeledd yn gwella diogelwch data. Byddwch yn colli llai o ddata os dewiswch argaeledd yn lle peidio â chofnodi. Felly, mae'r cyfan yn dibynnu ar ddod o hyd i gydbwysedd, ac mae'r penderfyniad yn dibynnu ar y sefyllfa benodol.

Ystyr ISR

Mae'r gyfres ISR yn caniatáu ichi ddewis y cydbwysedd gorau posibl rhwng diogelwch data a hwyrni. Er enghraifft, sicrhewch argaeledd os bydd y rhan fwyaf o'r atgynyrchiadau'n methu, gan leihau effaith atgynyrchiadau marw neu araf o ran cuddni.

Rydyn ni'n dewis yr ystyr ein hunain replica.lag.time.max.ms yn ôl eich anghenion. Yn y bôn, mae'r paramedr hwn yn golygu faint o oedi yr ydym yn fodlon ei dderbyn pryd acks=i gyd. Y gwerth rhagosodedig yw deg eiliad. Os yw hyn yn rhy hir i chi, gallwch ei leihau. Yna bydd amlder newidiadau yn yr ISR yn cynyddu, gan y bydd dilynwyr yn cael eu tynnu a'u hychwanegu'n amlach.

Yn syml, set o ddrychau yw RabbitMQ y mae angen eu hailadrodd. Mae drychau araf yn cyflwyno hwyrni ychwanegol, a gall drychau marw aros nes bod y pecynnau sy'n gwirio argaeledd pob nod (tic net) i ymateb. Mae ISR yn ffordd ddiddorol o osgoi'r materion cudd hyn. Ond rydym mewn perygl o golli swyddi gan mai dim ond i'r arweinydd y gall yr ISR grebachu. Er mwyn osgoi'r risg hon, defnyddiwch y gosodiad min.insync.replicas.

Gwarant cysylltiad cleient

Mewn lleoliadau bootstrap.servers gall cynhyrchydd a defnyddiwr nodi broceriaid lluosog ar gyfer cysylltu cleientiaid. Y syniad yw pan fydd un nod yn mynd i lawr, mae yna nifer o rai sbâr ar ôl y gall y cleient agor cysylltiad â nhw. Nid yw'r rhain o reidrwydd yn arweinwyr adran, ond yn hytrach yn fan cychwyn ar gyfer llwytho cychwynnol. Gall y cleient ofyn iddynt pa nod sy'n cynnal yr arweinydd rhaniad darllen/ysgrifennu.

Yn RabbitMQ, gall cleientiaid gysylltu ag unrhyw nod, ac mae llwybro mewnol yn anfon y cais i ble mae angen iddo fynd. Mae hyn yn golygu y gallwch chi osod cydbwysedd llwyth o flaen RabbitMQ. Mae Kafka yn ei gwneud yn ofynnol i gleientiaid gysylltu â'r nod sy'n cynnal yr arweinydd rhaniad cyfatebol. Mewn sefyllfa o'r fath, ni allwch osod cydbwysedd llwyth. Rhestr bootstrap.servers Mae'n hanfodol bod cleientiaid yn gallu cyrchu a dod o hyd i'r nodau cywir ar ôl methiant.

Pensaernïaeth Consensws Kafka

Hyd yn hyn, nid ydym wedi ystyried sut y mae’r clwstwr yn dysgu am gwymp y brocer a sut y caiff arweinydd newydd ei ethol. Er mwyn deall sut mae Kafka yn gweithio gyda rhaniadau rhwydwaith, yn gyntaf mae angen i chi ddeall y bensaernïaeth consensws.

Mae pob clwstwr Kafka yn cael ei ddefnyddio ynghyd â chlwstwr Zookeeper, sy'n wasanaeth consensws gwasgaredig sy'n caniatáu i'r system gyrraedd consensws ar ryw gyflwr penodol, gan flaenoriaethu cysondeb dros argaeledd. Mae angen caniatâd y mwyafrif o nodau Sŵ er mwyn cymeradwyo gweithrediadau darllen ac ysgrifennu.

Mae Zookeeper yn storio cyflwr y clwstwr:

Rhestr o bynciau, adrannau, ffurfweddiad, copïau arweinydd cyfredol, copïau dewisol.
Aelodau clwstwr. Mae pob brocer yn pings y clwstwr Zookeeper. Os na fydd yn derbyn ping o fewn cyfnod penodol o amser, yna mae Zookeeper yn cofnodi nad yw'r brocer ar gael.
Dewis y prif nodau a'r nodau sbâr ar gyfer y rheolydd.

Mae'r nod rheoli yn un o'r broceriaid Kafka sy'n gyfrifol am ethol arweinwyr replica. Mae Zookeeper yn anfon hysbysiadau at y rheolydd am aelodaeth clwstwr a newidiadau pwnc, a rhaid i'r rheolydd weithredu ar y newidiadau hyn.

Er enghraifft, gadewch i ni gymryd pwnc newydd gyda deg rhaniad a ffactor atgynhyrchu o 3. Rhaid i'r rheolwr ethol arweinydd ar gyfer pob rhaniad, gan geisio dosbarthu arweinwyr ymhlith y broceriaid yn y ffordd orau bosibl.

Ar gyfer pob rheolwr adran:

diweddaru gwybodaeth yn Zookeeper am ISR ac arweinydd;
Yn anfon LeaderAndISRCommand i bob brocer sy'n cynnal replica o'r rhaniad hwn, gan hysbysu'r broceriaid am yr ISR a'r arweinydd.

Pan fydd brocer ag arweinydd yn cwympo, mae Zookeeper yn anfon hysbysiad at y rheolwr, ac mae'n ethol arweinydd newydd. Unwaith eto, mae'r rheolwr yn diweddaru Zookeeper yn gyntaf ac yna'n anfon gorchymyn at bob brocer yn eu hysbysu am y newid arweinyddiaeth.

Mae pob arweinydd yn gyfrifol am recriwtio CMU. Gosodiadau replica.lag.time.max.ms yn penderfynu pwy fydd yn mynd i mewn yno. Pan fydd yr ISR yn newid, mae'r arweinydd yn trosglwyddo gwybodaeth newydd i Zookeeper.

Rhoddir gwybod i Geidwad y Sŵ bob amser am unrhyw newidiadau fel bod rheolwyr yn trosglwyddo'n esmwyth i arweinydd newydd os bydd methiant.

Reis. 21. Consensws Kafka

Protocol atgynhyrchu

Mae deall manylion atgynhyrchu yn eich helpu i ddeall senarios colli data posibl yn well.

Ymholiadau samplu, Log End Offset (LEO) a Highwater Mark (HW)

Roeddem o'r farn bod dilynwyr yn anfon ceisiadau nôl at yr arweinydd o bryd i'w gilydd. Y cyfwng rhagosodedig yw 500ms. Mae hyn yn wahanol i RabbitMQ oherwydd yn RabbitMQ nid y drych ciw sy'n cychwyn yr atgynhyrchu ond gan y meistr. Mae'r meistr yn gwthio newidiadau i'r drychau.

Mae'r arweinydd a'r holl ddilynwyr yn arbed y Log End Offset (LEO) a label Highwater (HW). Mae'r marc LEO yn storio gwrthbwyso'r neges olaf yn y replica lleol, ac mae'r HW yn dal gwrthbwyso'r ymrwymiad olaf. Cofiwch, ar gyfer statws ymrwymiad, bod yn rhaid parhau â'r neges ar draws pob atgynhyrchiad ISR. Mae hyn yn golygu bod LEO fel arfer ychydig ar y blaen i HW.

Pan fydd yr arweinydd yn derbyn neges, mae'n ei storio'n lleol. Mae'r dilynwr yn gwneud cais nôl trwy drosglwyddo ei LEO. Yna mae'r arweinydd yn anfon swp o negeseuon gan ddechrau o'r LEO hwn a hefyd yn trosglwyddo'r HW cyfredol. Pan fydd yr arweinydd yn derbyn gwybodaeth bod pob atgynhyrchiad wedi storio'r neges ar y gwrthbwyso a roddwyd, mae'n symud y marc HW. Dim ond yr arweinydd all symud yr HW, ac felly bydd yr holl ddilynwyr yn gwybod y gwerth cyfredol yn yr ymatebion i'w cais. Mae hyn yn golygu y gall dilynwyr lusgo y tu ôl i'r arweinydd o ran neges a gwybodaeth HW. Dim ond hyd at yr HW presennol y mae defnyddwyr yn eu derbyn.

Sylwch fod "parhau" yn golygu ysgrifenedig i'r cof, nid i ddisg. Ar gyfer perfformiad, mae Kafka yn cydamseru i ddisg ar gyfnod penodol. Mae gan RabbitMQ gyfwng o'r fath hefyd, ond dim ond ar ôl i'r meistr a'r holl ddrychau ysgrifennu'r neges i ddisg y bydd yn anfon cydnabyddiaeth at y cyhoeddwr. Penderfynodd datblygwyr Kafka, am resymau perfformiad, anfon ad cyn gynted ag y bydd y neges yn cael ei ysgrifennu i'r cof. Mae Kafka yn betio bod dileu swydd yn gwrthbwyso'r risg o storio negeseuon cydnabyddedig yn y cof yn fyr yn unig.

Methiant arweinydd

Pan fydd arweinydd yn cwympo, mae Zookeeper yn hysbysu'r rheolwr, ac mae'n dewis replica arweinydd newydd. Mae'r arweinydd newydd yn gosod marc HW newydd yn ôl ei LEO. Yna mae dilynwyr yn derbyn gwybodaeth am yr arweinydd newydd. Yn dibynnu ar y fersiwn o Kafka, bydd y dilynwr yn dewis un o ddau senario:

Bydd yn cwtogi'r log lleol i HW hysbys ac yn anfon cais at yr arweinydd newydd am negeseuon ar ôl y marc hwn.
A fydd yn anfon cais at yr arweinydd i ddarganfod yr HW ar yr adeg y cafodd ei ethol yn arweinydd, ac yna torri'r log i'r gwrthbwyso hwn. Yna bydd yn dechrau gwneud ceisiadau nôl cyfnodol gan ddechrau ar y gwrthbwyso hwn.

Efallai y bydd angen i ddilynwr gwtogi’r log am y rhesymau canlynol:

Pan fydd arweinydd yn methu, mae'r dilynwr cyntaf yn y set ISR sydd wedi'i gofrestru gyda Zookeeper yn ennill yr etholiad ac yn dod yn arweinydd. Mae'n bosibl na fydd yr holl ddilynwyr ar ISR, er eu bod yn cael eu hystyried “ar y cyd,” wedi derbyn copïau o'r holl negeseuon gan y cyn arweinydd. Mae'n gwbl bosibl nad oes gan y dilynwr dan sylw y copi mwyaf diweddar. Mae Kafka yn sicrhau nad oes unrhyw wahaniaeth rhwng atgynyrchiadau. Felly, er mwyn osgoi anghysondebau, rhaid i bob dilynwr dorri ei log i werth HW yr arweinydd newydd ar adeg ei ethol. Dyma reswm arall dros osod acks=i gyd mor bwysig ar gyfer cysondeb.
Mae negeseuon yn cael eu hysgrifennu ar ddisg o bryd i'w gilydd. Os bydd pob nod clwstwr yn methu ar yr un pryd, yna bydd atgynyrchiadau gyda gwrthbwyso gwahanol yn cael eu storio ar y disgiau. Mae'n bosibl, pan ddaw broceriaid yn ôl ar-lein, y bydd yr arweinydd newydd a etholir y tu ôl i'w ddilynwyr oherwydd iddo gael ei arbed i ddisg cyn y lleill.

Aduniad gyda'r clwstwr

Wrth ailymuno â'r clwstwr, mae'r atgynyrchiadau yn gwneud yr un peth â phan fydd arweinydd yn methu: maent yn gwirio replica'r arweinydd ac yn torri eu log i'w HW (adeg etholiad). Mewn cymhariaeth, mae RabbitMQ yn trin nodau a adunir yn gyfartal fel nodau cwbl newydd. Yn y ddau achos, mae'r brocer yn taflu unrhyw gyflwr presennol. Os defnyddir cydamseru awtomatig, yna rhaid i'r meistr atgynhyrchu'r holl gynnwys cyfredol i'r drych newydd mewn dull “gadewch i'r byd i gyd aros”. Nid yw'r meistr yn derbyn unrhyw weithrediadau darllen nac ysgrifennu yn ystod y llawdriniaeth hon. Mae'r dull hwn yn creu problemau mewn ciwiau mawr.

Mae Kafka yn log dosbarthedig ac yn gyffredinol mae'n storio mwy o negeseuon na chiw RabbitMQ, lle mae data'n cael ei dynnu o'r ciw ar ôl iddo gael ei ddarllen. Dylai ciwiau gweithredol aros yn gymharol fach. Ond mae Kafka yn log gyda'i bolisi cadw ei hun, a all osod cyfnod o ddyddiau neu wythnosau. Mae'r dull blocio ciw a chydamseru llawn yn gwbl annerbyniol ar gyfer log dosbarthedig. Yn lle hynny, mae dilynwyr Kafka yn syml yn torri eu log i HW yr arweinydd (ar adeg ei ethol) os yw eu copi o flaen yr arweinydd. Yn yr achos mwy tebygol, pan fydd y dilynwr ar ei hôl hi, yn syml mae'n dechrau gwneud ceisiadau nôl gan ddechrau gyda'i LEO presennol.

Mae dilynwyr newydd neu ddilynwyr wedi ailymuno yn dechrau y tu allan i'r ISR ac nid ydynt yn cymryd rhan mewn ymrwymiadau. Yn syml, maen nhw'n gweithio ochr yn ochr â'r grŵp, gan dderbyn negeseuon mor gyflym ag y gallant nes iddynt ddal i fyny â'r arweinydd a mynd i mewn i'r ISR. Nid oes cloi i mewn ac nid oes angen taflu'ch holl ddata i ffwrdd.

Colli cysylltedd

Mae gan Kafka fwy o gydrannau na RabbitMQ, felly mae ganddo set fwy cymhleth o ymddygiadau pan fydd y clwstwr yn cael ei ddatgysylltu. Ond cynlluniwyd Kafka yn wreiddiol ar gyfer clystyrau, felly mae'r atebion wedi'u hystyried yn ofalus iawn.

Isod mae sawl senario methiant cysylltedd:

Senario 1: Nid yw'r dilynwr yn gweld yr arweinydd, ond mae'n dal i weld y Sŵ-geidwad.
Senario 2: Nid yw'r arweinydd yn gweld unrhyw ddilynwyr, ond mae'n dal i weld Zookeeper.
Senario 3: Mae'r dilynwr yn gweld yr arweinydd, ond nid yw'n gweld y Sŵ-geidwad.
Senario 4: Mae'r arweinydd yn gweld y dilynwyr, ond nid yw'n gweld y Sŵ-geidwad.
Senario 5: Mae'r dilynwr yn gwbl ar wahân i'r ddau nod Kafka arall a'r Sŵ-geidwad.
Senario 6: Mae'r arweinydd yn gwbl ar wahân i'r ddau nod Kafka arall a'r Sŵ-geidwad.
Senario 7: Ni all nod rheolydd Kafka weld nod Kafka arall.
Senario 8: Nid yw rheolwr Kafka yn gweld Zookeeper.

Mae gan bob senario ei ymddygiad ei hun.

Senario 1: Nid yw'r dilynwr yn gweld yr arweinydd, ond mae'n dal i weld Zookeeper

Reis. 22. Senario 1: ISR o dri atgynhyrchiad

Mae'r methiant cysylltedd yn gwahanu brocer 3 oddi wrth froceriaid 1 a 2, ond nid oddi wrth Zookeeper. Ni all Brocer 3 anfon ceisiadau nôl mwyach. Wedi i amser fynd heibio replica.lag.time.max.ms caiff ei dynnu o'r ISR ac nid yw'n cymryd rhan mewn ymrwymiadau neges. Unwaith y bydd cysylltedd wedi'i adfer, bydd yn ailddechrau ceisiadau nôl ac yn ymuno â'r ISR pan fydd yn dal i fyny â'r arweinydd. Bydd Zookeeper yn parhau i dderbyn pings ac yn cymryd yn ganiataol bod y brocer yn fyw ac yn iach.

Reis. 23. Senario 1: Mae'r brocer yn cael ei dynnu o'r ISR os na cheir cais nôl ganddo o fewn yr egwyl replica.lag.time.max.ms

Nid oes unrhyw ataliad hollt-ymennydd neu nod fel yn RabbitMQ. Yn lle hynny, mae diswyddiad yn cael ei leihau.

Senario 2: Nid yw'r Arweinydd yn gweld unrhyw ddilynwyr, ond mae'n dal i weld Zookeeper

Reis. 24. Senario 2. Arweinydd a dau ddilynwr

Mae dadansoddiad mewn cysylltedd rhwydwaith yn gwahanu'r arweinydd oddi wrth y dilynwyr, ond gall y brocer weld Zookeeper o hyd. Fel yn y senario gyntaf, mae'r ISR yn crebachu, ond y tro hwn dim ond i'r arweinydd wrth i'r holl ddilynwyr roi'r gorau i anfon ceisiadau nôl. Unwaith eto, nid oes rhaniad rhesymegol. Yn lle hynny, mae colli swyddi ar gyfer negeseuon newydd nes bod cysylltedd yn cael ei adfer. Mae Zookeeper yn parhau i dderbyn pings ac yn credu bod y brocer yn fyw ac yn iach.

Reis. 25. Senario 2. ISR wedi crebachu i'r arweinydd yn unig

Senario 3. Mae'r dilynwr yn gweld yr arweinydd, ond nid yw'n gweld y Sŵ-geidwad

Mae'r dilynwr wedi'i wahanu oddi wrth Zookeeper, ond nid oddi wrth y brocer gyda'r arweinydd. O ganlyniad, mae'r dilynwr yn parhau i wneud ceisiadau nôl a bod yn aelod o'r ISR. Nid yw Zookeeper bellach yn derbyn pings ac yn cofrestru damwain brocer, ond gan mai dilynwr yn unig ydyw, nid oes unrhyw ganlyniadau ar ôl adferiad.

Reis. 26. Senario 3: Mae'r dilynwr yn parhau i anfon ceisiadau nôl at yr arweinydd

Senario 4. Arweinydd yn gweld dilynwyr, ond nid yw'n gweld Zookeeper

Reis. 27. Senario 4. Arweinydd a dau ddilynwr

Mae'r arweinydd wedi'i wahanu oddi wrth Zookeeper, ond nid oddi wrth y broceriaid gyda dilynwyr.

Reis. 28. Senario 4: Arweinydd wedi'i ynysu oddi wrth Sŵ-geidwad

Ar ôl peth amser, bydd Zookeeper yn cofrestru methiant brocer ac yn hysbysu'r rheolwr amdano. Bydd yn dewis arweinydd newydd ymhlith ei ddilynwyr. Fodd bynnag, bydd yr arweinydd gwreiddiol yn parhau i feddwl mai ef yw'r arweinydd a bydd yn parhau i dderbyn cynigion ganddo aciau=1. Nid yw dilynwyr bellach yn anfon ceisiadau nôl ato, felly bydd yn eu hystyried yn farw ac yn ceisio lleihau'r ISR iddo'i hun. Ond gan nad oes ganddo gysylltiad â Zookeeper, ni fydd yn gallu gwneud hyn, a bryd hynny bydd yn gwrthod derbyn unrhyw geisiadau pellach.

Сообщения acks=i gyd Ni fydd yn derbyn cydnabyddiaeth oherwydd bod yr ISR yn troi pob atgynhyrchiad ymlaen yn gyntaf, ac nid yw negeseuon yn eu cyrraedd. Pan fydd yr arweinydd gwreiddiol yn ceisio eu tynnu o'r ISR, ni fydd yn gallu gwneud hynny a bydd yn rhoi'r gorau i dderbyn unrhyw negeseuon o gwbl.

Yn fuan bydd cleientiaid yn sylwi ar y newid yn yr arweinydd ac yn dechrau anfon cofnodion i'r gweinydd newydd. Unwaith y bydd y rhwydwaith wedi'i adfer, mae'r arweinydd gwreiddiol yn gweld nad yw bellach yn arweinydd ac mae'n cwtogi ei log i'r gwerth HW a oedd gan yr arweinydd newydd ar adeg methiant i osgoi dargyfeiriad boncyff. Yna bydd yn dechrau anfon ceisiadau nôl at yr arweinydd newydd. Mae'r holl gofnodion gan yr arweinydd gwreiddiol nad ydynt yn cael eu hailadrodd i'r arweinydd newydd yn cael eu colli. Hynny yw, bydd negeseuon na chafodd eu cydnabod gan yr arweinydd gwreiddiol yn yr ychydig eiliadau hynny pan oedd dau arweinydd yn gweithio yn cael eu colli.

Reis. 29. Senario 4. Daw'r arweinydd ar frocer 1 yn ddilynwr ar ôl i'r rhwydwaith gael ei adfer

Senario 5: Mae'r dilynwr yn gwbl ar wahân i'r ddau nod Kafka arall a'r Sŵ-geidwad

Mae'r dilynwr wedi'i ynysu'n llwyr oddi wrth nodau eraill Kafka a Zookeeper. Yn syml, mae'n tynnu ei hun o'r ISR nes bod y rhwydwaith yn cael ei adfer, ac yna'n dal i fyny â'r lleill.

Reis. 30. Senario 5: Dilynwr ynysig yn cael ei dynnu o'r ISR

Senario 6: Mae'r arweinydd yn gwbl ar wahân i'r ddau nod Kafka arall a'r Sŵ-geidwad

Reis. 31. Senario 6. Arweinydd a dau ddilynwr

Mae'r arweinydd wedi'i ynysu'n llwyr oddi wrth ei ddilynwyr, y rheolwr a Zookeeper. Am gyfnod byr bydd yn parhau i dderbyn ceisiadau gan aciau=1.

Reis. 32. Senario 6: Ynysu'r arweinydd oddi wrth nodau eraill Kafka a Zookeeper

Heb dderbyn ceisiadau ar ôl dod i ben replica.lag.time.max.ms, bydd yn ceisio crebachu'r ISR iddo'i hun, ond ni fydd yn gallu gwneud hynny oherwydd nad oes unrhyw gyfathrebu â Zookeeper, yna bydd yn rhoi'r gorau i dderbyn ysgrifen.

Yn y cyfamser, bydd Zookeeper yn nodi bod y brocer ynysig wedi marw a bydd y rheolwr yn ethol arweinydd newydd.

Reis. 33. Senario 6. Dau arweinydd

Gall yr arweinydd gwreiddiol dderbyn cynigion am ychydig eiliadau, ond yna'n peidio â derbyn unrhyw negeseuon. Mae cleientiaid yn cael eu diweddaru bob 60 eiliad gyda'r metadata diweddaraf. Byddant yn cael gwybod am y newid arweinydd ac yn dechrau anfon ceisiadau at yr arweinydd newydd.

Reis. 34. Senario 6: Gweithgynhyrchwyr yn newid i arweinydd newydd

Bydd yr holl gofnodion a gadarnhawyd gan yr arweinydd gwreiddiol ers colli cysylltedd yn cael eu colli. Unwaith y bydd y rhwydwaith yn cael ei adfer, bydd yr arweinydd gwreiddiol yn darganfod trwy Zookeeper nad yw bellach yn arweinydd. Yna bydd yn torri ei log i HW yr arweinydd newydd ar adeg yr etholiad ac yn dechrau anfon ceisiadau fel dilynwr.

Reis. 35. Senario 6: Daw'r arweinydd gwreiddiol yn ddilynwr ar ôl adfer cysylltedd rhwydwaith

Yn y sefyllfa hon, gall gwahaniad rhesymegol ddigwydd am gyfnod byr, ond dim ond os aciau=1 и min.insync.replicas hefyd 1. Mae gwahaniad rhesymegol yn dod i ben yn awtomatig naill ai ar ôl i'r rhwydwaith gael ei adfer, pan fydd yr arweinydd gwreiddiol yn sylweddoli nad ef yw'r arweinydd mwyach, neu pan fydd yr holl gleientiaid yn sylweddoli bod yr arweinydd wedi newid ac yn dechrau ysgrifennu at yr arweinydd newydd - pa un bynnag sy'n digwydd gyntaf. Mewn unrhyw achos, bydd rhai negeseuon yn cael eu colli, ond dim ond gyda aciau=1.

Mae amrywiad arall ar y senario hwn lle, ychydig cyn i'r rhwydwaith hollti, syrthiodd y dilynwyr ar ei hôl hi a chywasgodd yr arweinydd yr ISR i'w hun yn unig. Yna mae'n mynd yn ynysig oherwydd colli cysylltedd. Etholir arweinydd newydd, ond mae'r arweinydd gwreiddiol yn parhau i dderbyn ceisiadau, hyd yn oed acks=i gyd, am nad oes neb arall yn ISR ond ef. Bydd y cofnodion hyn yn cael eu colli unwaith y bydd y rhwydwaith wedi'i adfer. Yr unig ffordd i osgoi'r opsiwn hwn yw min.insync.replicas = 2.

Senario 7: Nôd Rheolydd Kafka Methu Gweld Nod Kafka Arall

Yn gyffredinol, unwaith y bydd y cysylltiad â nod Kafka yn cael ei golli, ni fydd y rheolwr yn gallu trosglwyddo unrhyw wybodaeth newid arweinydd iddo. Yn yr achos gwaethaf, bydd hyn yn arwain at wahaniad rhesymegol tymor byr, fel yn senario 6. Yn amlach na pheidio, ni fydd y brocer yn dod yn ymgeisydd ar gyfer arweinyddiaeth os bydd yr olaf yn methu.

Senario 8: Nid yw rheolwr Kafka yn gweld Zookeeper

Ni fydd Zookeeper yn derbyn ping gan y rheolydd cwympo a bydd yn dewis nod Kafka newydd fel y rheolydd. Gall y rheolydd gwreiddiol barhau i gyflwyno ei hun felly, ond nid yw'n derbyn hysbysiadau gan Zookeeper, felly ni fydd ganddo unrhyw dasgau i'w cyflawni. Unwaith y bydd y rhwydwaith yn cael ei adfer, bydd yn sylweddoli nad yw bellach yn rheolwr, ond mae wedi dod yn nod Kafka rheolaidd.

Casgliadau o'r senarios

Gwelwn nad yw colli cysylltedd dilynwr yn arwain at golli neges, ond yn syml yn lleihau diswyddiadau dros dro nes bod y rhwydwaith yn cael ei adfer. Gall hyn, wrth gwrs, arwain at golli data os collir un neu fwy o nodau.

Os bydd yr arweinydd yn cael ei wahanu oddi wrth Zookeeper oherwydd colli cysylltedd, gallai hyn arwain at golli negeseuon o aciau=1. Mae diffyg cyfathrebu gyda Zookeeper yn achosi rhaniad rhesymegol byr gyda'r ddau arweinydd. Mae'r broblem hon yn cael ei datrys gan y paramedr acks=i gyd.

Paramedr min.insync.replicas mewn dau neu fwy o atgynhyrchiadau yn rhoi sicrwydd ychwanegol na fydd senarios tymor byr o’r fath yn arwain at golli negeseuon fel yn Senario 6.

Crynodeb o Negeseuon Coll

Gadewch i ni restru'r holl ffyrdd y gallwch chi golli data yn Kafka:

Unrhyw fethiant arweinydd os cadarnhawyd bod negeseuon yn defnyddio aciau=1
Unrhyw drawsnewidiad aflan o arweinyddiaeth, hynny yw, i ddilynwr y tu allan i'r ISR, hyd yn oed gyda acks=i gyd
Ynysu'r arweinydd o Zookeeper pe bai negeseuon yn cael eu cadarnhau yn defnyddio aciau=1
Unigedd llwyr yr arweinydd sydd eisoes wedi crebachu'r grŵp ISR i'w hun. Bydd yr holl negeseuon yn cael eu colli, hyd yn oed acks=i gyd. Nid yw hyn ond yn wir os min.insync.replicas=1.
Methiannau cydamserol pob nod rhaniad. Oherwydd bod negeseuon yn cael eu cydnabod o'r cof, efallai na fydd rhai wedi'u hysgrifennu ar ddisg eto. Ar ôl ailgychwyn y gweinyddwyr, efallai y bydd rhai negeseuon ar goll.

Gellir osgoi trawsnewidiadau arweinyddiaeth amhur trwy naill ai eu gwahardd neu sicrhau o leiaf ddau ddiswyddiad. Cyfuniad yw'r cyfluniad mwyaf gwydn acks=i gyd и min.insync.replicas dros 1.

Cymhariaeth uniongyrchol o ddibynadwyedd RabbitMQ a Kafka

Er mwyn sicrhau dibynadwyedd ac argaeledd uchel, mae'r ddau blatfform yn gweithredu system atgynhyrchu cynradd ac eilaidd. Fodd bynnag, mae gan RabbitMQ sawdl Achilles. Wrth ailgysylltu ar ôl methiant, mae nodau'n taflu eu data ac mae cydamseru yn cael ei rwystro. Mae'r whammy dwbl hwn yn codi amheuaeth ynghylch hirhoedledd ciwiau mawr yn RabbitMQ. Bydd yn rhaid i chi dderbyn naill ai llai o ddiswyddiad neu amseroedd blocio hir. Mae lleihau diswyddiadau yn cynyddu'r risg o golli data enfawr. Ond os yw'r ciwiau'n fach, yna er mwyn dileu swyddi, gellir delio â chyfnodau byr o ddiffyg argaeledd (ychydig eiliadau) gan ddefnyddio ymdrechion cysylltu dro ar ôl tro.

Nid oes gan Kafka y broblem hon. Mae'n taflu data yn unig o'r pwynt o wahaniaeth rhwng yr arweinydd a'r dilynwr. Mae'r holl ddata a rennir yn cael ei gadw. Yn ogystal, nid yw atgynhyrchu yn rhwystro'r system. Mae'r arweinydd yn parhau i dderbyn swyddi tra bod y dilynwr newydd yn dal i fyny, felly ar gyfer devops, mae ymuno neu ailymuno â'r clwstwr yn dod yn dasg ddibwys. Wrth gwrs, mae problemau o hyd fel lled band rhwydwaith yn ystod atgynhyrchu. Os ydych chi'n ychwanegu dilynwyr lluosog ar yr un pryd, efallai y byddwch chi'n dod ar draws terfyn lled band.

Mae RabbitMQ yn well na Kafka o ran dibynadwyedd pan fydd gweinyddwyr lluosog mewn clwstwr yn methu ar yr un pryd. Fel y dywedasom eisoes, mae RabbitMQ yn anfon cadarnhad i'r cyhoeddwr dim ond ar ôl i'r neges gael ei hysgrifennu ar ddisg gan y meistr a'r holl ddrychau. Ond mae hyn yn ychwanegu hwyrni ychwanegol am ddau reswm:

fsync bob ychydig gannoedd o filieiliadau
Dim ond ar ôl i oes y pecynnau sy'n gwirio argaeledd pob nod (tic net) ddod i ben y gellir sylwi ar fethiant y drych. Os yw'r drych yn arafu neu'n cwympo, mae hyn yn ychwanegu oedi.

Bet Kafka yw, os yw neges yn cael ei storio ar draws nodau lluosog, gall gydnabod negeseuon cyn gynted ag y byddant yn taro'r cof. Oherwydd hyn, mae perygl o golli negeseuon o unrhyw fath (hyd yn oed acks=i gyd, min.insync.replicas=2) mewn achos o fethiant ar yr un pryd.

Ar y cyfan, mae Kafka yn arddangos perfformiad meddalwedd gwell ac wedi'i gynllunio o'r gwaelod i fyny ar gyfer clystyrau. Gellir cynyddu nifer y dilynwyr i 11 os oes angen ar gyfer dibynadwyedd. Ffactor atgynhyrchu 5 ac isafswm nifer y copïau wrth gydamseru min.insync.replicas=3 Bydd colli neges yn ddigwyddiad prin iawn. Os gall eich seilwaith gynnal y gymhareb atgynhyrchu hon a lefel y diswyddiadau, yna gallwch ddewis yr opsiwn hwn.

Mae clystyru RabbitMQ yn dda ar gyfer ciwiau bach. Ond gall hyd yn oed ciwiau bach dyfu'n gyflym pan fo traffig trwm. Unwaith y bydd ciwiau'n cynyddu, bydd yn rhaid i chi wneud dewisiadau anodd rhwng argaeledd a dibynadwyedd. Clystyru RabbitMQ sydd fwyaf addas ar gyfer sefyllfaoedd annodweddiadol lle mae manteision hyblygrwydd RabbitMQ yn gorbwyso unrhyw anfanteision o'i glystyru.

Un ateb i ba mor agored i RabbitMQ yw ciwiau mawr yw eu rhannu'n nifer o giwiau llai. Os nad oes angen archebu'r ciw cyfan yn gyflawn, ond dim ond y negeseuon perthnasol (er enghraifft, negeseuon gan gleient penodol), neu os nad ydych yn archebu unrhyw beth o gwbl, yna mae'r opsiwn hwn yn dderbyniol: edrychwch ar fy mhrosiect Ail-gydbwyswr i rannu'r ciw (mae'r prosiect yn dal yn ei gyfnod cynnar).

Yn olaf, peidiwch ag anghofio am nifer o fygiau ym mecanweithiau clystyru ac atgynhyrchu RabbitMQ a Kafka. Dros amser, mae systemau wedi dod yn fwy aeddfed a sefydlog, ond ni fydd unrhyw neges byth yn 100% yn ddiogel rhag colled! Yn ogystal, mae damweiniau ar raddfa fawr yn digwydd mewn canolfannau data!

Os methais rywbeth, gwneud camgymeriad, neu os ydych yn anghytuno ag unrhyw un o'r pwyntiau, mae croeso i chi ysgrifennu sylw neu gysylltu â mi.

Gofynnir i mi yn aml: “Beth i'w ddewis, Kafka neu RabbitMQ?”, “Pa blatfform sy'n well?”. Y gwir yw ei fod yn wir yn dibynnu ar eich sefyllfa, profiad presennol, ac ati Rwy'n betrusgar i roi fy marn oherwydd byddai'n ormod o orsymleiddio i argymell un llwyfan ar gyfer pob achos defnydd a chyfyngiadau posibl. Ysgrifennais y gyfres hon o erthyglau fel y gallwch chi ffurfio eich barn eich hun.

Rwyf am ddweud bod y ddwy system yn arweinwyr yn y maes hwn. Efallai fy mod ychydig yn rhagfarnllyd oherwydd o fy mhrofiad gyda phrosiectau rwy'n tueddu i werthfawrogi pethau fel archebu negeseuon gwarantedig a dibynadwyedd.

Rwy'n gweld technolegau eraill nad oes ganddynt y dibynadwyedd a'r archebu gwarantedig hwn, yna rwy'n edrych ar RabbitMQ a Kafka ac yn sylweddoli gwerth anhygoel y ddwy system hyn.

Ffynhonnell: hab.com

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel