{"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\/nl\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFault tolerance and high availability are broad topics, so we will dedicate separate articles to RabbitMQ and Kafka. This article is about RabbitMQ, and the next one will be about Kafka, in comparison to RabbitMQ. The article is long, so make yourself comfortable.<\/p>\n<p>We will discuss fault tolerance strategies, consistency, and high availability (HA), as well as the trade-offs that come with each strategy. RabbitMQ can operate on a cluster of nodes, classifying it as a distributed system. When it comes to distributed systems, we often talk about consistency and availability. <\/p>\n<p>These concepts describe how a system behaves during a failure. Network connection failure, server failure, hard disk failure, temporary server unavailability due to garbage collection, packet loss, or slowed network connection. All of these can lead to data loss or conflicts. It turns out that it is practically impossible to have a system that is both completely consistent (without data loss, without data discrepancies) and available (able to accept read and write operations) for all types of failures.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nWe will see that consistency and availability are on opposite ends of the spectrum, and you need to choose which way to optimize. The good news is that with RabbitMQ such a choice is possible. You have some 'nerdy' levers to shift the balance towards greater consistency or greater availability.<\/p>\n<p>We will pay special attention to which configurations lead to data loss due to acknowledged messages. There is a chain of responsibility between publishers, brokers, and consumers. Once a message is handed over to the broker, it is their job not to lose the message. When the broker acknowledges receipt of the message to the publisher, we do not expect it to be lost. But we will see that this can indeed happen depending on your broker and publisher's configuration.<\/p>\n<h1>Single-node resilience primitives<\/h1>\n<p><\/p>\n<h3>Resilient queues\/routing<\/h3>\n<p>\nIn RabbitMQ zijn er twee soorten wachtrijen: duurzame (durable) en niet-duurzame (non-durable). Alle wachtrijen worden opgeslagen in de Mnesia-database. Duurzame wachtrijen worden opnieuw verklaard bij het opstarten van de node en overleven daarom een herstart, systeemfout of servercrash (zolang de gegevens behouden blijven). Dit betekent dat zolang je de routing (exchange) en wachtrij als duurzaam declareert, de infrastructuur van wachtrijen\/routing opnieuw operationeel zal zijn.<\/p>\n<p>Niet-duurzame wachtrijen en routing worden verwijderd bij het herstarten van de node.<\/p>\n<h3>Duurzame berichten<\/h3>\n<p>\nHet feit dat een wachtrij duurzaam is, betekent niet dat al zijn berichten de herstart van de node overleven. Alleen de berichten die door de publisher als <i>duurzaam<\/i> (persistent) zijn ingesteld, worden hersteld. Duurzame berichten cre\u00ebren echt een extra belasting voor de broker, maar als het verlies van een bericht onacceptabel is, is er geen andere optie.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 1. Duurzaamheidsmatrix<\/i><\/p>\n<h1>Clustering met wachtrijspiegeling<\/h1>\n<p>\nOm het verlies van de broker te overleven, hebben we redundantie nodig. We kunnen meerdere RabbitMQ-nodes in een cluster samenvoegen en vervolgens extra redundantie toevoegen door wachtrijen tussen verschillende nodes te repliceren. Op deze manier, als \u00e9\u00e9n node uitvalt, verliezen we geen gegevens en blijven we beschikbaar. <\/p>\n<p>Wachrijspiegeling:<\/p>\n<ul>\n<li>\u00e9\u00e9n hoofdwachtrij (master), die alle schrijf- en leesopdrachten ontvangt\n<\/li>\n<li>\u00e9\u00e9n of meerdere spiegels, die alle berichten en metadata uit de hoofdwachtrij ontvangen. Deze spiegels zijn niet bedoeld voor schaalvergroting, maar uitsluitend voor redundantie.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 2. Wachrijspiegeling<\/i><\/p>\n<p>Wachrijspiegeling wordt ingesteld met de juiste beleidsregels. In deze beleidsregels kan de replicatiefactor worden gekozen en zelfs de nodes waarop de wachtrij moet worden geplaatst. Voorbeelden:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (\u00e9\u00e9n master en \u00e9\u00e9n spiegel)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Bevestiging aan de publisher<\/h1>\n<p>\nVoor een consistente opslag zijn bevestigingen van de publisher nodig (Publisher Confirms). Zonder deze bestaat de kans op verlies van berichten. De bevestiging wordt naar de publisher gestuurd nadat het bericht op de schijf is opgeslagen. RabbitMQ slaat berichten niet op bij ontvangst, maar op een periodieke basis, ongeveer enkele honderden milliseconden. Wanneer een wachtrij wordt gespiegeld, wordt de bevestiging pas verzonden nadat alle spiegels ook hun kopie van het bericht op de schijf hebben opgeslagen. Dit betekent dat het gebruik van bevestigingen vertraging met zich meebrengt, maar als gegevensbeveiliging van belang is, zijn ze noodzakelijk.<\/p>\n<h1>Foutbestendige wachtrij<\/h1>\n<p>\nWanneer de broker stopt of crasht, vallen alle hoofd wachtrijen (masters) op deze node samen met hem uit. Vervolgens kiest het cluster de oudste spiegel van elke master en promoot deze tot de nieuwe master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 3. Meerdere gespiegelde wachtrijen en hun beleidsregels<\/i><\/p>\n<p>Broker 3 crasht. Merk op dat de spiegel van Wachtrij C op Broker 2 wordt gepromoveerd tot master. Let ook op dat er een nieuwe spiegel voor Wachtrij C wordt aangemaakt op Broker 1. RabbitMQ probeert altijd de replicatiefactor te handhaven zoals aangegeven in uw beleidsregels.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 4. Broker 3 valt uit, wat de storing van Wachtrij C veroorzaakt<\/i> <\/p>\n<p>De volgende Broker 1 valt uit! We hebben nog maar \u00e9\u00e9n broker over. De spiegel van Wachtrij B wordt gepromoveerd tot master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 5<\/i><\/p>\n<p>We hebben Broker 1 hersteld. Ongeacht hoe succesvol de gegevens de verlies en herstart van de broker hebben doorstaan, worden alle gespiegelde wachtrijberichten verworpen bij de herstart. Dit is belangrijk om op te merken, omdat er gevolgen aan verbonden zijn. We zullen deze gevolgen snel bespreken. Broker 1 is nu weer lid van het cluster, en het cluster probeert zich aan de beleidsregels te houden en maakt daarom spiegels aan op Broker 1.<\/p>\n<p>In dit geval was het verlies van Broker 1 volledig, evenals de gegevens, dus de niet-gespiegelde Wachtrij B is volledig verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 6. Broker 1 komt weer online<\/i><\/p>\n<p>Broker 3 is weer operationeel, zodat de wachtrijen A en B hun gehanteerde spiegels terugkrijgen om in hun HA-beleid te voorzien. Maar nu staan alle hoofdwachtrijen op \u00e9\u00e9n knooppunt! Dit is niet ideaal, een gelijkmatige verdeling over de knooppunten is beter. Helaas zijn er hier geen speciale opties voor het herschikken van de master. We komen hier later op terug, want eerst moet de synchronisatie van de wachtrij worden besproken. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 7. Broker 3 komt weer operationeel. Alle hoofdwachtrijen staan op \u00e9\u00e9n knooppunt!<\/i><\/p>\n<p>Zo heeft u nu een idee hoe spiegels redundantie en fouttolerantie bieden. Dit garandeert beschikbaarheid in het geval van een storing van een knooppunt en beschermt tegen gegevensverlies. Maar we zijn nog niet klaar, want het is in werkelijkheid veel ingewikkelder.<\/p>\n<h1>Synchronisatie<\/h1>\n<p>\nBij het aanmaken van een nieuw spiegel worden alle nieuwe berichten altijd gerepliceerd naar deze spiegel en naar andere. Wat betreft bestaande gegevens in de hoofdwachtrij, kunnen we ze repliceren naar de nieuwe spiegel, die een volledige kopie van de master wordt. We kunnen ook besluiten om bestaande berichten niet te repliceren en laten de hoofdwachtrij en de nieuwe spiegel synchroniseren in de tijd, waarbij nieuwe berichten aan het einde komen en bestaande berichten uit het begin van de hoofdwachtrij verdwijnen.<\/p>\n<p>Deze synchronisatie gebeurt automatisch of handmatig en wordt beheerd via het beleid van de wachtrijen. Laten we een voorbeeld bekijken.<\/p>\n<p>We hebben twee gespiegelde wachtrijen. Wachtrij A synchroniseert automatisch, terwijl Wachtrij B handmatig synchroniseert. In beide wachtrijen zijn tien berichten.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 8. Twee wachtrijen met verschillende synchronisatiestanden<\/i><\/p>\n<p>Nu verliezen we Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 9. Broker 3 is uitgevallen<\/i><\/p>\n<p>Broker 3 komt weer operationeel. De cluster cre\u00ebert een spiegel voor elke wachtrij op een nieuw knooppunt en synchroniseert automatisch de nieuwe Wachtrij A met de master. Echter, de spiegel van de nieuwe Wachtrij B blijft leeg. Zo hebben we volledige redundantie voor Wachtrij A en slechts \u00e9\u00e9n spiegel voor de bestaande berichten van Wachtrij B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 10. De nieuwe spiegel van Wachtrij A ontvangt alle bestaande berichten, terwijl de nieuwe spiegel van Wachtrij B dat niet doet<\/i><\/p>\n<p>In beide wachtrijen komen nog eens tien berichten binnen. Dan valt Broker 2 uit, en Wachtrij A keert terug naar het oudste spiegelbeeld dat zich op Broker 1 bevindt. Bij de storing vindt er geen dataverlies plaats. In Wachtrij B zijn er twintig berichten in de master en slechts tien in de spiegel, omdat deze wachtrij de oorspronkelijke tien berichten nooit heeft gerepliceerd.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 11. Wachtrij A keert terug naar Broker 1 zonder verlies van berichten.<\/i><\/p>\n<p>In beide wachtrijen komen weer tien berichten binnen. Nu valt Broker 1 uit. Wachtrij A schakelt zonder problemen over naar de spiegel zonder verlies van berichten. Echter, Wachtrij B ondervindt problemen. Op dit moment kunnen we ofwel de beschikbaarheid ofwel de consistentie optimaliseren. <\/p>\n<p>Als we de beschikbaarheid willen optimaliseren, dan moet het beleid <b><i>ha-promote-on-failure<\/i><\/b> worden ingesteld op <b><i>altijd<\/i><\/b>. Deze waarde is standaard, dus het is ook mogelijk om het beleid helemaal niet op te geven. In dat geval staan we in wezen uitval toe in ongesynchroniseerde spiegels. Dit leidt tot dataverlies, maar de wachtrij blijft lees- en schrijfbaar.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 12. Wachtrij A keert terug naar Broker 3 zonder verlies van berichten. Wachtrij B keert terug naar Broker 3 met verlies van tien berichten.<\/i><\/p>\n<p>We kunnen ook instellen <code>ha-promote-on-failure<\/code> op de waarde van <code>when-synced<\/code>. In dat geval wacht de wachtrij in plaats van terug te keren naar de spiegel tot Broker 1 met zijn gegevens weer operationeel is. Na zijn terugkeer komt de hoofdwachtrij weer op Broker 1 zonder verlies van gegevens. Beschikbaarheid wordt opgeofferd voor gegevensveiligheid. Maar dit is een risicovolle modus, die zelfs kan leiden tot volledig dataverlies, wat we binnenkort zullen bekijken.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 13. Wachtrij B blijft niet toegankelijk na de uitval van Broker 1.<\/i><\/p>\n<p>Je zou kunnen vragen: \"Misschien is het beter om automatische synchronisatie nooit te gebruiken?\". Het antwoord is dat synchronisatie een blokkering is. Tijdens de synchronisatie kan de hoofdwachtrij geen lees- of schrijfoperaties uitvoeren!<\/p>\n<p>Laten we een voorbeeld overwegen. We hebben nu zeer grote wachtrijen. Hoe kunnen ze zo groot worden? Om verschillende redenen:<\/p>\n<ul>\n<li>Wachtrijen worden niet actief gebruikt.\n<\/li>\n<li>Dit zijn supersnelle wachtrijen, en op dit moment werken de consumenten langzaam. \n<\/li>\n<li>Dit zijn supersnelle wachtrijen, er is een storing opgetreden, en de consumenten halen in.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 14. Twee grote wachtrijen met verschillende synchronisatiemodi<\/i><\/p>\n<p>Nu valt Broker 3 uit.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 15. Broker 3 valt uit, waarbij er \u00e9\u00e9n master en \u00e9\u00e9n mirror in elke wachtrij overblijft<\/i><\/p>\n<p>Broker 3 komt weer online, en nieuwe spiegels worden aangemaakt. Hoofdwachtrij A begint bestaande berichten naar de nieuwe mirror te repliceren, en gedurende deze tijd is de wachtrij niet beschikbaar. De replicatie van gegevens duurt twee uur, wat leidt tot twee uur stilstand voor deze wachtrij!<\/p>\n<p>Echter, Wachtrij B blijft gedurende de hele periode beschikbaar. Het heeft wat redundantie opgeofferd voor beschikbaarheid.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Fig. 16. De wachtrij blijft tijdens synchronisatie niet beschikbaar<\/i><\/p>\n<p>Na twee uur wordt Wachtrij A ook weer beschikbaar en kan het opnieuw lees- en schrijfoperaties uitvoeren.<\/p>\n<h3>Updates<\/h3>\n<p>\nDit blokkeren tijdens de synchronisatie bemoeilijkt het bijwerken van clusters met zeer grote wachtrijen. Op een bepaald moment moet de node met de master opnieuw worden opgestart, wat betekent dat we ofwel naar de mirror overschakelen, of de wachtrij uitschakelen tijdens de serverupdate. Als we kiezen voor overschakelen, verliezen we berichten als de spiegels niet gesynchroniseerd zijn. Standaard wordt tijdens het uitschakelen van de broker niet overgeschakeld op een niet-gesynchroniseerde mirror. Dit betekent dat zodra de broker terugkomt, we geen berichten verliezen; de enige schade was de stilstand van de wachtrij. Het gedrag bij het uitschakelen van de broker wordt bepaald door het beleid <code>ha-promote-on-shutdown<\/code>. Een van de twee waarden kan worden ingesteld:<\/p>\n<ul>\n<li><code>altijd<\/code>= overschakelen naar niet-gesynchroniseerde spiegels is ingeschakeld\n<\/li>\n<li><code>when-synced<\/code>= overschakelen alleen naar de gesynchroniseerde mirror, anders wordt de wachtrij niet beschikbaar voor lezen en schrijven. De wachtrij komt weer online zodra de broker terugkomt<\/li>\n<\/ul>\n<p>\nHoe dan ook, met grote wachtrijen moet worden gekozen tussen dataverlies en onbeschikbaarheid.<\/p>\n<h3>Wanneer beschikbaarheid de gegevensbeveiliging verhoogt<\/h3>\n<p>\nVoordat een beslissing wordt genomen, moet nog een complicatie in overweging worden genomen. Hoewel automatische synchronisatie beter is voor redundantie, hoe be\u00efnvloedt het de gegevensbeveiliging? Natuurlijk, met betere redundantie heeft RabbitMQ minder kans om bestaande berichten te verliezen, maar hoe zit het met nieuwe berichten van publishers?<\/p>\n<p>Hier moet het volgende in overweging worden genomen:<\/p>\n<ul>\n<li>Kan een publisher gewoon een fout teruggeven, waarna de bovenliggende service of gebruiker later een nieuwe poging doet?\n<\/li>\n<li>Kan een publisher een bericht lokaal of in een database opslaan om later opnieuw te proberen?<\/li>\n<\/ul>\n<p>\nAls de publisher slechts een bericht kan afwijzen, verbetert het verbeteren van de beschikbaarheid ook de beveiliging van gegevens.<\/p>\n<p>Daarom moeten we naar een balans zoeken, en de oplossing hangt af van de specifieke situatie.<\/p>\n<h1>Problemen met ha-promote-on-failure=when-synced<\/h1>\n<p>\nIdee <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> bestaat uit het voork\u00f3men van overschakelen naar een niet-synchroon spiegel en zo het verlies van gegevens te vermijden. De wachtrij blijft onleesbaar en niet schrijfbaar. In plaats daarvan proberen we de gecrashte broker met onbeschadigde gegevens weer op te starten, zodat deze als master verder kan werken zonder gegevensverlies. <\/p>\n<p>Maar (en dat is een groot maar) als de broker zijn gegevens heeft verloren, hebben we een groot probleem: de wachtrij is verloren! Alle gegevens zijn verdwenen! Zelfs als je spiegelt die meestal de hoofdwachtrij inhalen, worden ook deze spiegels afgewezen.<\/p>\n<p>Om een knooppunt met dezelfde naam opnieuw toe te voegen, zeggen we tegen het cluster de verloren knooppunt te vergeten (met het commando <i>rabbitmqctl forget_cluster_node<\/i>) en een nieuwe broker met dezelfde hostnaam te starten. Zolang het cluster de verloren knooppunt herinnert, herinnert het zich de oude wachtrij en niet-synchrone spiegels. Wanneer we het cluster zeggen de verloren knooppunt te vergeten, wordt deze wachtrij ook vergeten. Nu moet deze opnieuw worden aangekondigd. We hebben alle gegevens verloren, hoewel we spiegels met een gedeeltelijke set gegevens hadden. Het zou beter zijn geweest om over te schakelen naar een niet-synchroon spiegel!<\/p>\n<p>Daarom is handmatige synchronisatie (en het niet uitvoeren van synchronisatie) in combinatie met <code>ha-promote-on-failure=when-synced<\/code>, naar mijn mening, behoorlijk riskant. Documenten zeggen dat deze optie bestaat voor gegevensbeveiliging, maar het is een dubbelzijdig mes.<\/p>\n<h1>Herbalanceren van masters<\/h1>\n<p>\nZoals beloofd, keren we terug naar het probleem van het samenklonteren van alle masters op \u00e9\u00e9n of enkele knooppunten. Dit kan zelfs gebeuren door een \"rolling\" update van het cluster. In een cluster met drie knooppunten zullen alle hoofdwachtrijen zich op \u00e9\u00e9n of twee knooppunten verzamelen.<\/p>\n<p>Herbalanceren van masters kan problematisch zijn om twee redenen:<\/p>\n<ul>\n<li>Er zijn geen goede tools voor het uitvoeren van herbalancering<\/li>\n<li>Synchronisatie van wachtrijen<\/li>\n<\/ul>\n<p>\nVoor herbalancering is er een derde partij <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">plugin<\/a><\/noindex>, die niet officieel wordt ondersteund. Met betrekking tot externe plugins in de RabbitMQ-handleiding <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">staat<\/a><\/noindex>: \u00abDe plugin biedt enkele extra hulpmiddelen voor configuratie en rapportage, maar wordt niet ondersteund of geverifieerd door het RabbitMQ-team. Gebruik het op eigen risico\u00bb.<\/p>\n<p>Er is nog een andere truc om de primaire wachtrij te verplaatsen via HA-beleidsregels. Dit wordt genoemd in de handleiding <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">script<\/a><\/noindex> voor dit doel. Het werkt als volgt:<\/p>\n<ul>\n<li>Verwijdert alle spiegels met behulp van een tijdelijke beleidsregel met een hogere prioriteit dan de bestaande HA-beleidsregel.\n<\/li>\n<li>Wijzigt de tijdelijke HA-beleidsregel om de modus 'nodes' te gebruiken met de vermelding van de node waaraan de primaire wachtrij moet worden verplaatst.\n<\/li>\n<li>Synchroniseert de wachtrij voor gedwongen migratie.\n<\/li>\n<li>Na voltooiing van de migratie verwijdert het de tijdelijke beleidsregel. De oorspronkelijke HA-beleidsregel komt weer in werking en het vereiste aantal spiegels wordt aangemaakt.<\/li>\n<\/ul>\n<p>\nEen nadeel van deze aanpak is dat deze mogelijk niet werkt als je grote wachtrijen of strikte eisen aan redundantie hebt.<\/p>\n<p>Laten we nu bekijken hoe RabbitMQ-clusters omgaan met netwerkpartities.<\/p>\n<h1>Verbetering van consistentie<\/h1>\n<p>\nNodes in een gedistribueerd systeem zijn verbonden via netwerkkoppelingen, en deze netwerkkoppelingen kunnen en zullen uitvallen. De frequentie van uitval hangt af van de lokale infrastructuur of de betrouwbaarheid van de gekozen cloud. Hoe dan ook, gedistribueerde systemen moeten in staat zijn om hiermee om te gaan. We staan opnieuw voor de keuze tussen beschikbaarheid en consistentie, en het goede nieuws is dat RabbitMQ beide opties biedt (maar nooit tegelijkertijd).<\/p>\n<p>Met RabbitMQ hebben we twee hoofdmogelijkheden:<\/p>\n<ul>\n<li>Logisch splitsen (split-brain) toestaan. Dit zorgt voor beschikbaarheid, maar kan gegevensverlies veroorzaken.\n<\/li>\n<li>Logisch splitsen verbieden. Dit kan leiden tot tijdelijk verlies van beschikbaarheid, afhankelijk van hoe clients verbinding maken met het cluster. Het kan ook leiden tot totale onbeschikbaarheid in een cluster bestaande uit twee nodes.<\/li>\n<\/ul>\n<p>\nMaar wat is logisch splitsen? Dit is wanneer een cluster in twee\u00ebn wordt gesplitst door het verlies van netwerkkoppelingen. Aan elke kant worden spiegels gepromoveerd tot master, zodat uiteindelijk meerdere masters op elke wachtrij staan.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 17. De hoofdqueue en twee spiegels, elk op een aparte knooppunt. Dan ontstaat er een netwerkstoring en scheidt \u00e9\u00e9n spiegel. De gescheiden knooppunt ziet dat de twee andere zijn uitgevallen en bevordert zijn spiegels tot de master. Nu hebben we twee hoofdqueues, en beide staan schrijf- en leesoperaties toe.<\/i> <\/p>\n<p>Als publishers gegevens naar beide masters verzenden, krijgen we twee uiteenlopende kopie\u00ebn van de queue.<\/p>\n<p>Verschillende modi van RabbitMQ bieden ofwel beschikbaarheid ofwel consistentie.<\/p>\n<h3>De modus Ignore (standaardinstelling)<\/h3>\n<p>\nDeze modus biedt beschikbaarheid. Na een verlies van connectiviteit vindt er een logische splitsing plaats. Na het herstellen van de connectiviteit moet de beheerder beslissen welke sectie de voorkeur heeft. De verliezende kant wordt opnieuw opgestart, en alle verzamelde gegevens aan die kant gaan verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 18. Drie publishers zijn verbonden met drie brokers. Intern stuurt het cluster alle verzoeken naar de hoofqueue op Broker 2.<\/i><\/p>\n<p>Nu verliezen we Broker 3. Deze ziet dat de andere brokers zijn uitgevallen en bevordert zijn spiegel tot master. Dit leidt tot een logische splitsing.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 19. Logische splitsing (split-brain). Schrijfacties gaan naar twee hoofdqueues en twee kopie\u00ebn divergeren.<\/i><\/p>\n<p>De connectiviteit herstelt zich, maar de logische splitsing blijft bestaan. De beheerder moet handmatig de verliezende kant kiezen. In het onderstaande geval herstart de beheerder Broker 3. Alle berichten die niet zijn verzonden, gaan verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 20. De beheerder schakelt Broker 3 uit.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 21. De beheerder start Broker 3, en deze voegt zich bij het cluster, waarbij alle berichten die daar waren achtergebleven verloren gaan.<\/i><\/p>\n<p>Tijdens het verlies van connectiviteit en na het herstel was het cluster en deze queue beschikbaar voor lezen en schrijven.<\/p>\n<h3>De modus Autoheal<\/h3>\n<p>\nWerkt vergelijkbaar met de modus Ignore, met dien verstande dat het cluster automatisch de verliezende kant kiest na een splitsing en herstel van connectiviteit. De verliezende kant keert leeg terug naar het cluster, en de queue verliest alle berichten die alleen naar die kant waren verzonden.<\/p>\n<h3>De modus Pause Minority<\/h3>\n<p>\nAls we logische splitsing willen voorkomen, is onze enige optie om te stoppen met lezen en schrijven aan de kleinere kant na de clusteronderbreking. Wanneer de broker ziet dat hij aan de kleinere kant is, stopt hij met werken, d.w.z. hij sluit alle bestaande verbindingen en weigert nieuwe. Een keer per seconde controleert hij het herstel van de connectiviteit. Zodra de connectiviteit hersteld is, herstart hij en voegt zich weer bij het cluster.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 22. Drie publishers zijn verbonden met drie brokers. Intern stuurt het cluster alle aanvragen naar de hoofqueue op Broker 2.<\/i><\/p>\n<p>Daarna scheiden Brokers 1 en 2 zich van Broker 3. In plaats van zijn spiegel naar master te verhogen, stopt Broker 3 met werken en wordt onbereikbaar.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 23. Broker 3 stopt met werken, ontkoppelt alle klanten en weigert verbindingsaanvragen.<\/i><\/p>\n<p>Zodra de connectiviteit hersteld is, keert hij terug naar het cluster.<\/p>\n<p>Laten we een ander voorbeeld bekijken, waarbij de hoofqueue op Broker 3 staat.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 24. De hoofqueue op Broker 3.<\/i><\/p>\n<p>Dan treedt dezelfde connectiviteitsverliezen op. Broker 3 gaat op pauze, omdat hij aan de kleinere kant staat. Aan de andere kant zien de knooppunten dat Broker 3 is uitgevallen, zodat de oudere spiegel van Brokers 1 en 2 naar master wordt verhoogd.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 25. Overschakeling naar Broker 2 bij de onbereikbaarheid van Broker 3.<\/i><\/p>\n<p>Wanneer de connectiviteit is hersteld, zal Broker 3 zich bij het cluster voegen.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ versus Kafka: fouttolerantie en hoge beschikbaarheid in clusters\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Figuur 26. Het cluster is teruggekeerd naar normale werking.<\/i><\/p>\n<p>Hier is het belangrijk om te begrijpen dat we consistentie bereiken, maar ook beschikbaarheid kunnen verkrijgen. <i><b>als<\/b><\/i> we kunnen de klanten met succes naar het grotere deel van de sectie overbrengen. Voor de meeste situaties zou ik persoonlijk de Pause Minority-modus kiezen, maar dit hangt echt af van het specifieke geval.<\/p>\n<p>Om beschikbaarheid te waarborgen, is het belangrijk om ervoor te zorgen dat klanten succesvol verbinding maken met de knoop. Laten we onze opties bekijken.<\/p>\n<h1>Het waarborgen van de connectiviteit van klanten<\/h1>\n<p>\nWij hebben verschillende manieren om klanten na een verbindingsverlies naar de hoofdcluster of naar werkende knooppunten (na uitval van een knooppunt) te leiden. Laten we eerst herinneren dat een specifieke wachtrij op een bepaald knooppunt wordt geplaatst, maar dat de routering en beleidsregels op alle knooppunten worden gerepliceerd. Klanten kunnen verbinding maken met elk knooppunt, en de interne routering zal hen naar de juiste plek sturen. Maar wanneer een knooppunt is gepauzeerd, weigert het verbindingen, waardoor klanten verbinding moeten maken met een ander knooppunt. Als een knooppunt is uitgevallen, kan het daar nauwelijks iets aan doen.<\/p>\n<p>Onze opties:<\/p>\n<ul>\n<li>Toegang tot het cluster gebeurt via een load balancer die simpelweg de knooppunten in een ronde afloopt, waarbij klanten opnieuw verbinding proberen te maken tot een succesvolle verbinding is gemaakt. Als een knooppunt niet werkt of is gepauzeerd, zullen de verbindingspogingen naar dat knooppunt mislukken, maar volgende pogingen zullen naar andere servers gaan (in cyclische modus). Dit is geschikt voor kortdurend verbindingsverlies of een server die snel weer online kan komen.\n<\/li>\n<li>Toegang tot het cluster via een load balancer en het verwijderen van gepauzeerde\/uitgevallen knooppunten uit de lijst zodra deze zijn gedetecteerd. Als dit snel gebeurt en klanten in staat zijn om opnieuw verbinding te maken, krijgen we een constante beschikbaarheid.\n<\/li>\n<li>Geef elke klant een lijst van alle knooppunten, en de klant kiest willekeurig een van hen bij het maken van een verbinding. Als bij het maken van de verbinding een fout optreedt, gaat hij naar het volgende knooppunt in de lijst totdat hij verbinding maakt.\n<\/li>\n<li>Verwijder het verkeer van het uitgevallen\/gepauzeerde knooppunt met behulp van DNS. Dit wordt gedaan met een korte TTL.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Conclusies<\/h1>\n<p>\nRabbitMQ-cluster heeft zijn eigen voordelen en nadelen. De meest ernstige nadelen zijn dat:<\/p>\n<ul>\n<li>bij het aansluiten op het cluster knooppunten hun gegevens afwijzen;\n<\/li>\n<li>blokkering synchronisatie leidt tot onbeschikbaarheid van de wachtrij.<\/li>\n<\/ul>\n<p>\nAlle moeilijke beslissingen komen voort uit deze twee kenmerken van de architectuur. Als RabbitMQ gegevens zou kunnen opslaan bij het opnieuw verbinden van de cluster, zou de synchronisatie sneller plaatsvinden. Als het in staat zou zijn om niet-blokkerende synchronisatie uit te voeren, zou het beter grote wachtrijen ondersteunen. Het oplossen van deze twee problemen zou de prestaties van RabbitMQ als fouttolerante en hoogbeschikbare messaging-technologie aanzienlijk verbeteren. Ik zou RabbitMQ met clustering in de volgende situaties niet aanraden:<\/p>\n<ul>\n<li>Onbetrouwbaar netwerk.\n<\/li>\n<li>Onbetrouwbare opslag.\n<\/li>\n<li>Zeer grote wachtrijen.<\/li>\n<\/ul>\n<p>\nWat betreft instellingen voor hoge beschikbaarheid, overweeg de volgende:<\/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> (of <code>autoheal<\/code>)\n<\/li>\n<li>betrouwbare berichten\n<\/li>\n<li>zorg ervoor dat clients verbinding maken met de actieve node wanneer een node uitvalt<\/li>\n<\/ul>\n<p>\nVoor consistentie (gegevensbeveiliging) overweeg de volgende instellingen:<\/p>\n<ul>\n<li>Publisher Confirms en Handmatige Bevestigingen aan de kant van de consument\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, als uitgevers later opnieuw kunnen proberen en als je zeer betrouwbare opslag hebt! Anders zet je <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (maar voor grote inactieve wachtrijen kan handmatige modus nodig zijn; bovendien, overweeg of een onbeschikbaarheid kan leiden tot verlies van berichten)\n<\/li>\n<li>Pause Minority modus\n<\/li>\n<li>betrouwbare berichten<\/li>\n<\/ul>\n<p>\nWe hebben nog niet alle aspecten van fouttolerantie en hoge beschikbaarheid behandeld; bijvoorbeeld hoe veilig administratieve procedures uit te voeren (zoals geleidelijke updates). We moeten ook praten over federatie en de Shovel-plugin.<\/p>\n<p>Als ik nog iets ben vergeten, laat het me weten.<\/p>\n<p>Zie ook mijn <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">bericht<\/a><\/noindex>, waar ik een ramp op de RabbitMQ-cluster uitvoer met Docker en Blockade om enkele scenario's van berichtverlies te testen zoals beschreven in dit artikel.<\/p>\n<p>Vorige artikelen in de serie: <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 \/>Bron: <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.3 - 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\/nl\/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.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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\udd47 RabbitMQ tegen Kafka: fouttolerantie en hoge beschikbaarheid in clusters | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/52525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}