RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau

Mae goddefgarwch namau ac argaeledd uchel yn bynciau mawr, felly byddwn yn neilltuo erthyglau ar wahân i RabbitMQ a Kafka. Mae'r erthygl hon yn ymwneud â RabbitMQ, ac mae'r un nesaf yn ymwneud â Kafka, o'i gymharu â RabbitMQ. Mae hon yn erthygl hir, felly gwnewch eich hun yn gyfforddus.

Gadewch i ni edrych ar y strategaethau goddefgarwch bai, cysondeb, ac argaeledd uchel (HA) a'r cyfaddawdau y mae pob strategaeth yn eu gwneud. Gall RabbitMQ redeg ar glwstwr o nodau - ac yna caiff ei ddosbarthu fel system ddosbarthedig. O ran systemau gwasgaredig, rydym yn aml yn siarad am gysondeb ac argaeledd.

Mae'r cysyniadau hyn yn disgrifio sut mae system yn ymddwyn pan fydd yn methu. Methiant cysylltiad rhwydwaith, methiant gweinydd, methiant gyriant caled, gweinydd ddim ar gael dros dro oherwydd casglu sbwriel, colli pecynnau, neu arafu cysylltiad rhwydwaith. Gall hyn oll arwain at golli data neu wrthdaro. Mae'n troi allan ei bod bron yn amhosibl gosod system sy'n gwbl gyson (dim colli data, dim dargyfeiriad data) ac sydd ar gael (bydd yn derbyn darllen ac ysgrifennu) ar gyfer pob senario methiant.

Fe welwn fod cysondeb ac argaeledd ar ben arall y sbectrwm, ac mae angen i chi ddewis pa ffordd i optimeiddio. Y newyddion da yw bod y dewis hwn yn bosibl gyda RabbitMQ. Mae gennych y mathau hyn o liferi “nerdi” i symud y cydbwysedd tuag at fwy o gysondeb neu fwy o hygyrchedd.

Byddwn yn rhoi sylw arbennig i ba gyfluniadau sy'n arwain at golli data oherwydd cofnodion a gadarnhawyd. Mae cadwyn o gyfrifoldeb rhwng cyhoeddwyr, broceriaid a defnyddwyr. Unwaith y bydd y neges yn cael ei throsglwyddo i'r brocer, ei swydd ef yw peidio â cholli'r neges. Pan fydd y brocer yn cydnabod bod y cyhoeddwr wedi derbyn y neges, nid ydym yn disgwyl iddi gael ei cholli. Ond fe welwn y gall hyn ddigwydd mewn gwirionedd yn dibynnu ar eich cyfluniad brocer a chyhoeddwr.

Cyntefig Gwydnwch Nod Sengl

Ciwio / Llwybro Gwydn

Mae dau fath o giw yn RabbitMQ: gwydn ac an-wydn. Mae pob ciw yn cael ei gadw yng nghronfa ddata Mnesia. Mae ciwiau gwydn yn cael eu hail-hysbysebu wrth gychwyn nodau ac felly'n goroesi ailgychwyniadau, damweiniau system, neu ddamweiniau gweinydd (cyn belled â bod y data'n parhau). Mae hyn yn golygu cyn belled â'ch bod yn datgan bod llwybro (cyfnewid) a chiwio yn wydn, bydd y seilwaith ciwio/llwyo yn dychwelyd ar-lein.

Mae ciwiau a llwybro anweddol yn cael eu tynnu pan fydd y nod yn cael ei ailgychwyn.

Negeseuon cyson

Nid yw'r ffaith bod ciw yn wydn yn golygu y bydd ei holl negeseuon yn goroesi ailgychwyn nod. Dim ond negeseuon a osodwyd gan y cyhoeddwr fel cynaliadwy (parhaus). Mae negeseuon cyson yn creu llwyth ychwanegol ar y brocer, ond os yw colli neges yn annerbyniol, yna nid oes opsiwn arall.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 1. Matrics cynaliadwyedd

Clystyru gyda ciw yn adlewyrchu

Er mwyn goroesi colli brocer, mae angen dileu swydd. Gallwn gyfuno nodau RabbitMQ lluosog yn glwstwr, ac yna ychwanegu diswyddiad ychwanegol trwy ailadrodd ciwiau rhwng nodau lluosog. Fel hyn, os bydd un nod yn methu, nid ydym yn colli data ac yn parhau i fod ar gael.

Adlewyrchu ciw:

  • un prif ciw (meistr), sy'n derbyn yr holl orchmynion ysgrifennu a darllen
  • un neu fwy o ddrychau sy'n derbyn yr holl negeseuon a metadata o'r prif giw. Nid yw'r drychau hyn yno ar gyfer graddio, ond ar gyfer diswyddo yn unig.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 2. Adlewyrchu ciw

Gosodir adlewyrchu gan y polisi priodol. Ynddo gallwch ddewis y cyfernod atgynhyrchu a hyd yn oed y nodau y dylid lleoli'r ciw arnynt. Enghreifftiau:

  • ha-mode: all
  • ha-mode: exactly, ha-params: 2 (un meistr ac un drych)
  • ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Cadarnhad y cyhoeddwr

Er mwyn cyflawni recordiad cyson, mae angen Cadarnhau Publisher. Hebddynt, mae perygl o golli negeseuon. Anfonir cadarnhad at y cyhoeddwr ar ôl i'r neges gael ei hysgrifennu ar ddisg. Mae RabbitMQ yn ysgrifennu negeseuon i ddisg nid ar ôl eu derbyn, ond yn achlysurol, tua rhai cannoedd o filieiliadau. Pan fydd ciw yn cael ei adlewyrchu, dim ond ar ôl i bob drych ysgrifennu eu copi o'r neges i ddisg y anfonir cydnabyddiaeth. Mae hyn yn golygu bod defnyddio cadarnhad yn ychwanegu hwyrni, ond os yw diogelwch data yn bwysig, yna maent yn angenrheidiol.

Ciw methiant

Pan fydd brocer yn rhoi'r gorau iddi neu'n damwain, mae pob arweinydd ciw (meistr) ar y nod hwnnw'n damwain ynghyd ag ef. Yna mae'r clwstwr yn dewis drych hynaf pob meistr ac yn ei hyrwyddo fel y meistr newydd.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 3. Ciwiau a adlewyrchir lluosog a'u polisïau

Brocer 3 yn mynd i lawr. Sylwch fod y drych Ciw C ar Brocer 2 yn cael ei ddyrchafu i feistr. Sylwch hefyd fod drych newydd wedi'i greu ar gyfer Ciw C ar Brocer 1. Mae RabbitMQ bob amser yn ceisio cynnal y ffactor atgynhyrchu a nodir yn eich polisïau.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 4. Brocer 3 yn methu, gan achosi ciw C i fethu

Mae'r Brocer 1 nesaf yn disgyn! Dim ond un brocer sydd gennym ar ôl. Mae drych Ciw B yn cael ei ddyrchafu i feistr.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Ffig. Xnumx

Rydym wedi dychwelyd Brocer 1. Waeth pa mor dda y mae'r data yn goroesi colli ac adfer y brocer, mae'r holl negeseuon ciw a adlewyrchir yn cael eu taflu ar ailgychwyn. Mae hyn yn bwysig i'w nodi oherwydd bydd canlyniadau. Edrychwn ar y goblygiadau hyn yn fuan. Felly mae Brocer 1 bellach yn aelod o’r clwstwr eto, ac mae’r clwstwr yn ceisio cydymffurfio â’r polisïau ac felly’n creu drychau ar Brocer 1.

Yn yr achos hwn, roedd colli Brocer 1 yn gyflawn, fel yr oedd y data, felly collwyd y Ciw B heb ei ddrych yn llwyr.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 6. Brocer 1 yn dychwelyd i'r gwasanaeth

Mae Brocer 3 yn ôl ar-lein, felly mae ciwiau A a B yn dychwelyd y drychau a grëwyd arno i fodloni eu polisïau HA. Ond nawr mae'r holl brif giwiau ar un nod! Nid yw hyn yn ddelfrydol, mae dosbarthiad cyfartal rhwng nodau yn well. Yn anffodus, nid oes llawer o opsiynau yma ar gyfer ail-gydbwyso meistri. Byddwn yn dod yn ôl at y mater hwn yn ddiweddarach oherwydd mae angen inni edrych ar gydamseru ciw yn gyntaf.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 7. Brocer 3 yn dychwelyd i'r gwasanaeth. Pob prif giw ar un nod!

Felly nawr dylai fod gennych syniad o sut mae drychau yn darparu diswyddiad a goddefgarwch bai. Mae hyn yn sicrhau argaeledd os bydd un nod yn methu ac yn amddiffyn rhag colli data. Ond nid ydym wedi gwneud eto, oherwydd mewn gwirionedd mae'n llawer mwy cymhleth.

Syncing

Wrth greu drych newydd, bydd pob neges newydd bob amser yn cael ei hailadrodd i'r drych hwn ac unrhyw un arall. O ran y data presennol yn y ciw meistr, gallwn ei ailadrodd i ddrych newydd, sy'n dod yn gopi cyflawn o'r meistr. Gallwn hefyd ddewis peidio ag ailadrodd negeseuon presennol a gadael i'r prif giw a'r drych newydd gydgyfeirio mewn amser, gyda negeseuon newydd yn cyrraedd y gynffon a negeseuon presennol yn gadael pen y prif giw.

Perfformir y cydamseriad hwn yn awtomatig neu â llaw a chaiff ei reoli gan ddefnyddio polisi ciw. Gadewch i ni edrych ar enghraifft.

Mae gennym ddau giw drych. Mae Ciw A yn cael ei gydamseru'n awtomatig, ac mae Ciw B yn cael ei gydamseru â llaw. Mae'r ddau giw yn cynnwys deg neges.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 8. Dau giw gyda gwahanol ddulliau cydamseru

Nawr rydym yn colli Brocer 3.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 9. Syrthiodd Brocer 3

Brocer 3 yn dychwelyd i wasanaeth. Mae'r clwstwr yn creu drych ar gyfer pob ciw ar y nod newydd ac yn cydamseru'r Ciw A newydd yn awtomatig gyda'r meistr. Fodd bynnag, mae drych y Ciw B newydd yn parhau i fod yn wag. Fel hyn mae gennym ddiswyddiad llawn ar Ciw A a dim ond un drych ar gyfer negeseuon Ciw B presennol.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 10. Mae drych newydd Ciw A yn derbyn yr holl negeseuon sy'n bodoli, ond nid yw drych newydd Ciw B yn ei dderbyn.

Mae deg neges arall yn cyrraedd yn y ddau giw. Yna mae Brocer 2 yn cwympo ac mae Ciw A yn rholio yn ôl i'r drych hynaf, sydd ar Brocer 1. Nid oes unrhyw golli data pan fydd yn methu. Yn Ciw B, mae ugain neges yn y meistr a dim ond deg yn y drych oherwydd nid oedd y ciw hwn byth yn ailadrodd y deg neges wreiddiol.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 11. Mae Ciw A yn mynd yn ôl i Brocer 1 heb golli negeseuon

Mae deg neges arall yn cyrraedd yn y ddau giw. Nawr mae Brocer 1 yn chwalu. Mae Ciw A yn newid yn hawdd i'r drych heb golli negeseuon. Fodd bynnag, mae Ciw B yn cael problemau. Ar y pwynt hwn gallwn optimeiddio argaeledd neu gysondeb.

Os ydym am optimeiddio hygyrchedd, yna’r polisi ha-hyrwyddo-ar-methiant dylid ei osod yn bob amser yn. Dyma'r gwerth diofyn, felly ni allwch nodi'r polisi o gwbl. Yn yr achos hwn, rydym yn ei hanfod yn caniatáu methiannau mewn drychau heb eu cydamseru. Bydd hyn yn achosi i negeseuon gael eu colli, ond bydd y ciw yn parhau i fod yn ddarllenadwy ac yn ysgrifennadwy.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 12. Mae Ciw A yn cael ei rolio'n ôl i Brocer 3 heb golli negeseuon. Mae Ciw B yn mynd yn ôl i Brocer 3 gyda deg neges wedi'u colli

Gallwn hefyd osod ha-promote-on-failure i mewn i ystyr when-synced. Yn yr achos hwn, yn hytrach na dychwelyd i'r drych, bydd y ciw yn aros tan Brocer 1 gyda'i ddata yn dychwelyd i'r modd ar-lein. Ar ôl iddo ddychwelyd, mae'r prif giw yn ôl ar Broker 1 heb golli unrhyw ddata. Mae argaeledd yn cael ei aberthu ar gyfer diogelwch data. Ond mae hwn yn fodd peryglus a all hyd yn oed arwain at golli data yn llwyr, y byddwn yn edrych arno yn fuan.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 13. Nid yw Ciw B ar gael o hyd ar ôl colli Brocer 1

Efallai y byddwch yn gofyn, “A yw'n well peidio byth â defnyddio cydamseru awtomatig?” Yr ateb yw bod cydamseru yn weithrediad blocio. Yn ystod cydamseru, ni all y prif giw berfformio unrhyw weithrediadau darllen nac ysgrifennu!

Gadewch i ni edrych ar enghraifft. Nawr mae gennym ni giwiau hir iawn. Sut gallant dyfu i'r fath faint? Am sawl rheswm:

  • Ni ddefnyddir ciwiau yn weithredol
  • Mae'r rhain yn giwiau cyflym, ac ar hyn o bryd mae defnyddwyr yn araf
  • Mae'n giwiau cyflym iawn, bu glitch ac mae defnyddwyr yn dal i fyny

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 14. Dau giw mawr gyda gwahanol ddulliau cydamseru

Nawr mae Broker 3 yn disgyn.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 15. Brocer 3 yn disgyn, gan adael un meistr a drych ym mhob ciw

Brocer 3 yn dod yn ôl ar-lein a drychau newydd yn cael eu creu. Mae Prif Ciw A yn dechrau atgynhyrchu negeseuon presennol i'r drych newydd, ac yn ystod y cyfnod hwn nid yw'r Ciw ar gael. Mae'n cymryd dwy awr i ailadrodd y data, gan arwain at ddwy awr o amser segur ar gyfer y Ciw hwn!

Fodd bynnag, mae Ciw B yn parhau i fod ar gael trwy gydol y cyfnod. Aberthodd rywfaint o ddiswyddiad er mwyn hygyrchedd.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 16. Nid yw'r ciw ar gael yn ystod cydamseru

Ar ôl dwy awr, bydd Ciw A hefyd ar gael a gall ddechrau derbyn darlleniadau ac ysgrifennu eto.

Diweddariadau

Mae'r ymddygiad blocio hwn yn ystod cydamseru yn ei gwneud hi'n anodd diweddaru clystyrau gyda chiwiau mawr iawn. Ar ryw adeg, mae angen ailgychwyn y prif nod, sy'n golygu naill ai newid i ddrych neu analluogi'r ciw tra bod y gweinydd yn cael ei uwchraddio. Os byddwn yn dewis trosglwyddo, byddwn yn colli negeseuon os nad yw'r drychau wedi'u cysoni. Yn ddiofyn, yn ystod toriad brocer, ni chyflawnir methiant i ddrych heb ei gydamseru. Mae hyn yn golygu, cyn gynted ag y bydd y brocer yn dychwelyd, nid ydym yn colli unrhyw negeseuon, yr unig ddifrod oedd ciw syml. Mae rheolau ymddygiad pan fydd brocer yn cael ei ddatgysylltu yn cael eu gosod gan bolisi ha-promote-on-shutdown. Gallwch chi osod un o ddau werth:

  • always= mae trawsnewid i ddrychau heb eu cydamseru wedi'i alluogi
  • when-synced= trawsnewid i ddrych cydamserol yn unig, fel arall mae'r ciw yn dod yn annarllenadwy ac yn anysgrifenadwy. Mae'r ciw yn dychwelyd i wasanaeth cyn gynted ag y bydd y brocer yn dychwelyd

Un ffordd neu'r llall, gyda chiwiau mawr mae'n rhaid i chi ddewis rhwng colli data a diffyg argaeledd.

Pan fydd Argaeledd yn Gwella Diogelwch Data

Mae un cymhlethdod arall i'w ystyried cyn gwneud penderfyniad. Er bod cydamseru awtomatig yn well ar gyfer dileu swyddi, sut mae'n effeithio ar ddiogelwch data? Wrth gwrs, gyda gwell diswyddo, mae RabbitMQ yn llai tebygol o golli negeseuon presennol, ond beth am negeseuon newydd gan gyhoeddwyr?

Yma mae angen ichi ystyried y canlynol:

  • A allai'r 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 mai dim ond y neges y gall y cyhoeddwr ei thaflu, yna mewn gwirionedd, mae gwella hygyrchedd hefyd yn gwella diogelwch data.

Felly, rhaid ceisio cydbwysedd, ac mae'r ateb yn dibynnu ar y sefyllfa benodol.

Problemau gyda ha-promote-on-failure=pan wedi'i gysoni

Syniad ha-hyrwyddo-ar-methiant= pan-synced yw ein bod yn atal newid i ddrych heb ei gydamseru a thrwy hynny osgoi colli data. Mae'r ciw yn parhau i fod yn annarllenadwy neu ysgrifennadwy. Yn lle hynny, rydym yn ceisio adennill y brocer damwain gyda'i ddata yn gyfan fel y gall ailddechrau gweithredu fel meistr heb golli data.

Ond (ac mae hwn yn ond mawr) os yw'r brocer wedi colli ei ddata, yna mae gennym broblem fawr: mae'r ciw yn cael ei golli! Mae'r holl ddata wedi diflannu! Hyd yn oed os oes gennych chi ddrychau sy'n dal i fyny â'r prif giw yn bennaf, mae'r drychau hynny'n cael eu taflu hefyd.

I ail-ychwanegu nod gyda'r un enw, dywedwn wrth y clwstwr i anghofio'r nod coll (gyda'r gorchymyn rabbitmqctl forget_cluster_node) a dechrau brocer newydd gyda'r un enw gwesteiwr. Tra bod y clwstwr yn cofio’r nôd coll, mae’n cofio’r hen giw a drychau heb eu cydamseru. Pan ddywedir wrth glwstwr am anghofio nôd amddifad, anghofir y ciw hwnnw hefyd. Nawr mae angen inni ei ailddatgan. Collasom yr holl ddata, er bod gennym ddrychau gyda set rannol o ddata. Byddai'n well newid i ddrych heb ei gydamseru!

Felly, cydamseru â llaw (a methiant i gydamseru) ar y cyd â ha-promote-on-failure=when-synced, yn fy marn i, yn eithaf peryglus. Mae'r dogfennau'n dweud bod yr opsiwn hwn yn bodoli ar gyfer diogelwch data, ond mae'n gyllell ag ymyl dwbl.

Ail-gydbwyso meistr

Fel yr addawyd, rydym yn dychwelyd at y broblem o grynhoi'r holl feistri ar un neu nifer o nodau. Gall hyn hyd yn oed ddigwydd o ganlyniad i ddiweddariad clwstwr treigl. Mewn clwstwr tri nod, bydd pob ciw meistr yn cronni ar un neu ddau nod.

Gall meistri ail-gydbwyso fod yn broblemus am ddau reswm:

  • Nid oes unrhyw offer da i berfformio ail-gydbwyso
  • Cydamseru ciw

Mae trydydd parti ar gyfer ail-gydbwyso ategyn, nad yw'n cael ei gefnogi'n swyddogol. Ynghylch ategion trydydd parti yn llawlyfr RabbitMQ Dywedodd: “Mae'r ategyn yn darparu rhai offer cyfluniad ac adrodd ychwanegol, ond nid yw'n cael ei gefnogi na'i wirio gan dîm RabbitMQ. Defnyddiwch ar eich menter eich hun."

Mae tric arall i symud y prif giw drwy bolisïau HA. Mae'r llawlyfr yn sôn sgript am hyn. Mae'n gweithio fel hyn:

  • Cael gwared ar yr holl ddrychau gan ddefnyddio polisi dros dro sydd â blaenoriaeth uwch na'r polisi HA presennol.
  • Yn newid polisi dros dro HA i ddefnyddio modd nod, gan nodi'r nod y dylid trosglwyddo'r ciw meistr iddo.
  • Yn cydamseru'r ciw ar gyfer mudo gwthio.
  • Ar ôl i'r mudo gael ei gwblhau, yn dileu'r polisi dros dro. Daw'r polisi HA cychwynnol i rym a chaiff y nifer ofynnol o ddrychau ei greu.

Yr anfantais yw efallai na fydd y dull hwn yn gweithio os oes gennych giwiau mawr neu ofynion dileu swydd llym.

Nawr, gadewch i ni weld sut mae clystyrau RabbitMQ yn gweithio gyda rhaniadau rhwydwaith.

Colli cysylltedd

Mae nodau system ddosbarthedig yn cael eu cysylltu gan gysylltiadau rhwydwaith, a gall ac fe fydd cysylltiadau rhwydwaith yn cael eu datgysylltu. Mae amlder toriadau yn dibynnu ar y seilwaith lleol neu ddibynadwyedd y cwmwl a ddewiswyd. Mewn unrhyw achos, rhaid i systemau gwasgaredig allu ymdopi â nhw. Unwaith eto mae gennym ddewis rhwng argaeledd a chysondeb, ac unwaith eto y newyddion da yw bod RabbitMQ yn darparu'r ddau opsiwn (dim ond nid ar yr un pryd).

Gyda RabbitMQ mae gennym ddau brif opsiwn:

  • Caniatáu rhaniad rhesymegol (hollt-ymennydd). Mae hyn yn sicrhau argaeledd, ond gall achosi colli data.
  • Analluogi gwahaniad rhesymegol. Gall arwain at golli argaeledd yn y tymor byr yn dibynnu ar sut mae cleientiaid yn cysylltu â'r clwstwr. Gall hefyd arwain at ddiffyg argaeledd llwyr mewn clwstwr dau nod.

Ond beth yw gwahaniad rhesymegol? Dyma pryd mae clwstwr yn rhannu'n ddau oherwydd colli cysylltiadau rhwydwaith. Ar bob ochr, mae'r drychau'n cael eu dyrchafu i feistr, fel bod yna sawl meistr fesul tro yn y pen draw.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 17. Prif giw a dau ddrych, pob un ar nod ar wahân. Yna mae methiant rhwydwaith yn digwydd ac mae un drych yn dod yn ddatgysylltiedig. Mae'r nod gwahanedig yn gweld bod y ddau arall wedi cwympo i ffwrdd ac yn hyrwyddo ei ddrychau i'r meistr. Bellach mae gennym ddau brif giw, yn ysgrifenadwy ac yn ddarllenadwy.

Os bydd cyhoeddwyr yn anfon data at y ddau feistr, bydd gennym ddau gopi gwahanol o'r ciw yn y pen draw.

Mae gwahanol foddau RabbitMQ yn darparu naill ai argaeledd neu gysondeb.

Anwybyddu modd (diofyn)

Mae'r modd hwn yn sicrhau hygyrchedd. Ar ôl colli cysylltedd, mae gwahaniad rhesymegol yn digwydd. Ar ôl adfer cysylltedd, rhaid i'r gweinyddwr benderfynu pa raniad i roi blaenoriaeth iddo. Bydd yr ochr golli yn cael ei ailgychwyn a bydd yr holl ddata cronedig ar yr ochr honno yn cael ei golli.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 18. Mae tri chyhoeddwr yn gysylltiedig â thri brocer. Yn fewnol, mae’r clwstwr yn cyfeirio pob cais i’r prif giw ar Brocer 2.

Nawr rydym yn colli Brocer 3. Mae'n gweld bod broceriaid eraill wedi cwympo i ffwrdd ac yn hyrwyddo ei ddrych i'r meistr. Dyma sut mae gwahaniad rhesymegol yn digwydd.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 19. Rhaniad rhesymegol (hollt-ymennydd). Mae cofnodion yn mynd i ddau brif giw, ac mae'r ddau gopi yn ymwahanu.

Mae cysylltedd yn cael ei adfer, ond erys gwahaniad rhesymegol. Rhaid i'r gweinyddwr ddewis yr ochr sy'n colli â llaw. Yn yr achos isod, mae'r gweinyddwr yn ailgychwyn Brocer 3. Mae'r holl negeseuon na lwyddodd i'w trosglwyddo yn cael eu colli.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 20. Mae'r gweinyddwr yn analluogi Brocer 3.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 21. Mae'r gweinyddwr yn cychwyn Broker 3 ac mae'n ymuno â'r clwstwr, gan golli'r holl negeseuon a adawyd yno.

Yn ystod colli cysylltedd ac ar ôl ei adfer, roedd y clwstwr a'r ciw hwn ar gael ar gyfer darllen ac ysgrifennu.

Modd awto-iacháu

Yn gweithio'n debyg i'r modd Anwybyddu, ac eithrio bod y clwstwr ei hun yn dewis yr ochr sy'n colli yn awtomatig ar ôl hollti ac adfer cysylltedd. Mae'r ochr sy'n colli yn dychwelyd i'r clwstwr yn wag, ac mae'r ciw yn colli pob neges a anfonwyd i'r ochr honno yn unig.

Seibio Modd Lleiafrifol

Os nad ydym am ganiatáu rhaniad rhesymegol, yna ein hunig opsiwn yw taflu darlleniadau ac ysgrifennu ar yr ochr lai ar ôl y rhaniad clwstwr. Pan fydd y brocer yn gweld ei fod ar yr ochr lai, mae'n atal gwaith, hynny yw, mae'n cau'r holl gysylltiadau presennol ac yn gwrthod unrhyw rai newydd. Unwaith yr eiliad mae'n gwirio am adfer cysylltedd. Unwaith y bydd cysylltedd yn cael ei adfer, mae'n ailddechrau gweithredu ac yn ymuno â'r clwstwr.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 22. Mae tri chyhoeddwr yn gysylltiedig â thri brocer. Yn fewnol, mae’r clwstwr yn cyfeirio pob cais i’r prif giw ar Brocer 2.

Yna mae broceriaid 1 a 2 yn rhannu oddi wrth Brocer 3. Yn hytrach na hyrwyddo eu drych i feistroli, mae Brocer 3 yn atal ac yn dod yn ddim ar gael.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 23. Mae Brocer 3 yn seibio, yn datgysylltu pob cleient, ac yn gwrthod ceisiadau cysylltiad.

Unwaith y bydd cysylltedd yn cael ei adfer, mae'n dychwelyd i'r clwstwr.

Edrychwn ar enghraifft arall lle mae'r prif giw ar Brocer 3.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 24. Prif giw ar Brocer 3 .

Yna mae'r un golled o gysylltedd yn digwydd. Mae Brocer 3 yn oedi oherwydd ei fod ar yr ochr lai. Ar yr ochr arall, mae'r nodau'n gweld bod Brocer 3 wedi cwympo i ffwrdd, felly mae'r drych hŷn o Broceriaid 1 a 2 yn cael ei hyrwyddo i feistroli.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 25. Pontio i Brocer 2 os nad yw Brocer 3 ar gael.

Pan fydd cysylltedd yn cael ei adfer, bydd Broker 3 yn ymuno â'r clwstwr.

RabbitMQ vs Kafka: Goddefgarwch Nam ac Argaeledd Uchel mewn Clystyrau
Reis. 26. Mae'r clwstwr wedi dychwelyd i weithrediad arferol.

Y peth pwysig i'w ddeall yma yw ein bod yn cael cysondeb, ond gallwn hefyd gael argaeledd, os Byddwn yn trosglwyddo cleientiaid yn llwyddiannus i'r rhan fwyaf o'r adran. Ar gyfer y rhan fwyaf o sefyllfaoedd, byddwn yn bersonol yn dewis y modd Lleiafrifol Saib, ond mae'n dibynnu mewn gwirionedd ar yr achos unigol.

Er mwyn sicrhau argaeledd, mae'n bwysig sicrhau bod cleientiaid yn cysylltu'n llwyddiannus â'r gwesteiwr. Gadewch i ni edrych ar ein hopsiynau.

Sicrhau Cysylltedd Cwsmeriaid

Mae gennym nifer o opsiynau ar gyfer sut i gyfeirio cleientiaid at brif ran y clwstwr neu at nodau gweithio (ar ôl i un nod fethu) ar ôl colli cysylltedd. Yn gyntaf, gadewch i ni gofio bod ciw penodol yn cael ei gynnal ar nod penodol, ond mae llwybro a pholisïau yn cael eu hailadrodd ar draws pob nod. Gall cleientiaid gysylltu ag unrhyw nod, a bydd llwybro mewnol yn eu cyfeirio lle mae angen iddynt fynd. Ond pan fydd nod yn cael ei atal, mae'n gwrthod cysylltiadau, felly mae'n rhaid i gleientiaid gysylltu â nod arall. Os bydd y nod yn disgyn i ffwrdd, nid oes llawer y gall ei wneud o gwbl.

Ein hopsiynau:

  • Ceir mynediad i'r clwstwr gan ddefnyddio cydbwysydd llwyth sy'n beicio trwy'r nodau ac mae cleientiaid yn ceisio cysylltu eto nes yn llwyddiannus. Os yw nod wedi'i ostwng neu wedi'i atal, yna bydd ymdrechion i gysylltu â'r nod hwnnw'n methu, ond bydd ymdrechion dilynol yn mynd i weinyddion eraill (mewn dull crwn-robin). Mae hyn yn addas ar gyfer colli cysylltedd yn y tymor byr neu weinydd wedi'i ostwng a fydd yn dod yn ôl yn gyflym.
  • Cyrchwch y clwstwr trwy gydbwysydd llwyth a thynnwch nodau crog/methedig oddi ar y rhestr cyn gynted ag y cânt eu canfod. Os byddwn yn gwneud hyn yn gyflym, ac os yw cleientiaid yn gallu rhoi cynnig arall ar y cysylltiad, yna byddwn yn sicrhau argaeledd cyson.
  • Rhowch restr o'r holl nodau i bob cleient, ac mae'r cleient yn dewis un ohonynt ar hap wrth gysylltu. Os yw'n derbyn gwall wrth geisio cysylltu, mae'n symud i'r nod nesaf yn y rhestr nes ei fod yn cysylltu.
  • Tynnwch draffig o nod a fethwyd/ataliwyd gan ddefnyddio DNS. Gwneir hyn gan ddefnyddio TTL bach.

Canfyddiadau

Mae gan glystyru RabbitMQ ei fanteision a'i anfanteision. Yr anfanteision mwyaf difrifol yw:

  • wrth ymuno â chlwstwr, mae nodau'n taflu eu data;
  • mae blocio cydamseru yn achosi i'r ciw ddod yn ddim ar gael.

Mae pob penderfyniad anodd yn deillio o'r ddwy nodwedd bensaernïol hyn. Pe gallai RabbitMQ arbed data pan fydd y clwstwr yn ailymuno, yna byddai'r cydamseru yn gyflymach. Pe bai'n gallu cydamseru heb rwystro, byddai'n well cynnal ciwiau mawr. Byddai trwsio'r ddau fater hyn yn gwella perfformiad RabbitMQ yn fawr fel technoleg negeseuon sy'n gallu goddef diffygion ac sydd ar gael yn fawr. Byddwn yn betrusgar i argymell RabbitMQ gyda chlystyru yn y sefyllfaoedd canlynol:

  • Rhwydwaith annibynadwy.
  • Storfa annibynadwy.
  • Ciwiau hir iawn.

O ran gosodiadau argaeledd uchel, ystyriwch y canlynol:

  • ha-promote-on-failure=always
  • ha-sync-mode=manual
  • cluster_partition_handling=ignore (Neu autoheal)
  • negeseuon parhaus
  • sicrhau bod cleientiaid yn cysylltu â'r nod gweithredol pan fydd rhai nod yn methu

Er cysondeb (diogelwch data), ystyriwch y gosodiadau canlynol:

  • Cyhoeddwr yn Cadarnhau a Chydnabyddiaethau â Llaw ar ochr y defnyddiwr
  • ha-promote-on-failure=when-synced, os gall y cyhoeddwyr roi cynnig arall arni yn nes ymlaen ac os oes gennych chi storfa ddibynadwy iawn! Fel arall rhowch =always.
  • ha-sync-mode=automatic (ond ar gyfer ciwiau mawr anweithredol efallai y bydd angen modd â llaw; ystyriwch hefyd a fydd diffyg argaeledd yn achosi i negeseuon gael eu colli)
  • Seibio modd Lleiafrifol
  • negeseuon parhaus

Nid ydym wedi ymdrin â'r holl faterion yn ymwneud â goddef diffygion ac argaeledd uchel eto; er enghraifft, sut i gyflawni gweithdrefnau gweinyddol yn ddiogel (fel diweddariadau treigl). Mae angen i ni hefyd siarad am ffedereiddio a'r ategyn Shovel.

Os ydw i wedi methu unrhyw beth arall, rhowch wybod i mi.

Gweler hefyd fy post, lle rwy'n perfformio hafoc ar glwstwr RabbitMQ gan ddefnyddio Docker a Blockade i brofi rhai o'r senarios colli neges a ddisgrifir yn yr erthygl hon.

Erthyglau blaenorol yn y gyfres:
Rhif 1 - habr.com/ru/company/itsumma/blog/416629
Rhif 2 - habr.com/ru/company/itsumma/blog/418389
Rhif 3 - habr.com/ru/company/itsumma/blog/437446

Ffynhonnell: hab.com

Ychwanegu sylw