Culpa tolerantia et promptitudo magna sunt argumenta, ergo singulas articulos RabbitMQ et Kafka dabimus. Hic articulus est de RabbitMQ, et proximus est de Kafka, prae RabbitMQ. Longum est articulus, fac te ipsum consolatorem.

Intueamur culpam tolerantiae, constantiae, et promptitudinis (HA) consilia et negotiationes, quae unumquodque consilium facit. RabbitMQ currere potest in botrum nodis - et tunc indicatur ut systema distributum. Cum ad systemata distributa, de constantia et promptitudine saepe loquimur.

Notiones hae describunt quomodo systema se gerit cum deficit. Connexio retis defectus, defectus servientis, defectus ferreus coegi, servitor temporalis necessariae ob purgamentum collectionis, fasciculus damnum, nexus retis vel retardationis. Haec omnia possunt ad damna vel certamina data. Evenit ut vix impossibile sit systema ponere, quod et omnino consentaneum est (nullum detrimentum notitiae, nulla notitia disiunctionis) et promptum (legit et scribens acceptabit) omnibus missionibus defectum.

Videbimus constantiam et promptitudinem in extremis spectri oppositis, et quem ad optimize modum eligere debes. Evangelium est quod apud RabbitMQ haec electio fieri potest. Habetis huiusmodi vectium "nerdy" ut stateram ad maiorem constantiam vel maiorem accessibilitatem transferat.

Sedulo operam dabimus quibus conformationes ad iacturam notitiarum ex monumentis confirmatis conducunt. Vincula officiorum inter editores, sectores et consumerent. Cum nuntius ad sectorem transmittitur, eius officium est nuntium non amittere. Cum sector agnoscat acceptilationem editoris nuntium, non exspectamus amissum esse. Sed videbimus hoc fieri posse secundum typum tuum sectorem et publisher.

Unius Node Resilientiae Primitivae

Queuing molles / Routing

Queues in RabbitMQ sunt duo genera: durabile et non durabile. Omnes queues in datorum Mnesia servatae sunt. Queues durabiles initio nodi proscriptae sunt et sic supersunt restarts, fragores systematis seu fragores servo (dummodo perseveret notitia). Hoc significat quod dum declaras fundere (commutationem) et queue mollem esse, queuing/fusura infrastructuram online revertetur.

Queues volatilia et fugata tolluntur cum nodi restarted.

Pertinax nuntia

Quia queue durabile non significat quod omnes nuntii eius superstes nodi sileo. Tantum epistulae ab editore positae Suscepit (pertinax). Epistulae assiduae additamentum onus in sectorem creant, sed si nuntius damni acceptus est, tunc optio nulla alia est.

Renatus. 1. Sustineri matrix

Ictibus queue speculum

Damnum sectoris superesse, redundantia opus est. Multiplices nodos RabbitMQ in botrum coniungere possumus, ac deinde additam addere nugationem per queues multiplices inter nodos replicando. Hoc modo, si nodi unus deficiat, notitias non amittimus et in promptu manemus.

Queue referret:

• una principalis queue, quae omnia scribat et imperata accipit
• unum vel plura specula, quae omnia mandata et metadata ab alto queue recipiunt. Haec specula ibi non sunt ad scalas, sed ad purum redundantiam.

Renatus. 2. Queue speculum

Speculum apto consilio positum est. In eo eligere potes replicationem coefficiens et etiam nodos in quibus collocari debet queue. Exempla:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (Unus dominus et unus Speculum)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Publisher confirmatio

Ad consistent recordationem, Publisher Confirms requiruntur. Sine illis periculum est epistulae amissae. Confirmatio editori mittitur postquam nuntius in disco scriptus est. RabbitMQ epistulas scribit ad disci non in recepcione, sed in fundamento periodico, in regione plurium millium milium secundorum centum. Cum queue speculatur, agnitio solum mittitur postquam omnia specula etiam eorum exemplar nuntii in disco scripserunt. Hoc significat utens confirmationibus latentiam adiungit, sed si notitia securitatis momenti est, tunc necessaria sunt.

Failover queue

Cum sector cedit aut fragore, omnes duces queue in illa node una cum ea fragore. Botrus ergo speculum vetustissimum cuiusque magistri eligit et quasi novum magistrum promovet.

Renatus. 3. Multiplex speculi queues et consilia

Sectorem III descendentis. Nota quod queue C speculum in Broker 3 promovetur ad dominum. Nota etiam quod novum speculum pro Queue C in Broker creatum est 2. RabbitMQ semper conatus est ponere replicationem factoris in tuis agendis definitis.

Renatus. 4. Sectorem 3 deficit, queue C deficere facit

Proximus cocio 1 cadit! Solum habemus unum sectorem dereliquit. Queue B Speculum ad magistrum promotus.

Vide Fig. 5

Reddimus sectorem 1. Quantumvis bene notitia supersit damnum et recuperatio sectoris, omnes speculati nuntii reiciuntur in sileo. Haec notare oportet, quia consequentia erunt. Has effectus mox videbimus. Itaque cocio 1 nunc membrum botri iterum est, et botrus consiliis parere conatur et ideo specula in cocio 1 creat.

In hoc casu, amissio Sectoris 1 perfecta est, ut erat notitia, ita indubitata Queue B funditus amissa est.

Renatus. 6. Sectorem I redit ad servitium

Broker 3 online est retro, ut queues A et B specula in ea creata redire ad rationes suas HA satisfaciant. Nunc autem omnes principales queues in una node! Hoc non est specimen, melior est etiam distributio nodis. Infeliciter, non multum bene hic sunt dominos rebalancendi. Reveniemus ad hanc quaestionem postea quia oportet quaerere queue synchronisation prius.

Renatus. 7. Cocio 3 redit in servitutem. Omnes principales queues in una node!

Nunc ergo debes habere ideam quomodo specula praebent redundantiam et culpae tolerantiam. Hoc disponibilitate praestat in eventu unius nodi defectus et contra data detrimenta tutatur. Sed tamen non fit, quia re ipsa multo magis implicata est.

synchronization

Cum novum speculum creando, omnes novae nuntia semper huic speculo et quibusvis aliis repplicabuntur. Data in domino queue existente, illud novum speculum replicare possumus, quod totum exemplum domini fit. Possumus etiam eligere non nuntios existentium replicare et principale queue et novum speculum in tempore convenire, cum nuntiis novis ad caudam venientibus nuntiis existens et caput principalis queue relinquens.

Synchronisatio haec automatice vel manually conficitur et consilio queue utendo administratur. Intueamur exemplum.

We have two speculos queues. Queue A automatice synchronizatur, et Queue B manually synchronised est. Ambae queues decem epistulas continent.

Renatus. 8. Duae stantibus anteponere cum diversis modis synchronisation

qus nunc nos cocio III.

Renatus. 9. Cocio 3 fell

Cocio III reddit ad seruicium. Botrus speculum in singulis queue in novo nodo creat et automatice novam Queue A cum magistro conformat. Sed speculum novae Queue B vacuum manet. Hoc modo plenam redundantiam habemus in Queue A et unum tantum speculum pro nuntiis Queue B existentibus.

Renatus. 10. Novum speculum Queue A omnes nuntios existentes accipit, sed novum speculum Queue B non habet.

Decem plures nuntii in utraque queues perveniunt. Sectorem 2 deinde inruerit et Queue A ad speculum vetustissimum revertitur, quod in Broker 1. Nulla notitia damni est cum deficit. In Queue B viginti nuntii in domino sunt et tantum decem in speculo, quia haec queue decem nuntiis originalibus numquam replicatur.

Renatus. 11. Queue A volvitur ad Sectorem 1 sine nuntiis amissis

Decem plures nuntii in utraque queues perveniunt. Nunc Broker 1 inruerit, Queue A facile permutat speculum sine nuntiis amissis. Sed queue B problemata habet. Hic optimize vel promptitudinis vel constantiae possumus.

Si accessibilitate optimize velimus, consilium ha-promote-in-defectum debet institui semper. Hoc est valorem default, ergo consilium omnino definire non potes. In hoc casu, per se defecta in speculis unsynchronised. Haec epistulae causa amissae erunt, sed queue lectissima et writable remanebit.

Renatus. 12. Queue A revolvitur ad Sectorem 3 sine nuntiis amissis. Queue B revertitur ad Brokerum 3 cum decem nuntiis amissis

Etiam install possumus ha-promote-on-failure in significatione when-synced. In hoc casu, loco ad speculum revolutum, exspectabit queue donec Broker 1 cum suis data notitia ad modum online redit. Postquam redit, summa queue in Broker 1 sine ullo dato detrimento revertitur. Availability immolatur pro notitia securitatis. Sed hic modus est periculosus qui etiam ad plenam notitiarum iacturam ducere potest, quod mox inspiciemus.

Renatus. 13. Queue B manet unavailable amissis Sectorem 1

Quaeres fortasse: "Numquam melius est ut ipsa synchronisatione automataria utatur?" Dicendum est quod synchronisatio est operatio interclusio. In synchronisation, principale queue operationes legere vel scribere non potest!

Intueamur exemplum. Nunc ipsum diu queues habemus. Quomodo crescunt in tantam magnitudinem? Pluribus de causis;

• Queues sunt active usus
• Haec sunt alta velocitate queues et nunc usores sunt tardi
• Summus celeritas queues, glitch et consumers captas fuerunt

Renatus. 14. Duae magnae Queues cum diversis modis synchronisation

Nunc Cocio 3 cadit.

Renatus. 15. Cocio 3 cadit, relicto domino et speculo in unaquaque queue

Broker 3 redit online et specula nova creantur. Praecipua Queue A nuntiis ad novum speculum replicare incipit, et per hoc tempus perpendat Queue. Duas horas accipit ad datam replicare, inde in duabus horis huius temporis pro Queue!

Queue B tamen per totam periodum in promptu manet. Immolabat aliquam redundantiam pro accessibilitate.

Renatus. 16. Queue manet in synchronisation unavailable

Post duas horas, Queue A praesto fit et recipere potest et iterum legit et scribit.

updating

Mores interclusio haec in synchronisation facit difficilem ligaturas renovare cum amplissimis queues. In aliquo puncto, dominus nodi debet sileo, quod significat vel mutandi ad speculum vel inactivare queue dum servo upgraded est. Si transitum voluerimus, nuntios amittemus si speculorum non congruens est. Defalta, in eu ipsum sectorem, defectus in speculo unsynchronizato non perficitur. Id quod statim cum sectorem redit, nuntiis non amittimus, solum damnum simplex fuit queue. Regulae se gerendi cum sector disiuncta sunt, per consilium constituuntur ha-promote-on-shutdown. Unum e duobus valoribus potes ponere:

• always= Transitus ad unsynchronized speculorum est enabled
• when-synced= transitus ad speculum synchronum tantum, secus queue unreadable et unwritebilis fit. Queue ad officium redit simul ac sectorem redit

Uno modo vel alio, cum magna Queues eligendi data inter damna et unavailability.

Cum Availability Improves Data Securitatis

Complicatio est magis considerare antequam decernat. Dum automatic synchronisation melius est redundantia, quomodo incursum notitia securitatis? Scilicet, meliori redundantia, RabbitMQ minus probabile est nuntios exstantes perdere, sed quid de novis nuntiis ab editoribus?

Hic debes considerare quae sequuntur:

• Possetne editor simpliciter errorem reddere et habere officium fluminis vel usoris postea iterum tenta?
• publisher potestne nuntium servare in loco vel in database postea iterum tentare?

Si editor solum nuntium deponere potest, re vera, accessibilitas meliori etiam securitatem notitias ampliat.

Ita petenda est trutina, et a specifica situ pendet solutio.

Problems with ha-prome-in-defectum = when-synced

idea ha-promote-in-defectum= quando-synced est ut in speculo unsynchronised commutatione prohibeamus et per hoc notitia detrimentum vitemus. Queue unreadable vel writable manet. Sed conamur integrum sectorem recuperare cum notitia sua ut dominus sine notitia damni reuocare possit.

Sed (et hoc magnum est sed) si sectorem notitia sua perdidit, magna quaestio habemus: queue periit! Omnis notitia abiit! Etiamsi specula quae maxime adsequi queunt, ea quoque specula depelluntur.

Nodem addere eodem nomine, botrum dicimus ut nodi amissae obliviscantur (cum mandato lepmqctl forget_cluster_node) et novum sectorem incipiunt cum eodem hostname. Dum botrus meminit amissi nodi, veteris meminit queue et speculorum discolorato. Cum botrus dicitur oblivisci nodi orphani, queue etiam oblitus est. Nunc opus est ut re- nuntiemus. Data omnia perdidimus, licet specula cum parte data copia habuimus. Utilius est ad speculum non synchronisatum vertas!

Ergo synchronisation manualis (et defectionem synchronizare) in compositione cum ha-promote-on-failure=when-syncedut mea fert opinio, satis periculosum est. Doces dicunt hanc optionem securitatis datae esse, sed cultrum ancipitem esse.

Magister rebalancing

Promissa ad quaestionem de cumulationis omnium magistrorum uno vel pluribus nodis revertimur. Id evenire etiam potest propter renovationem botri volubilem. In tres nodi botrus, omnes magistri queues in unum vel duos nodos coacervabunt.

Magistris rebalantibus problematicum esse potest duabus de causis:

• Instrumenta bona non sunt ad faciendum rebalancing
• Queue synchronisation

Est tertia pars pro rebalancing pluginquae publice non sustinetur. De tertia parte plugins in RabbitMQ manuali dixit: “ Plugin praebet aliquid additi configurationis et instrumenta nuntiandi, sed non confirmatur vel verificatur per turmas RabbitMQ. Utere periculo tuo".

Est alia dolus movendi principale queue per HA lobortis. Manuale commemorat scriptum quia haec. Hoc sic facit:

• Omnia specula removet utens consilium temporale quod altiorem habet rationem quam consilium HA existens.
• HA ad tempus consilium mutat modum nodi utendi, specificans nodi ad quem dominus queue transferri debet.
• Synchronizes queue pro dis migrationibus.
• Postquam migratio perfecta est, consilium temporale delet. Initialis HA consilium effectum habet et numerus speculorum inquisitus creatus est.

In downside est ut accessus non possit operari si magna queues vel stricta nugatio requisita est.

Nunc videamus quomodo Racemi RabbitMQ operantur cum partitionibus retis.

Damnum connectivity

Nodi systematis distributi per nexus retis coniunguntur, et nexus retis disiungi possunt et disiungi possunt. Frequentia outages dependet ab infrastructura locali vel firmitate nubis delectae. Quoquo modo, systemata distributa cum illis obire poterit. Iterum electio inter promptitudinem et constantiam habemus, iterumque bonum nuntium est quod RabbitMQ utraque optiones praebet (sicut non simul).

Apud RabbitMQ habemus duas optiones principales:

• Patitur logica divisio (split-brain). Hoc disponibilitate praestat, sed notitia damnum causare potest.
• Inactivare logicam separationem. Proveniat in brevi-terminus iactura promptitudinis secundum quam clientes ad botrum iungunt. Potest etiam ducere ad perficiendam unavabilitatem in duplici nodo botri.

Sed quid est separatio logica? Hoc est, cum botrus scinditur in duas ob damnum nexus retis. Utrimque specula ad magistrum promoventur, ita ut tandem plures magistri vicissim sint.

Renatus. 17. Praecipua queue et duo specula, singula in nodo separato. Tum retis defectus incidit et unum speculum seiungitur. Nodus separatus videt duos alios cecidisse, et specula sua ad dominum promovere. Nunc habemus duas principales queues, tam writable quam lectabiles.

Si editores utrique magistros datas miserunt, cum duobus exemplaribus divergentibus queue finire debemus.

Diversi modos RabbitMQ praebent vel promptitudinem vel constantiam.

Modus ignorare (default)

Hic modus accessibilitatem efficit. Post amissionem connectivity, logica separatio fit. Recepta connectivity, administrator decernere debet uter partitio priora reddatur. Parte amissa restituetur et omnis notitia congesta inde amittetur.

Renatus. 18. Tres editores cum tribus sectoribus adiuncti sunt. Interne, botrus ambages omnes petitiones principales queue in Broker II.

Nunc amittimus sectorem 3. Videt alios sectores excidisse et speculum suum ad dominum promovere. Ita fit separatio logica.

Renatus. 19. Logica divisio (split-brain). Tabulae in duas principales queues intrant, et duo exemplaria divergunt.

Connectivity is restauratur, sed separatio logica manet. Administrator manualiter partem amissam eligere debet. In casu infra, administrator reboot Broker 3. Omnes nuntii, qui eum transmittere non curaverunt, pereunt.

Renatus. 20. Administrator disable Broker III.

Renatus. 21. Administrator coctor incipit 3 et ei botrum coniungit, amissis omnibus nuntiis, qui ibi relicti sunt.

Per connectivity amissionem et post restitutionem, glomerus et haec queue legendi et scribendi praesto fuerunt.

Autoheal modus

Simili modo ad Ignorare modum operatur, nisi quod ipse botrus sponte eligat partem amissam post connectivity scindendo et restaurando. Latus amissus redit ad botrum vacuum, et queue permittit omnes nuntios, qui tantum ad eam partem missi sunt.

Declina Minoritas Modus

Si partitionem logicam pati nolumus, tunc unica optio nostra in minore parte post partitionem glomerorum legit et scribit abiiciendi. Cum sector in parte minor esse viderit, opus suspendit, id est, omnes nexus exsistentes claudit et aliquas novas recusat. Semel iterumque inhibet restitutionem ad connectivity. Postquam connectivity restaurata, operationem resumit et botrum iungit.

Renatus. 22. Tres editores cum tribus sectoribus adiuncti sunt. Interne, botrus ambages omnes petitiones principales queue in Broker II.

Sectores 1 et 2 tunc finduntur a Broker 3. Loco speculum suum ad dominum promovendum, Broker 3 suspendit et fit unavailable.

Renatus. 23. Cocio 3 propinare, omnes clientes adimit, nexum petitionum respuit.

Postquam connectivity restituitur, ad botrum redit.

Intueamur aliud exemplum ubi summa queue in Broker 3 est.

Renatus. 24. Main queue on Broker III.

Deinde idem fit de damno connectivity. Cocio 3 propinatur, quia in minore parte est. Parte altera, nodi vident sectorem 3 excidisse, ut speculum vetustius a Brokero 1 et 2 ad dominum promoveatur.

Renatus. 25. Transitus ad Sectorem 2 si Broker 3 est unavailable.

Cum connectivity restituetur, sectorem 3 botrum iunget.

Renatus. 26. Botrus ad normalem operationem rediit.

Refert hic intelligere, quod constantiam consequimur, sed disponibilitatem quoque possumus; si Nos clientes ad summam sectionis feliciter transferemus. In pluribus adiunctis, Ipse personaliter eligeret modum Minoritatis Sergii, sed realiter pendet in casu singulari.

Ut disponibilitate, interest ut clientes cum exercitu feliciter coniungere. Inspice optiones nostras.

Ensuring Customer Connectivity

Plures optiones habemus quomodo clientes directi ad principalem partem botri vel ad nodos laborantes (post unum nodi deficit) post amissionem connectivity. Primum meminerimus quod certae queue nodi certae hosted sunt, sed fusa et consilia per omnes nodos replicantur. Clientes nulli nodi coniungere possunt, et fugatio interna eos diriget quo ire necesse est. Sed nodo suspensus, nexus reicit, clientes ad alium nodi coniungere debent. Si nodi cadit, parum potest.

Optiones nostrae:

• Botrus accessit usus librarii oneris qui simpliciter cyclos per nodos et clientes retry connectens usque ad felicem. Si nodi depressus vel suspensus est, tunc conatus nodi coniungere illi deficientem, sed subsequens conatus ad alios servientes ibit (in more rotundo-robin). Hoc aptum est ad breve tempus dispendium connectivity vel servo downe quod cito reducetur.
• Botrus accessere per librarium onus et suspensas / nodos defecerunt e indice quam primum deprehenduntur. Hoc si cito fecerimus, et si clientes possunt remittere nexum, tum promptitudinis erimus assidue.
• Indicem omnium nodis unicuique clienti tribue, et cliens passim unum ex illis iungendo eligit. Si errorem coniungere conatur, ad proximam nodi in album se movet donec coniungat.
• Aufer negotiationis ex incassum / suspensus nodi usura DNS. Hoc fit utens parvo ttl.

Inventiones

RabbitMQ ibil habet commoda et incommoda. Gravissima incommoda sunt illa;

• botrum iungens, nodos data abiciunt;
• interclusio synchronisation facit queue fieri unavailable.

Ex his duobus notis architecturae omnes quaestiones difficiles oriuntur. Si RabbitMQ notitias servare potuit cum botrus coniungitur, tunc synchronisatio velocior erit. Si capax esset synchronisationum non-obstructionum, melius magnas queues sustineret. Has duas quaestiones constituens vehementer emendare perficiebat RabbitMQ ut culpa tolerans et promptus nuntius technologiae. Incertus ero RabbitMQ ibil commendare in sequentibus adiunctis;

• Fugax ornatum.
• Repono volaticus.
• Ipsum donec queues.

Cum ad occasum disponibilitate venit, sequentia considera:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (aut autoheal)
• constans nuntiis
• ut clients coniungere ad active nodi cum quidam nodi ratio

For constantia (notitia securitatis), consider the following settings;

• Publisher Confirmat et Manuale Agnitiones in parte consumendi
• ha-promote-on-failure=when-synced, si editores serius iterum conari possunt et si certissimam habes! Alioquin put =always.
• ha-sync-mode=automatic (sed pro magna otiosa queues manualis modus requiri potest; etiam considera an unavailability epistulae causa amissae sint)
• Declina Minoritas modus
• constans nuntiis

Non omnes exitus tolerantiae culpae et promptitudinis adhuc operuimus; exempli gratia, modum procedendi administrativi secure peragendi (qualia volventia updates). Nos quoque de foederatione et trulla plugin loqui necesse est.

Si aliud amisi, fac ut sciam.

Vide etiam my post, ubi stragem in RabbitMQ botrum utentes Docker et Obsidio exerceo ad explorandum aliquod nuntium damnum missionum in hoc articulo descriptorum.

Articuli priores in serie:
No. 1 - habr.com/ru/company/itsumma/blog/416629
No. 2 - habr.com/ru/company/itsumma/blog/418389
No. 3 - habr.com/ru/company/itsumma/blog/437446

Source: www.habr.com