{"id":52525,"date":"2019-11-10T00:00:00","date_gmt":"2019-11-09T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah"},"modified":"2020-02-18T14:00:16","modified_gmt":"2020-02-18T11:00:16","slug":"rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFelaktighetstolerans och h\u00f6g tillg\u00e4nglighet \u00e4r stora \u00e4mnen, s\u00e5 vi kommer att \u00e4gna RabbitMQ och Kafka separata artiklar. Denna artikel handlar om RabbitMQ, och n\u00e4sta kommer att handla om Kafka, i j\u00e4mf\u00f6relse med RabbitMQ. Artikeln \u00e4r l\u00e5ng, s\u00e5 g\u00f6r dig bekv\u00e4m.<\/p>\n<p>Vi kommer att titta p\u00e5 strategier f\u00f6r felaktighetstolerans, konsistens och h\u00f6g tillg\u00e4nglighet (HA), samt de kompromisser som m\u00e5ste g\u00f6ras i varje strategi. RabbitMQ kan fungera p\u00e5 en kluster av noder \u2013 och klassificeras d\u00e5 som ett distribuerat system. N\u00e4r vi pratar om distribuerade system handlar det ofta om konsistens och tillg\u00e4nglighet. <\/p>\n<p>Dessa begrepp beskriver hur systemet beter sig vid fel. Fel i n\u00e4tverksanslutning, serverfel, h\u00e5rddiskfel, tempor\u00e4r otillg\u00e4nglighet av servern p\u00e5 grund av skr\u00e4phantering, paketf\u00f6rlust eller n\u00e4tverksf\u00f6rdr\u00f6jning. Allt detta kan leda till dataf\u00f6rlust eller konflikter. Det visar sig vara praktiskt taget om\u00f6jligt att uppr\u00e4tta ett system som \u00e4r b\u00e5de helt konsistent (utan dataf\u00f6rlust, utan datakonflikter) och tillg\u00e4ngligt (som kommer att ta emot l\u00e4s- och skrivoperationer) f\u00f6r alla typer av fel.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nVi kommer att se att konsistens och tillg\u00e4nglighet finns i olika \u00e4ndar av spektrumet, och du m\u00e5ste v\u00e4lja vilket h\u00e5ll du vill optimera mot. Den goda nyheten \u00e4r att med RabbitMQ \u00e4r detta val m\u00f6jligt. Du har s\u00e5dana \"n\u00f6rdiga\" reglage f\u00f6r att flytta balansen mot st\u00f6rre konsistens eller st\u00f6rre tillg\u00e4nglighet.<\/p>\n<p>Vi kommer s\u00e4rskilt att fokusera p\u00e5 vilka konfigurationer som leder till dataf\u00f6rlust p\u00e5 grund av bekr\u00e4ftade poster. Det finns en ansvarskedja mellan publicerare, m\u00e4klare och konsumenter. N\u00e4r ett meddelande har \u00f6verf\u00f6rts till m\u00e4klaren \u00e4r det hans jobb att inte f\u00f6rlora meddelandet. N\u00e4r m\u00e4klaren bekr\u00e4ftar mottagandet av meddelandet till publiceraren f\u00f6rv\u00e4ntar vi oss inte att det ska f\u00f6rloras. Men vi kommer att se att detta faktiskt kan h\u00e4nda beroende p\u00e5 din m\u00e4klares och publicerares konfiguration.<\/p>\n<h1>Enkelnodens motst\u00e5ndskraftiga primitiva<\/h1>\n<p><\/p>\n<h3>Motst\u00e5ndskraftiga k\u00f6er\/routing<\/h3>\n<p>\nI RabbitMQ finns det tv\u00e5 typer av k\u00f6er: best\u00e4ndiga (durable) och icke-best\u00e4ndiga (non-durable). Alla k\u00f6er lagras i Mnesia-databasen. Best\u00e4ndiga k\u00f6er deklareras p\u00e5 nytt vid start av noden och \u00f6verlever d\u00e4rmed omstart, systemfel eller serverkrascher (s\u00e5 l\u00e4nge data lagras). Detta inneb\u00e4r att s\u00e5 l\u00e4nge du deklarerar routingen (exchange) och k\u00f6er som best\u00e4ndiga, \u00e5terg\u00e5r k\u00f6-\/routinginfrastrukturen till drift.<\/p>\n<p>Icke-best\u00e4ndiga k\u00f6er och routing tas bort vid omstart av noden.<\/p>\n<h3>Best\u00e4ndiga meddelanden<\/h3>\n<p>\nAtt en k\u00f6 \u00e4r best\u00e4ndig inneb\u00e4r inte att alla dess meddelanden \u00f6verlever omstart av noden. Endast de meddelanden som publicerats som <i>best\u00e4ndiga<\/i> (persistent) kommer att \u00e5terst\u00e4llas. Best\u00e4ndiga meddelanden skapar verkligen en extra belastning p\u00e5 m\u00e4klaren, men om f\u00f6rlusten av ett meddelande \u00e4r oacceptabel, finns det inget alternativ.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 1. Best\u00e4ndighetsmatris<\/i><\/p>\n<h1>Klustering med speglade k\u00f6er<\/h1>\n<p>\nF\u00f6r att \u00f6verleva f\u00f6rlusten av m\u00e4klaren beh\u00f6ver vi redundans. Vi kan gruppera flera RabbitMQ-noder i ett kluster och d\u00e4refter \u00f6ka redundansen genom att replikera k\u00f6er mellan flera noder. S\u00e5ledes, om en nod kraschar, f\u00f6rlorar vi inte data och f\u00f6rblir tillg\u00e4ngliga. <\/p>\n<p>Speglad k\u00f6:<\/p>\n<ul>\n<li>en huvudk\u00f6 (master) som tar emot alla skriv- och l\u00e4skommandon\n<\/li>\n<li>en eller flera speglar som tar emot alla meddelanden och metadata fr\u00e5n huvudk\u00f6en. Dessa speglar finns inte f\u00f6r att skala utan uteslutande f\u00f6r redundans.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 2. Spegling av k\u00f6<\/i><\/p>\n<p>Speglingen st\u00e4lls in med en l\u00e4mplig politik. H\u00e4r kan man v\u00e4lja replikationsfaktorn och till och med noderna d\u00e4r k\u00f6n ska placeras. Exempel:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (en master och en spegel)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Bekr\u00e4ftelse till publiceraren<\/h1>\n<p>\nF\u00f6r att uppn\u00e5 en konsekvent registrering kr\u00e4vs bekr\u00e4ftelser fr\u00e5n publicisten (Publisher Confirms). Utan dessa finns det en risk f\u00f6r att meddelanden g\u00e5r f\u00f6rlorade. Bekr\u00e4ftelsen skickas till publicisten efter att meddelandet har skrivits till disken. RabbitMQ skriver meddelanden till disken inte vid mottagning, utan periodiskt, omkring flera hundra millisekunder. N\u00e4r k\u00f6n speglas skickas bekr\u00e4ftelsen endast efter att alla speglar ocks\u00e5 har skrivit sin kopia av meddelandet till disken. Detta inneb\u00e4r att anv\u00e4ndning av bekr\u00e4ftelser l\u00e4gger till en f\u00f6rdr\u00f6jning, men om dataskydd \u00e4r viktigt \u00e4r de n\u00f6dv\u00e4ndiga.<\/p>\n<h1>Fel t\u00e5lig k\u00f6<\/h1>\n<p>\nN\u00e4r m\u00e4klaren avslutas eller kraschar, tappar alla ledande k\u00f6er (master) p\u00e5 denna nod kopplingen med honom. Klustret v\u00e4ljer d\u00e5 den \u00e4ldsta spegeln av varje master och befordrar den till ny master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 3. Flera speglade k\u00f6er och deras policyer<\/i><\/p>\n<p>M\u00e4klare 3 kraschar. Observera att spegeln f\u00f6r K\u00f6 C p\u00e5 M\u00e4klare 2 befordras till master. Observera ocks\u00e5 att en ny spegel f\u00f6r K\u00f6 C skapas p\u00e5 M\u00e4klare 1. RabbitMQ f\u00f6rs\u00f6ker alltid uppr\u00e4tth\u00e5lla den angivna replikationsgraden i dina policyer.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 4. M\u00e4klare 3 kraschar, vilket orsakar en k\u00f6 C-fel<\/i> <\/p>\n<p>Den n\u00e4sta M\u00e4klare 1 kraschar! Vi har bara en m\u00e4klare kvar. Spegeln f\u00f6r K\u00f6 B befordras till master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 5<\/i><\/p>\n<p>Vi har \u00e5terf\u00e5tt M\u00e4klare 1. Oavsett hur framg\u00e5ngsrikt data \u00f6verlevde f\u00f6rlusten och \u00e5terst\u00e4llningen av m\u00e4klaren, kastas alla speglade meddelanden i k\u00f6n vid omstart. Det \u00e4r viktigt att notera, eftersom det kommer att f\u00e5 konsekvenser. Vi kommer snart att titta p\u00e5 dessa konsekvenser. S\u00e5ledes \u00e4r M\u00e4klare 1 nu \u00e5terigen medlem av klustret, och klustret f\u00f6rs\u00f6ker uppr\u00e4tth\u00e5lla policyerna och skapar d\u00e4rf\u00f6r speglar p\u00e5 M\u00e4klare 1.<\/p>\n<p>I detta fall var f\u00f6rlusten av M\u00e4klare 1 fullst\u00e4ndig, liksom data, s\u00e5 den ospeglande K\u00f6 B \u00e4r helt f\u00f6rlorad.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 6. M\u00e4klare 1 \u00e5terkommer till tj\u00e4nst<\/i><\/p>\n<p>Broker 3 \u00e4r tillbaka i drift, s\u00e5 k\u00f6erna A och B f\u00e5r tillbaka sina skapade spegelkopior f\u00f6r att uppfylla sina HA-policys. Men nu \u00e4r alla huvudk\u00f6er p\u00e5 en och samma nod! Det \u00e4r inte idealiskt, en j\u00e4mnare f\u00f6rdelning mellan noderna skulle vara b\u00e4ttre. Tyv\u00e4rr finns det inga speciella alternativ f\u00f6r att ombalansera m\u00e4starna h\u00e4r. Vi kommer tillbaka till det problemet senare, f\u00f6rst m\u00e5ste vi titta p\u00e5 k\u00f6-synkroniseringen. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 7. Broker 3 \u00e5terg\u00e5r till drift. Alla huvudk\u00f6er p\u00e5 en nod!<\/i><\/p>\n<p>S\u00e5 nu borde du ha en uppfattning om hur spegelkopior skapar redundans och fel\u00f6verlevnad. Detta garanterar tillg\u00e4nglighet vid en nodfel och skyddar mot dataf\u00f6rlust. Men vi \u00e4r inte klara \u00e4n, eftersom det faktiskt \u00e4r mycket mer komplicerat.<\/p>\n<h1>Synkronisering<\/h1>\n<p>\nN\u00e4r en ny spegel skapas kommer alla nya meddelanden alltid att replikerats till denna spegel och eventuella andra. N\u00e4r det g\u00e4ller befintliga data i huvudk\u00f6en kan vi replikera dem till den nya spegeln, vilket g\u00f6r den till en fullst\u00e4ndig kopia av m\u00e4staren. Vi kan ocks\u00e5 v\u00e4lja att inte replikera befintliga meddelanden och l\u00e5ta huvudk\u00f6en och den nya spegeln konvergera \u00f6ver tid, n\u00e4r nya meddelanden anl\u00e4nder i slutet och befintliga meddelanden raderas fr\u00e5n b\u00f6rjan av huvudk\u00f6en.<\/p>\n<p>S\u00e5dan synkronisering g\u00f6rs automatiskt eller manuellt och styrs av k\u00f6policyn. L\u00e5t oss ta ett exempel.<\/p>\n<p>Vi har tv\u00e5 speglade k\u00f6er. K\u00f6 A synkroniseras automatiskt, medan K\u00f6 B g\u00f6r det manuellt. B\u00e5da k\u00f6erna har tio meddelanden.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 8. Tv\u00e5 k\u00f6er med olika synkroniseringsl\u00e4gen<\/i><\/p>\n<p>Nu f\u00f6rlorar vi Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 9. Broker 3 har kraschat<\/i><\/p>\n<p>Broker 3 \u00e4r tillbaka i drift. Klustret skapar en spegel f\u00f6r varje k\u00f6 p\u00e5 en ny nod och synkroniserar automatiskt den nya K\u00f6 A med m\u00e4staren. Men spegeln f\u00f6r den nya K\u00f6 B f\u00f6rblir tom. S\u00e5ledes har vi full redundans f\u00f6r K\u00f6 A och endast en spegel f\u00f6r befintliga meddelanden i K\u00f6 B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 10. Den nya spegeln av K\u00f6 A f\u00e5r alla befintliga meddelanden, medan den nya spegeln av K\u00f6 B inte f\u00e5r n\u00e5gra.<\/i><\/p>\n<p>Det kommer ytterligare tio meddelanden till b\u00e5da k\u00f6erna. D\u00e4refter kraschar Broker 2 och K\u00f6 A rullar tillbaka till den \u00e4ldsta spegeln som finns p\u00e5 Broker 1. Vid ett fel sker ingen dataf\u00f6rlust. I K\u00f6 B finns tjugo meddelanden i m\u00e4staren och endast tio i spegeln, eftersom denna k\u00f6 aldrig replikerade de ursprungliga tio meddelandena.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 11. K\u00f6 A rullar tillbaka p\u00e5 Broker 1 utan meddelandef\u00f6rlust<\/i><\/p>\n<p>Det kommer ytterligare tio meddelanden till b\u00e5da k\u00f6erna. Nu kraschar Broker 1. K\u00f6 A v\u00e4xlar utan problem till spegeln utan meddelandef\u00f6rlust. Dock uppst\u00e5r problem f\u00f6r K\u00f6 B. Vid detta skede kan vi optimera antingen tillg\u00e4ngligheten eller konsistensen. <\/p>\n<p>Om vi vill optimera tillg\u00e4ngligheten, b\u00f6r policyn <b><i>ha-promote-on-failure<\/i><\/b> st\u00e4llas in p\u00e5 <b><i>always<\/i><\/b>. Detta \u00e4r standardv\u00e4rdet, s\u00e5 vi kan helt enkelt v\u00e4lja att inte ange policyn \u00f6verhuvudtaget. I s\u00e5 fall till\u00e5ter vi i praktiken fel i osynkroniserade speglar. Detta skulle leda till meddelandef\u00f6rlust, men k\u00f6n f\u00f6rblir tillg\u00e4nglig f\u00f6r l\u00e4sning och skrivning.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 12. K\u00f6 A rullar tillbaka p\u00e5 Broker 3 utan meddelandef\u00f6rlust. K\u00f6 B rullar tillbaka p\u00e5 Broker 3 med f\u00f6rlust av tio meddelanden<\/i><\/p>\n<p>Vi kan ocks\u00e5 st\u00e4lla in <code>ha-promote-on-failure<\/code> till v\u00e4rdet <code>when-synced<\/code>. I detta fall kommer k\u00f6n att v\u00e4nta tills Broker 1 med sina data \u00e5terg\u00e5r till drift ist\u00e4llet f\u00f6r att rulla tillbaka till spegeln. N\u00e4r den kommer tillbaka, hamnar huvudk\u00f6en \u00e5terigen p\u00e5 Broker 1 utan dataf\u00f6rlust. Tillg\u00e4ngligheten offras f\u00f6r dataskyddet. Men detta \u00e4r ett riskabelt l\u00e4ge som kan leda till fullst\u00e4ndig dataf\u00f6rlust, vilket vi kommer att titta p\u00e5 snart.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 13. K\u00f6 B f\u00f6rblir otillg\u00e4nglig efter att Broker 1 har f\u00f6rlorats<\/i><\/p>\n<p>Du kanske undrar: \"\u00c4r det kanske b\u00e4ttre att aldrig anv\u00e4nda automatisk synkronisering?\". Svaret \u00e4r att synkronisering \u00e4r en blockerande operation. Under synkroniseringen kan huvudk\u00f6en inte utf\u00f6ra n\u00e5gra l\u00e4s- eller skrivoperationer!<\/p>\n<p>L\u00e5t oss titta p\u00e5 ett exempel. Just nu har vi v\u00e4ldigt stora k\u00f6er. Hur kan de v\u00e4xa till s\u00e5 stora storlekar? Av flera anledningar:<\/p>\n<ul>\n<li>K\u00f6erna anv\u00e4nds inte aktivt\n<\/li>\n<li>Detta \u00e4r h\u00f6gpresterande k\u00f6er, och just nu arbetar konsumenterna l\u00e5ngsamt \n<\/li>\n<li>Detta \u00e4r h\u00f6gpresterande k\u00f6er, det har intr\u00e4ffat ett fel, och konsumenterna hinner ikapp<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figur 14. Tv\u00e5 stora k\u00f6er med olika synkroniseringsl\u00e4gen<\/i><\/p>\n<p>Nu faller Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figur 15. Broker 3 faller, vilket l\u00e4mnar en master och en spegel i varje k\u00f6<\/i><\/p>\n<p>Broker 3 \u00e5terkommer i drift, och nya speglar skapas. Huvudk\u00f6 A b\u00f6rjar replikera befintliga meddelanden till den nya spegeln, och under denna tid \u00e4r k\u00f6n otillg\u00e4nglig. Datoreplikering tar tv\u00e5 timmar, vilket leder till tv\u00e5 timmars stillest\u00e5nd f\u00f6r denna k\u00f6!<\/p>\n<p>Men k\u00f6 B f\u00f6rblir tillg\u00e4nglig under hela perioden. Den gav upp viss redundans f\u00f6r att s\u00e4kerst\u00e4lla tillg\u00e4nglighet.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figur 16. K\u00f6n f\u00f6rblir otillg\u00e4nglig under synkroniseringen<\/i><\/p>\n<p>Efter tv\u00e5 timmar blir k\u00f6 A ocks\u00e5 tillg\u00e4nglig och kan \u00e5ter igen b\u00f6rja ta emot l\u00e4s- och skrivoperationer.<\/p>\n<h3>Uppdateringar<\/h3>\n<p>\nDet blockerande beteendet under synkronisering g\u00f6r det sv\u00e5rt att uppdatera kluster med mycket stora k\u00f6er. Vid en viss punkt m\u00e5ste knuten med masterstartas om, vilket betyder antingen ett byte till en spegel eller att st\u00e4nga av k\u00f6n under serveruppdateringen. Om vi v\u00e4ljer byte, f\u00f6rlorar vi meddelanden om speglarna inte \u00e4r synkroniserade. Som standard utf\u00f6rs inget byte till en icke-synkroniserad spegel n\u00e4r broker st\u00e4ngs av. Det betyder att s\u00e5 snart broker \u00e5terkommer, f\u00f6rlorar vi inga meddelanden; den enda skadan var stillest\u00e5ndet f\u00f6r k\u00f6n. Reglerna f\u00f6r beteende vid avst\u00e4ngning av broker best\u00e4ms av policyn <code>ha-promote-on-shutdown<\/code>. Du kan st\u00e4lla in ett av tv\u00e5 v\u00e4rden:<\/p>\n<ul>\n<li><code>always<\/code>= aktivera byte till icke-synkroniserade speglar\n<\/li>\n<li><code>when-synced<\/code>= byte endast till en synkroniserad spegel, annars blir k\u00f6n otillg\u00e4nglig f\u00f6r l\u00e4sning och skrivning. K\u00f6n \u00e5terkommer i drift s\u00e5 snart broker \u00e5terkommer<\/li>\n<\/ul>\n<p>\nOavsett, med stora k\u00f6er m\u00e5ste man v\u00e4lja mellan dataloss och otillg\u00e4nglighet.<\/p>\n<h3>N\u00e4r tillg\u00e4nglighet \u00f6kar datas\u00e4kerheten<\/h3>\n<p>\nInnan vi fattar beslutet m\u00e5ste vi beakta ytterligare en komplikation. \u00c4ven om automatisk synkronisering \u00e4r b\u00e4ttre f\u00f6r redundans, hur p\u00e5verkar den datas\u00e4kerheten? Sj\u00e4lvklart, tack vare b\u00e4ttre redundans, \u00e4r RabbitMQ mindre ben\u00e4gen att f\u00f6rlora existerande meddelanden, men vad h\u00e4nder med nya meddelanden fr\u00e5n publicerarna?<\/p>\n<p>H\u00e4r m\u00e5ste vi beakta f\u00f6ljande:<\/p>\n<ul>\n<li>Kan en publicerare bara returnera ett fel, s\u00e5 att den \u00f6verordnade tj\u00e4nsten eller anv\u00e4ndaren kan f\u00f6rs\u00f6ka igen senare?\n<\/li>\n<li>Kan en publicerare spara meddelandet lokalt eller i databasen f\u00f6r att f\u00f6rs\u00f6ka igen senare?<\/li>\n<\/ul>\n<p>\nOm publiceraren endast kan avvisa meddelandet, f\u00f6rb\u00e4ttrar \u00f6kad tillg\u00e4nglighet faktiskt ocks\u00e5 dataskyddet.<\/p>\n<p>Det \u00e4r d\u00e4rf\u00f6r viktigt att hitta en balans, och l\u00f6sningen beror p\u00e5 den specifika situationen.<\/p>\n<h1>Problem med ha-promote-on-failure=when-synced<\/h1>\n<p>\nTanken <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> ligger i att vi f\u00f6rhindrar v\u00e4xling till en osynkroniserad spegel och d\u00e4rmed undviker datarf\u00f6rlust. Koordinaten f\u00f6rblir otillg\u00e4nglig f\u00f6r l\u00e4sning eller skrivning. Ist\u00e4llet f\u00f6rs\u00f6ker vi \u00e5terf\u00e5 den kraschade m\u00e4klaren med intakta data s\u00e5 att den kan \u00e5teruppta sin roll som master utan datarf\u00f6rlust. <\/p>\n<p>Men (och detta \u00e4r ett stort men) om m\u00e4klaren har f\u00f6rlorat sina data, har vi ett stort problem: k\u00f6n \u00e4r f\u00f6rlorad! Alla data \u00e4r borta! \u00c4ven om du har speglar som vanligtvis f\u00f6ljer huvudk\u00f6n, avvisas dessa speglar ocks\u00e5.<\/p>\n<p>F\u00f6r att l\u00e4gga till noden med samma namn igen s\u00e4ger vi till klustret att gl\u00f6mma den f\u00f6rlorade noden (med kommandot <i>rabbitmqctl forget_cluster_node<\/i>) och startar en ny m\u00e4klare med samma v\u00e4rdnamn. Medan klustret kommer ih\u00e5g den f\u00f6rlorade noden, kommer det ih\u00e5g den gamla k\u00f6n och de osynkroniserade speglarna. N\u00e4r klustret beordras att gl\u00f6mma den f\u00f6rlorade noden, gl\u00f6ms ocks\u00e5 denna k\u00f6. Den m\u00e5ste nu deklareras p\u00e5 nytt. Vi har f\u00f6rlorat alla data, trots att vi hade speglar med delvis datam\u00e4ngd. Det hade varit b\u00e4ttre att v\u00e4xla till en osynkroniserad spegel!<\/p>\n<p>S\u00e5ledes \u00e4r manuell synkronisering (och att inte utf\u00f6ra synkronisering) i kombination med <code>ha-promote-on-failure=when-synced<\/code>, enligt min \u00e5sikt, ganska riskabelt. Dokumenten s\u00e4ger att detta alternativ finns f\u00f6r dataskydd, men det \u00e4r ett tveeggat sv\u00e4rd.<\/p>\n<h1>Omf\u00f6rdelning av masters<\/h1>\n<p>\nSom lovat kommer vi tillbaka till problemet med ansamling av alla masters p\u00e5 en eller flera noder. Detta kan intr\u00e4ffa \u00e4ven som ett resultat av en \"rullande\" uppdatering av klustret. I ett kluster med tre noder kommer alla huvudk\u00f6er att ansamlas p\u00e5 en eller tv\u00e5 noder.<\/p>\n<p>Omf\u00f6rdelning av masters kan visa sig problematisk av tv\u00e5 sk\u00e4l:<\/p>\n<ul>\n<li>Det finns inga bra verktyg f\u00f6r att utf\u00f6ra omf\u00f6rdelning<\/li>\n<li>Synkronisering av k\u00f6er<\/li>\n<\/ul>\n<p>\nDet finns en tredjepartsl\u00f6sning f\u00f6r ombalansering <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, som inte st\u00f6ds officiellt. G\u00e4llande tredjepartsplugins i RabbitMQ-guiden <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">s\u00e4gs<\/a><\/noindex>: \u00abPluginet erbjuder vissa extra justerings- och rapporteringsverktyg, men st\u00f6ds inte och har inte testats av RabbitMQ-teamet. Anv\u00e4nd p\u00e5 egen risk\u00bb.<\/p>\n<p>Det finns ytterligare ett trick f\u00f6r att flytta huvud k\u00f6n via HA-policyn. Guiden n\u00e4mner <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">skript<\/a><\/noindex> detta. Det fungerar p\u00e5 f\u00f6ljande s\u00e4tt:<\/p>\n<ul>\n<li>Tar bort alla speglar med en tempor\u00e4r policy med en h\u00f6gre prioritet \u00e4n den befintliga HA-policyn.\n<\/li>\n<li>\u00c4ndrar den tempor\u00e4ra HA-policyn f\u00f6r att anv\u00e4nda \"nodes\"-l\u00e4get och specificerar noden som huvud k\u00f6n ska flyttas till.\n<\/li>\n<li>Synkroniserar k\u00f6n f\u00f6r att p\u00e5tvinga migreringen.\n<\/li>\n<li>N\u00e4r migreringen \u00e4r f\u00e4rdig tas den tempor\u00e4ra policyn bort. Den ursprungliga HA-policyn tr\u00e4der i kraft och \u00f6nskat antal speglar skapas.<\/li>\n<\/ul>\n<p>\nNackdelen \u00e4r att denna metod kanske inte fungerar om du har stora k\u00f6er eller strikta redundanskrav.<\/p>\n<p>Nu ska vi titta p\u00e5 hur RabbitMQ-kluster hanterar n\u00e4tverkspartitioner.<\/p>\n<h1>Brott mot sammanh\u00e5llning<\/h1>\n<p>\nNoder i ett distribuerat system kopplas samman via n\u00e4tverksf\u00f6rbindelser, och n\u00e4tverksf\u00f6rbindelser kan och kommer att brytas. Frekvensen av avbrott beror p\u00e5 den lokala infrastrukturen eller p\u00e5litligheten av det valda molnet. I vilket fall som helst m\u00e5ste distribuerade system kunna hantera dem. \u00c5terigen har vi valet mellan tillg\u00e4nglighet och konsistens, och \u00e5terigen \u00e4r den goda nyheten att RabbitMQ erbjuder b\u00e5da alternativen (bara inte samtidigt).<\/p>\n<p>Med RabbitMQ har vi tv\u00e5 huvudsakliga alternativ:<\/p>\n<ul>\n<li>Till\u00e5ta logisk uppdelning (split-brain). Detta s\u00e4kerst\u00e4ller tillg\u00e4nglighet, men kan orsaka dataf\u00f6rlust.\n<\/li>\n<li>F\u00f6rbjuda logisk uppdelning. Detta kan leda till kortsiktig f\u00f6rlust av tillg\u00e4nglighet beroende p\u00e5 hur klienterna kopplar upp sig mot klustret. Det kan ocks\u00e5 leda till fullst\u00e4ndig otillg\u00e4nglighet i ett kluster med tv\u00e5 noder.<\/li>\n<\/ul>\n<p>\nMen vad \u00e4r logisk uppdelning? Det \u00e4r n\u00e4r klustret delas i tv\u00e5 p\u00e5 grund av f\u00f6rlorade n\u00e4tverksf\u00f6rbindelser. P\u00e5 varje sida h\u00f6js speglar till master, s\u00e5 att det i slut\u00e4ndan finns flera masters f\u00f6r varje k\u00f6.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 17. Huvudk\u00f6 och tv\u00e5 speglar, var och en p\u00e5 en separat nod. D\u00e4refter uppst\u00e5r ett n\u00e4tverksfel, och en spegel separeras. Den separerade noden ser att de tv\u00e5 andra har kopplats bort och fr\u00e4mjar sina speglar till master. Nu har vi tv\u00e5 huvudk\u00f6er, och b\u00e5da till\u00e5ter skrivning och l\u00e4sning.<\/i> <\/p>\n<p>Om publicerare skickar data till b\u00e5da masters, f\u00e5r vi tv\u00e5 avvikande kopior av k\u00f6n.<\/p>\n<p>Olika l\u00e4gen i RabbitMQ s\u00e4kerst\u00e4ller antingen tillg\u00e4nglighet eller konsistens.<\/p>\n<h3>L\u00e4get Ignorera (standard)<\/h3>\n<p>\nDetta l\u00e4ge s\u00e4kerst\u00e4ller tillg\u00e4nglighet. Efter f\u00f6rlust av anslutning sker en logisk separation. N\u00e4r anslutning har \u00e5terst\u00e4llts m\u00e5ste administrat\u00f6ren avg\u00f6ra vilket avsnitt som ska prioriteras. Den f\u00f6rlorande sidan kommer att startas om, och all ackumulerad data fr\u00e5n denna sida g\u00e5r f\u00f6rlorad.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 18. Tre publicerare \u00e4r kopplade till tre m\u00e4klare. Internt dirigerar klustret alla f\u00f6rfr\u00e5gningar till huvudk\u00f6 p\u00e5 M\u00e4klare 2.<\/i><\/p>\n<p>Nu f\u00f6rlorar vi M\u00e4klare 3. Den ser att de andra m\u00e4klarna har kopplats bort och fr\u00e4mjar sin spegel till master. S\u00e5 sker en logisk separation.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 19. Logisk separation (split-brain). Inmatningar g\u00f6rs i tv\u00e5 huvudk\u00f6er, och tv\u00e5 kopior avviker.<\/i><\/p>\n<p>Anslutning \u00e5terst\u00e4lls, men logisk separation kvarst\u00e5r. Administrat\u00f6ren m\u00e5ste manuellt v\u00e4lja den f\u00f6rlorande sidan. I det angivna fallet startar administrat\u00f6ren om M\u00e4klare 3. Alla meddelanden som inte hann \u00f6verf\u00f6ras g\u00e5r f\u00f6rlorade.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 20. Administrat\u00f6ren st\u00e4nger av M\u00e4klare 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 21. Administrat\u00f6ren startar M\u00e4klare 3, och den g\u00e5r med i klustret, f\u00f6rlorar alla meddelanden som fanns kvar d\u00e4r.<\/i><\/p>\n<p>Under f\u00f6rlust av anslutning och efter dess \u00e5terst\u00e4llning var klustret och denna k\u00f6 tillg\u00e4ngliga f\u00f6r l\u00e4sning och skrivning.<\/p>\n<h3>L\u00e4get Autoheal<\/h3>\n<p>\nFungerar liknande som l\u00e4get Ignorera, f\u00f6rutom att klustret automatiskt v\u00e4ljer den f\u00f6rlorande sidan efter separation och \u00e5terst\u00e4llande av anslutning. Den f\u00f6rlorande sidan \u00e5terv\u00e4nder till klustret tom, och k\u00f6n f\u00f6rlorar alla meddelanden som skickades endast till den sidan.<\/p>\n<h3>L\u00e4get Pausa Minoritet<\/h3>\n<p>\nOm vi inte vill till\u00e5ta logiskt avskiljande \u00e4r v\u00e5rt enda alternativ att avst\u00e5 fr\u00e5n att l\u00e4sa och skriva p\u00e5 den mindre sidan efter klusteravsnittet. N\u00e4r en m\u00e4klare ser att den \u00e4r p\u00e5 den mindre sidan pausar den driften, vilket inneb\u00e4r att den st\u00e4nger alla befintliga anslutningar och avvisar alla nya. En g\u00e5ng per sekund kontrollerar den \u00e5terst\u00e4llningen av anslutningen. S\u00e5 snart anslutningen har \u00e5terst\u00e4llts, \u00e5terupptar den driften och \u00e5teransluter till klustret.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 22. Tre publicerare \u00e4r kopplade till tre m\u00e4klare. Klustret dirigerar alla f\u00f6rfr\u00e5gningar till huvudk\u00f6en p\u00e5 M\u00e4klare 2.<\/i><\/p>\n<p>D\u00e4refter separeras M\u00e4klare 1 och 2 fr\u00e5n M\u00e4klare 3. Ist\u00e4llet f\u00f6r att uppgradera sitt spegel till master pausar M\u00e4klare 3 driften och blir otillg\u00e4nglig.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 23. M\u00e4klare 3 pausar driften, kopplar bort alla klienter och avvisar anslutningsf\u00f6rfr\u00e5gningar.<\/i><\/p>\n<p>S\u00e5 snart anslutningen har \u00e5terst\u00e4llts, kommer den tillbaka till klustret.<\/p>\n<p>L\u00e5t oss titta p\u00e5 ett annat exempel d\u00e4r huvudk\u00f6en ligger p\u00e5 M\u00e4klare 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 24. Huvudk\u00f6en ligger p\u00e5 M\u00e4klare 3.<\/i><\/p>\n<p>D\u00e4refter intr\u00e4ffar samma f\u00f6rlust av anslutning. M\u00e4klare 3 pausas eftersom den \u00e4r p\u00e5 den mindre sidan. P\u00e5 den andra sidan ser noderna att M\u00e4klare 3 har tappat anslutningen, s\u00e5 den \u00e4ldre spegeln fr\u00e5n M\u00e4klare 1 och 2 uppgraderas till master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 25. \u00d6verg\u00e5ng till M\u00e4klare 2 vid otillg\u00e4nglighet av M\u00e4klare 3.<\/i><\/p>\n<p>N\u00e4r anslutningen har \u00e5terst\u00e4llts kommer M\u00e4klare 3 att ansluta till klustret.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ kontra Kafka: fel tolerans och h\u00f6g tillg\u00e4nglighet i kluster\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 26. Klustret har \u00e5terg\u00e5tt till normal drift.<\/i><\/p>\n<p>H\u00e4r \u00e4r det viktigt att f\u00f6rst\u00e5 att vi f\u00e5r konsistens, men vi kan ocks\u00e5 f\u00e5 tillg\u00e5ng. <i><b>om<\/b><\/i> vi framg\u00e5ngsrikt omdirigerar klienterna till den st\u00f6rre delen av avsnittet. F\u00f6r de flesta situationer skulle jag personligen v\u00e4lja l\u00e4get Pause Minority, men detta beror verkligen p\u00e5 det specifika fallet.<\/p>\n<p>F\u00f6r att s\u00e4kerst\u00e4lla tillg\u00e5ng \u00e4r det viktigt att se till att klienterna framg\u00e5ngsrikt ansluter till noden. L\u00e5t oss \u00f6verv\u00e4ga v\u00e5ra alternativ.<\/p>\n<h1>S\u00e4kerst\u00e4llande av klientanslutning<\/h1>\n<p>\nVi har flera alternativ f\u00f6r att dirigera kunder till huvudklustret eller till fungerande noder efter en avbrott. L\u00e5t oss f\u00f6rst p\u00e5minna oss om att en specifik k\u00f6 placeras p\u00e5 en viss nod, men routing och policys replikeras p\u00e5 alla noder. Kunder kan ansluta till valfri nod, och den interna routingen dirigerar dem dit de beh\u00f6ver g\u00e5. Men n\u00e4r en nod stoppas avvisar den anslutningar, s\u00e5 kunderna m\u00e5ste ansluta till en annan nod. Om noden avbryts kan den egentligen inte g\u00f6ra mycket.<\/p>\n<p>V\u00e5ra alternativ:<\/p>\n<ul>\n<li>\u00c5tkomst till klustret g\u00f6rs via en lastbalanserare som helt enkelt roterar mellan noderna, medan kunderna g\u00f6r om f\u00f6rs\u00f6k till anslutning tills det lyckas. Om en nod inte fungerar eller \u00e4r stoppad, kommer anslutningsf\u00f6rs\u00f6k till den noden att misslyckas, men efterf\u00f6ljande f\u00f6rs\u00f6k g\u00e5r till andra servrar (i cyklisk ordning). Detta passar f\u00f6r kortvariga avbrott eller en server som har kraschat och snabbt kommer att startas igen.\n<\/li>\n<li>\u00c5tkomst till klustret via en lastbalanserare och borttagning av stoppade\/kraschat noder fr\u00e5n listan s\u00e5 snart de uppt\u00e4ckts. Om detta g\u00f6rs snabbt, och om kunderna kan g\u00f6ra om f\u00f6rs\u00f6k till anslutning, f\u00e5r vi kontinuerlig tillg\u00e4nglighet.\n<\/li>\n<li>Ge varje kund en lista \u00f6ver alla noder, s\u00e5 v\u00e4ljer kunden slumpm\u00e4ssigt en av dem vid anslutning. Om de f\u00e5r ett fel vid anslutningsf\u00f6rs\u00f6ket g\u00e5r de vidare till n\u00e4sta nod i listan tills de ansluter.\n<\/li>\n<li>Ta bort trafik fr\u00e5n en avst\u00e4ngd\/stoppad nod med hj\u00e4lp av DNS. Detta g\u00f6rs med en l\u00e5g TTL.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Slutsatser<\/h1>\n<p>\nRabbitMQ-klustring har sina f\u00f6rdelar och nackdelar. De mest betydande nackdelarna \u00e4r att:<\/p>\n<ul>\n<li>noderna avf\u00e4rdar sina data n\u00e4r de ansluter till klustret;\n<\/li>\n<li>blockerande synkronisering leder till att k\u00f6n blir otillg\u00e4nglig.<\/li>\n<\/ul>\n<p>\nAlla sv\u00e5ra beslut kommer fr\u00e5n dessa tv\u00e5 arkitekturdrag. Om RabbitMQ kunde spara data vid \u00e5terkoppling av klustret, skulle synkroniseringen g\u00e5 snabbare. Om det var kapabelt till icke-blockerande synkronisering skulle det b\u00e4ttre st\u00f6dja stora k\u00f6er. Att \u00e5tg\u00e4rda dessa tv\u00e5 problem skulle allvarligt f\u00f6rb\u00e4ttra RabbitMQ:s prestanda som en fel-tolerant och h\u00f6g- tillg\u00e4nglig meddelandehanteringsteknologi. Jag skulle inte v\u00e5ga rekommendera RabbitMQ med klustring i f\u00f6ljande situationer:<\/p>\n<ul>\n<li>Op\u00e5litligt n\u00e4tverk.\n<\/li>\n<li>Op\u00e5litlig lagring.\n<\/li>\n<li>Mycket stora k\u00f6er.<\/li>\n<\/ul>\n<p>\nN\u00e4r det g\u00e4ller inst\u00e4llningar f\u00f6r h\u00f6g tillg\u00e4nglighet b\u00f6r f\u00f6ljande \u00f6verv\u00e4gas:<\/p>\n<ul>\n<li><code>ha-promote-on-failure=always<\/code>\n<\/li>\n<li><code>ha-sync-mode=manual<\/code>\n<\/li>\n<li><code>cluster_partition_handling=ignore<\/code> (eller <code>autoheal<\/code>)\n<\/li>\n<li>best\u00e4ndiga meddelanden\n<\/li>\n<li>se till att klienterna ansluter till den aktiva noden n\u00e4r n\u00e5gon nod g\u00e5r ner<\/li>\n<\/ul>\n<p>\nF\u00f6r konsekvens (datas\u00e4kerhet) b\u00f6r f\u00f6ljande inst\u00e4llningar \u00f6verv\u00e4gas:<\/p>\n<ul>\n<li>Publisher Confirms och Manual Acknowledgements p\u00e5 konsumentsidan\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, om utgivarna kan f\u00f6rs\u00f6ka igen senare och om du har en mycket p\u00e5litlig lagring! Annars anv\u00e4nd <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (men f\u00f6r stora inaktiva k\u00f6er kan manuellt l\u00e4ge kr\u00e4vas, dessutom, \u00f6verv\u00e4g om otillg\u00e4nglighet kan leda till meddelandef\u00f6rlust)\n<\/li>\n<li>Pause Minority-l\u00e4ge\n<\/li>\n<li>best\u00e4ndiga meddelanden<\/li>\n<\/ul>\n<p>\nVi har inte t\u00e4ckt alla fr\u00e5gor kring fel-tolerans och h\u00f6g tillg\u00e4nglighet; till exempel, hur man s\u00e4kert utf\u00f6r administrativa procedurer (s\u00e5som smyguppdateringar). Det beh\u00f6ver ocks\u00e5 pratas om federation och Shovel-plugin.<\/p>\n<p>Om jag har missat n\u00e5got, v\u00e4nligen l\u00e5t mig veta.<\/p>\n<p>Se \u00e4ven min <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">inl\u00e4gg<\/a><\/noindex>, d\u00e4r jag genomf\u00f6r en genomg\u00e5ng av RabbitMQ-klustret med hj\u00e4lp av Docker och Blockade f\u00f6r att testa vissa scenarier f\u00f6r meddelandef\u00f6rlust som beskrivs i denna artikel.<\/p>\n<p>Tidigare artiklar i serien: <br \/>\nNr 1 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/416629\/\">habr.com\/ru\/company\/itsumma\/blog\/416629<\/a><\/noindex> <br \/>\nNr 2 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/418389\/\">habr.com\/ru\/company\/itsumma\/blog\/418389<\/a><\/noindex> <br \/>\nNr 3 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/437446\/\">habr.com\/ru\/company\/itsumma\/blog\/437446<\/a><\/noindex><br \/>\n<br \/>K\u00e4lla: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/471858\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u2014 \u0431\u043e\u043b\u044c\u0448\u0438\u0435 \u0442\u0435\u043c\u044b, \u0442\u0430\u043a \u0447\u0442\u043e \u043f\u043e\u0441\u0432\u044f\u0442\u0438\u043c RabbitMQ \u0438 Kafka \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0441\u0442\u0430\u0442\u044c\u0438. \u0414\u0430\u043d\u043d\u0430\u044f \u0441\u0442\u0430\u0442\u044c\u044f \u043e RabbitMQ, \u0430 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u2014 \u043e Kafka, \u0432 \u0441\u0440\u0430\u0432\u043d\u0435\u043d\u0438\u0438 \u0441 RabbitMQ. \u0421\u0442\u0430\u0442\u044c\u044f \u0434\u043b\u0438\u043d\u043d\u0430\u044f, \u0442\u0430\u043a \u0447\u0442\u043e \u0443\u0441\u0442\u0440\u0430\u0438\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043f\u043e\u0443\u0434\u043e\u0431\u043d\u0435\u0435. \u0420\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438 \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438, \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0438 \u0432\u044b\u0441\u043e\u043a\u043e\u0439 \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u0438 (HA), \u0430 \u0442\u0430\u043a\u0436\u0435 \u043a\u043e\u043c\u043f\u0440\u043e\u043c\u0438\u0441\u0441\u044b, \u043d\u0430 \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0438\u0434\u0442\u0438 \u0432 \u043a\u0430\u0436\u0434\u043e\u0439 \u0441\u0442\u0440\u0430\u0442\u0435\u0433\u0438\u0438. RabbitMQ \u043c\u043e\u0436\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-52525","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\".\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sv_SE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\".\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-11-09T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:00:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47RabbitMQ mot Kafka: fel-tolerans och h\u00f6g tillg\u00e4nglighet i kluster | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47RabbitMQ \u043f\u0440\u043e\u0442\u0438\u0432 Kafka: \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u044c \u0438 \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u043e\u0441\u0442\u044c \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 | ProHoster","og:description":".","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-09T21:00:00+00:00","article:modified_time":"2020-02-18T11:00:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52525","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 03:54:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:41:25","updated":"2026-01-24 03:54:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/52525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}