{"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\/de\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","title":{"rendered":"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAusfallsicherheit und hohe Verf\u00fcgbarkeit sind umfassende Themen, daher widmen wir RabbitMQ und Kafka separate Artikel. Dieser Artikel behandelt RabbitMQ, und der n\u00e4chste wird Kafka im Vergleich zu RabbitMQ behandeln. Der Artikel ist lang, also machen Sie es sich bequem.<\/p>\n<p>Lassen Sie uns die Strategien zur Ausfallsicherheit, Konsistenz und hohen Verf\u00fcgbarkeit (HA) sowie die Kompromisse, die in jeder Strategie eingegangen werden m\u00fcssen, betrachten. RabbitMQ kann in einem Cluster von Knoten arbeiten und wird dann als verteiltes System klassifiziert. Wenn es um verteilte Systeme geht, sprechen wir oft \u00fcber Konsistenz und Verf\u00fcgbarkeit. <\/p>\n<p>Diese Konzepte beschreiben, wie das System bei Ausf\u00e4llen reagiert. Ein Ausfall der Netzwerkverbindung, ein Serverausfall, ein Festplattendefekt, tempor\u00e4re Serverunzug\u00e4nglichkeit aufgrund von Garbage Collection, Paketverluste oder eine Verlangsamung der Netzwerkverbindung. All dies kann zu Datenverlust oder Konflikten f\u00fchren. Es scheint praktisch unm\u00f6glich zu sein, ein System gleichzeitig vollst\u00e4ndig konsistent (ohne Datenverluste, ohne Inkonsistenzen) und verf\u00fcgbar (also f\u00e4hig, Lese- und Schreiboperationen entgegenzunehmen) f\u00fcr alle Ausfallvarianten zu betreiben.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nWir werden sehen, dass Konsistenz und Verf\u00fcgbarkeit an verschiedenen Enden des Spektrums stehen und dass Sie w\u00e4hlen m\u00fcssen, in welche Richtung Sie optimieren m\u00f6chten. Die gute Nachricht ist, dass dies mit RabbitMQ m\u00f6glich ist. Sie haben sozusagen \u201eNerd-Hebel\u201c, um das Gleichgewicht zugunsten gr\u00f6\u00dferer Konsistenz oder gr\u00f6\u00dferer Verf\u00fcgbarkeit zu verschieben.<\/p>\n<p>Besonderes Augenmerk legen wir darauf, welche Konfigurationen zu Datenverlust aufgrund best\u00e4tigter Nachrichten f\u00fchren. Es gibt eine Verantwortlichkeitskette zwischen Publishern, Brokern und Verbrauchern. Sobald die Nachricht an den Broker \u00fcbermittelt wird, liegt es in seiner Verantwortung, die Nachricht nicht zu verlieren. Wenn der Broker dem Publisher den Erhalt der Nachricht best\u00e4tigt, erwarten wir nicht, dass sie verloren geht. Doch wir werden sehen, dass dies tats\u00e4chlich abh\u00e4ngig von der Konfiguration Ihres Brokers und Publishers passieren kann.<\/p>\n<h1>Primitives zur Stabilit\u00e4t eines Knotens<\/h1>\n<p><\/p>\n<h3>Stabile Warteschlangen\/Routing<\/h3>\n<p>\nIn RabbitMQ gibt es zwei Arten von Warteschlangen: dauerhaft (durable) und nicht dauerhaft (non-durable). Alle Warteschlangen werden in der Mnesia-Datenbank gespeichert. Dauerhafte Warteschlangen werden beim Start des Knotens erneut deklariert und \u00fcberstehen somit einen Neustart, einen Systemausfall oder einen Serverfehler (solange die Daten gespeichert bleiben). Das bedeutet, solange Sie Routing (exchange) und Warteschlange als dauerhaft deklarieren, wird die Infrastruktur der Warteschlangen\/Routing in den Betriebsmodus zur\u00fcckkehren.<\/p>\n<p>Nicht dauerhafte Warteschlangen und Routing werden beim Neustart des Knotens gel\u00f6scht.<\/p>\n<h3>Dauerhafte Nachrichten<\/h3>\n<p>\nNur weil die Warteschlange langlebig ist, bedeutet das nicht, dass alle ihre Nachrichten einen Neustart des Knotens \u00fcberstehen. Es werden nur die Nachrichten wiederhergestellt, die vom Publisher als <i>best\u00e4ndig<\/i> (persistent) markiert sind. Best\u00e4ndige Nachrichten belasten tats\u00e4chlich den Broker, aber wenn der Verlust einer Nachricht inakzeptabel ist, bleibt uns keine andere Wahl.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/8b8e2de4ef82bf8497960657aac0ddb0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 1. Matrix der Best\u00e4ndigkeit<\/i><\/p>\n<h1>Clusterbildung mit Warteschlangen-Spiegelung<\/h1>\n<p>\nUm den Verlust des Brokers zu \u00fcberstehen, ben\u00f6tigen wir Redundanz. Wir k\u00f6nnen mehrere RabbitMQ-Knoten in einem Cluster zusammenfassen und dann durch die Replikation von Warteschlangen zwischen mehreren Knoten zus\u00e4tzliche Redundanz hinzuf\u00fcgen. Somit verlieren wir keine Daten und bleiben verf\u00fcgbar, selbst wenn ein Knoten ausf\u00e4llt. <\/p>\n<p>Warteschlangen-Spiegelung:<\/p>\n<ul>\n<li>eine Hauptwarteschlange (Master), die alle Lese- und Schreibbefehle empf\u00e4ngt\n<\/li>\n<li>ein oder mehrere Spiegel, die alle Nachrichten und Metadaten aus der Hauptwarteschlange erhalten. Diese Spiegel dienen nicht der Skalierung, sondern ausschlie\u00dflich der Redundanz.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/35f3d4bdc4f5e10da0e40eb91c5d8280.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 2. Warteschlangen-Spiegelung<\/i><\/p>\n<p>Die Spiegelung wird durch die entsprechende Richtlinie festgelegt. In dieser k\u00f6nnen Sie den Replikationsfaktor und sogar die Knoten ausw\u00e4hlen, auf denen die Warteschlange platziert werden soll. Beispiele:<\/p>\n<ul>\n<li><code>ha-mode: all<\/code>\n<\/li>\n<li><code>ha-mode: exactly, ha-params: 2<\/code> (ein Master und ein Spiegel)\n<\/li>\n<li><code>ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2<\/code><\/li>\n<\/ul>\n<p><\/p>\n<h1>Best\u00e4tigung an den Publisher<\/h1>\n<p>\nF\u00fcr eine konsistente Aufzeichnung sind Best\u00e4tigungen an den Publisher (Publisher Confirms) erforderlich. Ohne diese besteht das Risiko, dass Nachrichten verloren gehen. Die Best\u00e4tigung wird an den Publisher gesendet, nachdem die Nachricht auf die Festplatte geschrieben wurde. RabbitMQ schreibt Nachrichten nicht beim Empfang, sondern in regelm\u00e4\u00dfigen Abst\u00e4nden, im Bereich von mehreren Hundert Millisekunden. Wenn die Warteschlange gespiegelt wird, erfolgt die Best\u00e4tigung erst, nachdem alle Spiegel ebenfalls ihre Kopie der Nachricht auf die Festplatte geschrieben haben. Das bedeutet, dass die Verwendung von Best\u00e4tigungen eine Verz\u00f6gerung hinzuf\u00fcgt, aber wenn Datensicherheit wichtig ist, sind sie notwendig.<\/p>\n<h1>Ausfallsichere Warteschlange<\/h1>\n<p>\nWenn ein Broker ausf\u00e4llt oder den Dienst einstellt, fallen alle Hauptwarteschlangen (Master) auf diesem Knoten zusammen mit ihm aus. Der Cluster w\u00e4hlt dann das \u00e4lteste Spiegelbild jedes Masters und hebt es zum neuen Master hervor.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/8d8227c00643f35e0dc752b6617e18fb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 3. Mehrere gespiegelt Warteschlangen und deren Richtlinien.<\/i><\/p>\n<p>Broker 3 f\u00e4llt aus. Beachten Sie, dass das Spiegelbild der Warteschlange C auf Broker 2 zum Master erhoben wird. Zudem wird ein neues Spiegelbild f\u00fcr Warteschlange C auf Broker 1 erstellt. RabbitMQ versucht stets, das in Ihren Richtlinien angegebene Replikationsverh\u00e4ltnis aufrechtzuerhalten.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/d08b3ada22e79686d448714f7bab009a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 4. Broker 3 f\u00e4llt aus, was zu einem Ausfall der Warteschlange C f\u00fchrt.<\/i> <\/p>\n<p>Jetzt f\u00e4llt auch Broker 1 aus! Nur noch ein Broker bleibt \u00fcbrig. Das Spiegelbild der Warteschlange B wird zum Master erhoben.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 5<\/i><\/p>\n<p>Broker 1 wurde wiederhergestellt. Unabh\u00e4ngig davon, wie erfolgreich die Daten den Verlust und die Wiederherstellung des Brokers \u00fcberstanden haben, werden alle gespiegelt Nachrichten der Warteschlange beim Neustart verworfen. Dies ist wichtig zu beachten, da es Konsequenzen haben wird. Diese Konsequenzen werden wir bald n\u00e4her betrachten. Somit ist Broker 1 jetzt wieder Mitglied des Clusters und das Cluster versucht, die Richtlinien einzuhalten, wodurch Spiegelungen auf Broker 1 erstellt werden.<\/p>\n<p>In diesem Fall war der Verlust von Broker 1 vollst\u00e4ndig, ebenso wie die Daten, sodass die nicht gespiegelte Warteschlange B vollst\u00e4ndig verloren ist.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 6. Broker 1 wird wieder in Betrieb genommen.<\/i><\/p>\n<p>Broker 3 wurde wieder in Betrieb genommen, sodass die Warteschlangen A und B die auf ihm erstellten Spiegel zur\u00fcckerhalten, um ihren HA-Richtlinien gerecht zu werden. Aber jetzt sind alle Hauptwarteschlangen auf einem Knoten! Das ist nicht ideal, eine gleichm\u00e4\u00dfige Verteilung zwischen den Knoten w\u00e4re besser. Leider gibt es hier keine besonderen Optionen zum Neuausbalancieren der Master. Wir werden dieses Problem sp\u00e4ter noch einmal aufgreifen, da wir zuerst die Synchronisation der Warteschlange betrachten m\u00fcssen. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 7. Broker 3 wird wieder in Betrieb genommen. Alle Hauptwarteschlangen auf einem Knoten!<\/i><\/p>\n<p>So haben Sie jetzt eine Vorstellung davon, wie Spiegelungen Redundanz und Ausfallsicherheit gew\u00e4hrleisten. Dies sichert die Verf\u00fcgbarkeit im Falle eines Ausfalls eines Knotens und sch\u00fctzt vor Datenverlust. Aber wir sind noch nicht fertig, denn in Wirklichkeit ist alles viel komplexer.<\/p>\n<h1>Synchronisierung<\/h1>\n<p>\nWenn Sie ein neues Spiegelbild erstellen, werden alle neuen Nachrichten immer auf dieses Spiegelbild und alle anderen repliziert. Was die bestehenden Daten in der Hauptwarteschlange betrifft, k\u00f6nnen wir sie in das neue Spiegelbild replizieren, das eine vollst\u00e4ndige Kopie des Masters wird. Wir k\u00f6nnen auch die bestehenden Nachrichten nicht replizieren und es der Hauptwarteschlange und dem neuen Spiegelbild erlauben, sich im Laufe der Zeit zu treffen, wenn neue Nachrichten ans Ende eingehen und bestehende Nachrichten aus dem Kopf der Hauptwarteschlange entfernt werden.<\/p>\n<p>Eine solche Synchronisierung erfolgt automatisch oder manuell und wird durch Richtlinien f\u00fcr Warteschlangen gesteuert. Lassen Sie uns ein Beispiel betrachten.<\/p>\n<p>Wir haben zwei gespiegelte Warteschlangen. Warteschlange A wird automatisch synchronisiert, w\u00e4hrend Warteschlange B manuell synchronisiert wird. Beide Warteschlangen haben zehn Nachrichten.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/304f2a475fdd0cb6d3069140c667a0a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 8. Zwei Warteschlangen mit unterschiedlichen Synchronisierungsmodi<\/i><\/p>\n<p>Jetzt verlieren wir Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/49114966f440c407488bb467ff6dbf93.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 9. Broker 3 ist ausgefallen<\/i><\/p>\n<p>Broker 3 wird wieder in Betrieb genommen. Der Cluster erstellt ein Spiegelbild f\u00fcr jede Warteschlange auf dem neuen Knoten und synchronisiert automatisch die neue Warteschlange A mit dem Master. Das Spiegelbild der neuen Warteschlange B bleibt jedoch leer. Damit haben wir eine vollst\u00e4ndige Redundanz der Warteschlange A und nur ein Spiegelbild f\u00fcr die bestehenden Nachrichten der Warteschlange B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/adffc1f5eff8806edbd83772f338d67f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 10. Das neue Spiegelbild der Warteschlange A erh\u00e4lt alle vorhandenen Nachrichten, das neue Spiegelbild der Warteschlange B jedoch nicht<\/i><\/p>\n<p>In beiden Warteschlangen kommen jeweils weitere zehn Nachrichten an. Dann f\u00e4llt Broker 2 aus, und Warteschlange A wird auf das \u00e4lteste Spiegelbild zur\u00fcckgesetzt, das sich auf Broker 1 befindet. Bei einem Ausfall kommt es zu keinem Datenverlust. In Warteschlange B sind zwanzig Nachrichten im Master und nur zehn im Spiegelbild, da diese Warteschlange die urspr\u00fcnglichen zehn Nachrichten nie repliziert hat.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/c6cfef4bced5627bf243c2f020a42646.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 11. Warteschlange A wird von Broker 1 ohne Nachrichtenverlust zur\u00fcckgesetzt<\/i><\/p>\n<p>In beiden Warteschlangen gehen jeweils zehn Nachrichten ein. Jetzt f\u00e4llt Broker 1 aus. Warteschlange A wechselt problemlos auf das Spiegel-System, ohne Nachrichten zu verlieren. Bei Warteschlange B gibt es jedoch Probleme. In diesem Stadium k\u00f6nnen wir entweder die Verf\u00fcgbarkeit oder die Konsistenz optimieren. <\/p>\n<p>Wenn wir die Verf\u00fcgbarkeit optimieren m\u00f6chten, sollte die Richtlinie <b><i>ha-promote-on-failure<\/i><\/b> auf <b><i>always<\/i><\/b>. Dies ist der Standardwert, sodass die Richtlinie einfach nicht angegeben werden kann. In diesem Fall erlauben wir im Wesentlichen Ausf\u00e4lle bei nicht synchronisierten Spiegeln. Dies f\u00fchrt zum Verlust von Nachrichten, aber die Warteschlange bleibt weiterhin lesbar und beschreibbar.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/cd704cf4397184c212e1576b986abbaa.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 12. Warteschlange A wechselt zu Broker 3, ohne Nachrichten zu verlieren. Warteschlange B wechselt zu Broker 3 mit dem Verlust von zehn Nachrichten.<\/i><\/p>\n<p>Wir k\u00f6nnen auch <code>ha-promote-on-failure<\/code> auf <code>when-synced<\/code>. In diesem Fall wird die Warteschlange nicht auf den Stand des Spiegels zur\u00fcckgesetzt, sondern wartet darauf, dass Broker 1 mit seinen Daten wieder in den Betrieb zur\u00fcckkehrt. Nach seiner R\u00fcckkehr erh\u00e4lt die Hauptwarteschlange wieder Zugang \u00fcber Broker 1, ohne Datenverlust. Die Verf\u00fcgbarkeit wird jedoch zugunsten der Datensicherheit geopfert. Aber dies ist ein riskanter Modus, der sogar zu einem vollst\u00e4ndigen Datenverlust f\u00fchren kann, was wir in K\u00fcrze besprechen werden.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/03fed936fe75220e22f68432ca81b654.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 13. Die Warteschlange B bleibt nach dem Ausfall von Broker 1 nicht erreichbar.<\/i><\/p>\n<p>Sie k\u00f6nnten die Frage stellen: \u201eVielleicht sollten wir die automatische Synchronisation nie verwenden?\u201c. Die Antwort lautet, dass die Synchronisation eine blockierende Operation ist. W\u00e4hrend der Synchronisation kann die Hauptwarteschlange keine Lese- oder Schreibvorg\u00e4nge durchf\u00fchren!<\/p>\n<p>Schauen wir uns ein Beispiel an. Derzeit haben wir sehr gro\u00dfe Warteschlangen. Wie k\u00f6nnen sie so gro\u00df werden? Aus mehreren Gr\u00fcnden:<\/p>\n<ul>\n<li>Die Warteschlangen werden nicht aktiv genutzt.\n<\/li>\n<li>Es handelt sich um Hochgeschwindigkeitswarteschlangen, aber zurzeit arbeiten die Verbraucher langsam. \n<\/li>\n<li>Es handelt sich um Hochgeschwindigkeitswarteschlangen, es gab einen Ausfall, und die Verbraucher holen auf.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/dd4b0fd70cbbc0b7defc06536157770d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 14. Zwei gro\u00dfe Warteschlangen mit unterschiedlichen Synchronisationsmodi.<\/i><\/p>\n<p>Broker 3 f\u00e4llt nun aus.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/8c31cfdf485ab4c9dfe13e86a151df4f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 15. Broker 3 f\u00e4llt aus und hinterl\u00e4sst jeweils einen Master und ein Mirror in jeder Queue.<\/i><\/p>\n<p>Broker 3 wird wieder aktiviert und neue Mirrors werden erstellt. Die Haupt-Queue A beginnt, vorhandene Nachrichten auf das neue Mirror zu replizieren, und in dieser Zeit ist die Queue nicht verf\u00fcgbar. Die Datenreplikation ben\u00f6tigt zwei Stunden, was zu zwei Stunden Ausfallzeit f\u00fcr diese Queue f\u00fchrt!<\/p>\n<p>Die Queue B bleibt jedoch w\u00e4hrend des gesamten Zeitraums verf\u00fcgbar. Sie hat auf eine gewisse Redundanz verzichtet, um die Verf\u00fcgbarkeit zu gew\u00e4hrleisten.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/28e641300a1c3f4d70e29a16db51521e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 16. Die Queue bleibt w\u00e4hrend der Synchronisation nicht verf\u00fcgbar.<\/i><\/p>\n<p>Nach zwei Stunden wird auch Queue A wieder verf\u00fcgbar und kann erneut Lese- und Schreiboperationen annehmen.<\/p>\n<h3>Updates<\/h3>\n<p>\nEin solches blockierendes Verhalten w\u00e4hrend der Synchronisierung erschwert die Aktualisierung von Clustern mit sehr gro\u00dfen Warteschlangen. Irgendwann muss der Knoten mit dem Master neu gestartet werden, was entweder einen Wechsel zu einem Spiegel oder das Deaktivieren der Warteschlange w\u00e4hrend des Server-Updates bedeutet. Wenn wir uns f\u00fcr den Wechsel entscheiden, verlieren wir Nachrichten, falls die Spiegel nicht synchronisiert sind. Standardm\u00e4\u00dfig wird beim Deaktivieren des Brokers kein Wechsel zu einem nicht synchronisierten Spiegel durchgef\u00fchrt. Das bedeutet, dass wir, sobald der Broker wieder online ist, keine Nachrichten verlieren; der einzige Nachteil ist der einfache Warteschlangenstillstand. Die Verhaltensregeln beim Deaktivieren des Brokers werden durch die Richtlinie festgelegt. <code>ha-promote-on-shutdown<\/code>. Es kann einer von zwei Werte gesetzt werden:<\/p>\n<ul>\n<li><code>always<\/code>= Wechsel zu nicht synchronisierten Spiegeln aktiviert\n<\/li>\n<li><code>when-synced<\/code>= Wechsel nur zu synchronisierten Spiegeln, andernfalls wird die Warteschlange f\u00fcr Lese- und Schreibzugriffe nicht verf\u00fcgbar. Die Warteschlange wird wieder betriebsbereit, sobald der Broker zur\u00fcckkehrt.<\/li>\n<\/ul>\n<p>\nSo oder so muss man bei gro\u00dfen Warteschlangen zwischen Datenverlust und Nichtverf\u00fcgbarkeit w\u00e4hlen.<\/p>\n<h3>Wenn die Verf\u00fcgbarkeit erh\u00f6ht wird, steigt die Datensicherheit.<\/h3>\n<p>\nBevor Sie eine Entscheidung treffen, sollte noch ein weiteres Komplikation ber\u00fccksichtigt werden. Obwohl die automatische Synchronisierung f\u00fcr Redundanz besser ist, wie beeinflusst sie die Datensicherheit? Sicherlich verringert die bessere Redundanz von RabbitMQ die Wahrscheinlichkeit, vorhandene Nachrichten zu verlieren, aber wie steht es um neue Nachrichten von Publishern?<\/p>\n<p>Folgendes sollte ber\u00fccksichtigt werden:<\/p>\n<ul>\n<li>Kann der Publisher einfach einen Fehler zur\u00fcckgeben, und wird der \u00fcbergeordnete Dienst oder der Benutzer sp\u00e4ter einen erneuten Versuch unternehmen?\n<\/li>\n<li>Kann der Publisher die Nachricht lokal oder in einer Datenbank speichern, um es sp\u00e4ter erneut zu versuchen?<\/li>\n<\/ul>\n<p>\nWenn der Publisher lediglich in der Lage ist, die Nachricht abzulehnen, erh\u00f6ht die Verbesserung der Verf\u00fcgbarkeit tats\u00e4chlich auch die Datensicherheit.<\/p>\n<p>Daher ist es notwendig, ein Gleichgewicht zu finden, und die Entscheidung h\u00e4ngt von der spezifischen Situation ab.<\/p>\n<h1>Probleme mit ha-promote-on-failure=when-synced<\/h1>\n<p>\nDie Idee <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> besteht darin, dass wir den Wechsel zu einem nicht synchronisierten Spiegel verhindern und dadurch Datenverluste vermeiden. Die Warteschlange bleibt f\u00fcr Lese- oder Schreibvorg\u00e4nge unzug\u00e4nglich. Stattdessen versuchen wir, den ausgefallenen Broker mit intakten Daten wiederherzustellen, damit er ohne Datenverlust wieder als Master arbeiten kann. <\/p>\n<p>Aber (und das ist ein gro\u00dfes Aber), wenn der Broker seine Daten verloren hat, haben wir ein gro\u00dfes Problem: Die Warteschlange ist verloren! Alle Daten sind weg! Selbst wenn Sie Spiegel haben, die im Wesentlichen die Hauptwarteschlange einholen, werden auch diese Spiegel verworfen.<\/p>\n<p>Um einen Knoten mit demselben Namen erneut hinzuzuf\u00fcgen, sagen wir dem Cluster, dass es den verlorenen Knoten vergessen soll (mit dem Befehl <i>rabbitmqctl forget_cluster_node<\/i>) und starten einen neuen Broker mit demselben Hostnamen. Solange das Cluster sich an den verlorenen Knoten erinnert, sind die alte Warteschlange und die nicht synchronisierten Spiegel bekannt. Wenn dem Cluster gesagt wird, den verlorenen Knoten zu vergessen, wird auch diese Warteschlange vergessen. Jetzt muss sie erneut deklariert werden. Wir haben alle Daten verloren, auch wenn wir Spiegel mit einem teilweisen Datensatz hatten. Es w\u00e4re besser gewesen, auf einen nicht synchronisierten Spiegel umzuschalten!<\/p>\n<p>Deshalb ist die manuelle Synchronisierung (und das Unterlassen der Synchronisierung) in Kombination mit <code>ha-promote-on-failure=when-synced<\/code>, meiner Meinung nach, ziemlich riskant. Die Dokumente besagen, dass diese Option zur Datensicherheit existiert, aber sie ist ein zweischneidiges Schwert.<\/p>\n<h1>Neuverteilung der Master<\/h1>\n<p>\nWie versprochen, kehren wir zum Problem der Ansammlung aller Master auf einem oder mehreren Knoten zur\u00fcck. Dies kann sogar durch ein \u201eRolling\u201c Update des Clusters geschehen. In einem Cluster mit drei Knoten werden alle Hauptwarteschlangen sich auf einem oder zwei Knoten sammeln.<\/p>\n<p>Die Neuverteilung der Master kann aus zwei Gr\u00fcnden problematisch sein:<\/p>\n<ul>\n<li>Es gibt keine guten Werkzeuge zur Durchf\u00fchrung der Neuverteilung.<\/li>\n<li>Synchronisierung der Warteschlangen<\/li>\n<\/ul>\n<p>\nF\u00fcr die Neuverteilung gibt es ein Drittanbieter- <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">Plugin<\/a><\/noindex>, das nicht offiziell unterst\u00fctzt wird. Zum Thema Drittanbieter-Plugins steht im RabbitMQ-Handbuch <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">geschrieben<\/a><\/noindex>: \u201eDas Plugin bietet einige zus\u00e4tzliche Anpassungs- und Berichtswerkzeuge, wird jedoch nicht unterst\u00fctzt und nicht von der RabbitMQ-Community \u00fcberpr\u00fcft. Nutzen Sie es auf eigenes Risiko.\u201c<\/p>\n<p>Es gibt noch einen weiteren Trick, um die Hauptwarteschlange \u00fcber HA-Richtlinien zu verschieben. Im Handbuch wird darauf hingewiesen <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">Skript<\/a><\/noindex> daf\u00fcr. Es funktioniert wie folgt:<\/p>\n<ul>\n<li>Entfernt alle Spiegel mithilfe einer tempor\u00e4ren Richtlinie mit h\u00f6herer Priorit\u00e4t als die vorhandene HA-Richtlinie.\n<\/li>\n<li>\u00c4ndert die tempor\u00e4re HA-Richtlinie, um den Modus \u201eKnoten\u201c mit dem Knoten anzugeben, auf den die Hauptwarteschlange verschoben werden soll.\n<\/li>\n<li>Synchronisiert die Warteschlange zur erzwungenen Migration.\n<\/li>\n<li>Nach Abschluss der Migration wird die tempor\u00e4re Richtlinie gel\u00f6scht. Die urspr\u00fcngliche HA-Richtlinie tritt in Kraft, und die erforderliche Anzahl von Spiegeln wird erstellt.<\/li>\n<\/ul>\n<p>\nDer Nachteil ist, dass dieser Ansatz m\u00f6glicherweise nicht funktioniert, wenn Sie gro\u00dfe Warteschlangen oder strenge Redundanzanforderungen haben.<\/p>\n<p>Nun sehen wir, wie RabbitMQ-Cluster mit Netzwerkpartitionen umgehen.<\/p>\n<h1>Verletzung der Konsistenz<\/h1>\n<p>\nDie Knoten eines verteilten Systems sind durch Netzwerkverbindungen verbunden, und diese Verbindungen k\u00f6nnen unterbrochen werden. Die H\u00e4ufigkeit der Unterbrechungen h\u00e4ngt von der lokalen Infrastruktur oder der Zuverl\u00e4ssigkeit der gew\u00e4hlten Cloud ab. In jedem Fall sollten verteilte Systeme in der Lage sein, damit umzugehen. Wiedermal stehen wir vor der Wahl zwischen Verf\u00fcgbarkeit und Konsistenz, und erneut ist die gute Nachricht, dass RabbitMQ beide Optionen bereitstellt (aber nicht gleichzeitig).<\/p>\n<p>Mit RabbitMQ haben wir zwei Hauptoptionen:<\/p>\n<ul>\n<li>Erm\u00f6glichen Sie eine logische Trennung (Split-Brain). Dies gew\u00e4hrleistet Verf\u00fcgbarkeit, kann jedoch zu Datenverlust f\u00fchren.\n<\/li>\n<li>Verhindern Sie eine logische Trennung. Dies kann je nach Art der Verbindung der Clients mit dem Cluster zu kurzfristigem Verlust der Verf\u00fcgbarkeit f\u00fchren. Au\u00dferdem kann es in einem Cluster mit zwei Knoten zu vollst\u00e4ndiger Unverf\u00fcgbarkeit f\u00fchren.<\/li>\n<\/ul>\n<p>\nAber was ist eine logische Trennung? Dies geschieht, wenn der Cluster aufgrund eines Verlusts der Netzwerkverbindungen in zwei Teile geteilt wird. Auf jeder Seite wird das Spiegelbild zu einem Master, sodass letztendlich auf jede Warteschlange mehrere Master kommen.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/d880a935df450fb994edfed0715e026e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 17. Die Hauptwarteschlange und zwei Spiegel, jeweils auf einem separaten Knoten. Dann tritt ein Netzwerkfehler auf, und ein Spiegel wird getrennt. Der getrennte Knoten erkennt, dass die beiden anderen ausgefallen sind, und bef\u00f6rdert seine Spiegel zum Master. Jetzt haben wir zwei Hauptwarteschlangen, die beide Schreib- und Lesezugriff erm\u00f6glichen.<\/i> <\/p>\n<p>Wenn Publisher Daten an beide Master senden, erhalten wir zwei divergierende Kopien der Warteschlange.<\/p>\n<p>Die verschiedenen Modi von RabbitMQ bieten entweder Verf\u00fcgbarkeit oder Konsistenz.<\/p>\n<h3>Ignorieren-Modus (Standard)<\/h3>\n<p>\nDieser Modus gew\u00e4hrleistet Verf\u00fcgbarkeit. Nach dem Verlust der Konnektivit\u00e4t tritt eine logische Trennung ein. Nach der Wiederherstellung der Konnektivit\u00e4t muss der Administrator entscheiden, welchem Abschnitt der Vorzug gegeben wird. Die unterlegene Seite wird neu gestartet, und alle gespeicherten Daten auf dieser Seite gehen verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/4d82c13b5ef21837ba819f5c246a1e41.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 18. Drei Publisher sind mit drei Brokern verbunden. Intern leitet das Cluster alle Anfragen an die Hauptwarteschlange auf Broker 2.<\/i><\/p>\n<p>Jetzt verlieren wir Broker 3. Er erkennt, dass die anderen Broker ausgefallen sind, und bef\u00f6rdert seinen Spiegel zum Master. So tritt eine logische Trennung ein.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/c7e01d51b24023bacdd93cfad95c9eab.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 19. Logische Trennung (Split-Brain). Die Eintr\u00e4ge gehen in zwei Hauptwarteschlangen, und zwei Kopien gehen auseinander.<\/i><\/p>\n<p>Die Verbindung wird wiederhergestellt, aber die logische Trennung bleibt bestehen. Der Administrator muss manuell die unterlegene Seite ausw\u00e4hlen. Im folgenden Fall startet der Administrator Broker 3 neu. Alle Nachrichten, die nicht \u00fcbermittelt werden konnten, gehen verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/51c3ee15024d3c83ba625e3ff9cdeb90.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 20. Der Administrator trennt Broker 3.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/0bac8e33de25c0c5381d336d26464858.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 21. Der Administrator startet Broker 3, und er verbindet sich mit dem Cluster und verliert dabei alle Nachrichten, die dort verblieben sind.<\/i><\/p>\n<p>W\u00e4hrend der Verlust der Verbindung und nach ihrer Wiederherstellung waren der Cluster und diese Warteschlange zum Lesen und Schreiben verf\u00fcgbar.<\/p>\n<h3>Autoheal-Modus<\/h3>\n<p>\nFunktioniert \u00e4hnlich wie der Ignorieren-Modus, mit dem Unterschied, dass der Cluster automatisch die unterlegene Seite nach der Trennung und Wiederherstellung der Verbindung ausw\u00e4hlt. Die unterlegene Seite kehrt leer in den Cluster zur\u00fcck, und die Warteschlange verliert alle Nachrichten, die nur an diese Seite gesendet wurden.<\/p>\n<h3>Pause-Minority-Modus<\/h3>\n<p>\nWenn wir eine logische Trennung vermeiden m\u00f6chten, bleibt uns nur die M\u00f6glichkeit, das Lesen und Schreiben auf der kleineren Seite nach der Partition des Clusters abzulehnen. Wenn der Broker erkennt, dass er sich auf der kleineren Seite befindet, stoppt er seine Arbeit, schlie\u00dft also alle bestehenden Verbindungen und lehnt alle neuen ab. Einmal pro Sekunde \u00fcberpr\u00fcft er die Wiederherstellung der Konnektivit\u00e4t. Sobald die Konnektivit\u00e4t wiederhergestellt ist, setzt er seine Arbeit fort und verbindet sich wieder mit dem Cluster.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/7a51cf509b2c94e2ae100c7dedd9d21a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 22. Drei Publisher sind mit drei Brokern verbunden. Intern leitet der Cluster alle Anfragen an die Hauptwarteschlange bei Broker 2.<\/i><\/p>\n<p>Dann trennen sich Broker 1 und 2 von Broker 3. Anstatt sein Spiegelbild zum Master zu erh\u00f6hen, stoppt Broker 3 die Arbeit und wird nicht mehr verf\u00fcgbar.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/c12ec38a47e1f8ccceebfa1854f54f21.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 23. Broker 3 stoppt die Arbeit, trennt alle Kunden und lehnt Verbindungsgesuche ab.<\/i><\/p>\n<p>Sobald die Konnektivit\u00e4t wiederhergestellt ist, kehrt er in den Cluster zur\u00fcck.<\/p>\n<p>Sehen wir uns ein anderes Beispiel an, bei dem die Hauptwarteschlange bei Broker 3 ist.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/4cc6a28270f00a280ecb5af5252f4e07.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 24. Die Hauptwarteschlange befindet sich bei Broker 3.<\/i><\/p>\n<p>Dann tritt derselbe Verlust der Konnektivit\u00e4t ein. Broker 3 wird in den Standby-Modus versetzt, da er sich auf der kleineren Seite befindet. Auf der anderen Seite sehen die Knoten, dass Broker 3 ausgefallen ist, und somit wird das \u00e4ltere Spiegelbild von Broker 1 und 2 zum Master hochgestuft.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/d0d032385533bb53c5a95927afcd3119.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 25. Wechsel zu Broker 2 bei Nichterreichbarkeit von Broker 3.<\/i><\/p>\n<p>Sobald die Konnektivit\u00e4t wiederhergestellt ist, schlie\u00dft sich Broker 3 dem Cluster an.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ vs. Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern\" src=\"\/wp-content\/uploads\/2019\/11\/53f8186a040ae07724ef59cf79b72a0c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 26. Das Cluster arbeitet wieder normal.<\/i><\/p>\n<p>Hier ist es wichtig zu verstehen, dass wir Konsistenz erreichen, aber auch Verf\u00fcgbarkeit erhalten k\u00f6nnen, <i><b>wenn<\/b><\/i> wir die Clients erfolgreich auf den gr\u00f6\u00dferen Teil des Abschnitts umschalten. F\u00fcr die meisten Situationen w\u00fcrde ich pers\u00f6nlich den Modus Pause Minority bevorzugen, aber das h\u00e4ngt wirklich vom konkreten Fall ab.<\/p>\n<p>Um die Verf\u00fcgbarkeit zu gew\u00e4hrleisten, ist es wichtig sicherzustellen, dass die Clients erfolgreich eine Verbindung zu einem Knoten herstellen. Lassen Sie uns unsere Optionen betrachten.<\/p>\n<h1>Sicherstellung der Klientenkonnektivit\u00e4t<\/h1>\n<p>\nWir bieten mehrere M\u00f6glichkeiten, wie Sie nach einem Verbindungsverlust die Clients auf den Hauptteil des Clusters oder auf funktionierende Knoten umleiten k\u00f6nnen (nach einem Ausfall eines Knotens). Zun\u00e4chst erinnern wir uns daran, dass eine bestimmte Warteschlange auf einem bestimmten Knoten platziert wird, jedoch die Routing- und Replikationsrichtlinien auf allen Knoten verteilt sind. Clients k\u00f6nnen sich mit jedem Knoten verbinden, und das interne Routing leitet sie entsprechend weiter. Wenn jedoch ein Knoten au\u00dfer Betrieb ist, weist er Verbindungen zur\u00fcck, sodass die Clients sich mit einem anderen Knoten verbinden m\u00fcssen. Wenn ein Knoten ausf\u00e4llt, kann er kaum etwas tun.<\/p>\n<p>Unsere Optionen:<\/p>\n<ul>\n<li>Der Zugriff auf das Cluster erfolgt \u00fcber einen Lastenausgleich, der die Knoten einfach zyklisch durchl\u00e4uft, w\u00e4hrend die Clients Verbindungswiederholungen bis zum erfolgreichen Abschluss durchf\u00fchren. Wenn ein Knoten nicht funktioniert oder au\u00dfer Betrieb ist, werden die Verbindungsversuche zu diesem Knoten fehlschlagen, aber die nachfolgenden Versuche werden an andere Server (im Zyklenmodus) weitergeleitet. Dies eignet sich f\u00fcr kurzfristige Verbindungsverluste oder einen Serverausfall, der schnell behoben werden kann.\n<\/li>\n<li>Zugang zum Cluster \u00fcber den Load Balancer und das Entfernen von inaktiven\/ausgefallenen Knoten aus der Liste, sobald diese erkannt werden. Wenn dies schnell geschieht und die Kunden in der Lage sind, erneut zu verbinden, gew\u00e4hrleisten wir eine durchgehende Verf\u00fcgbarkeit.\n<\/li>\n<li>Jedem Kunden eine Liste aller Knoten zur Verf\u00fcgung stellen, aus der er beim Verbindungsaufbau zuf\u00e4llig einen ausw\u00e4hlt. Wenn er beim Verbindungsversuch einen Fehler erh\u00e4lt, wechselt er zum n\u00e4chsten Knoten in der Liste, bis die Verbindung hergestellt ist.\n<\/li>\n<li>Den Verkehr von einem ausgefallenen\/inaktiven Knoten \u00fcber DNS umleiten. Dies erfolgt durch einen kurzen TTL.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Fazit<\/h1>\n<p>\nDie Clusterbildung von RabbitMQ hat ihre eigenen Vor- und Nachteile. Die gravierendsten Nachteile sind:<\/p>\n<ul>\n<li>bei der Verbindung zum Cluster verwerfen die Knoten ihre Daten;\n<\/li>\n<li>blockierende Synchronisation f\u00fchrt zur Nichterreichbarkeit der Warteschlange.<\/li>\n<\/ul>\n<p>\nAlle schwierigen Entscheidungen resultieren aus diesen beiden Eigenschaften der Architektur. Wenn RabbitMQ Daten beim Wiederverbinden des Clusters speichern k\u00f6nnte, w\u00fcrde die Synchronisation schneller erfolgen. Wenn es in der Lage w\u00e4re, nicht-blockierende Synchronisation zu unterst\u00fctzen, k\u00f6nnte es gro\u00dfe Warteschlangen besser verwalten. Die Behebung dieser beiden Probleme w\u00fcrde die Leistung von RabbitMQ als ausfallsichere und hochverf\u00fcgbare Messaging-Technologie erheblich verbessern. Ich w\u00fcrde nicht empfehlen, RabbitMQ mit Clusterbildung in den folgenden Situationen einzusetzen:<\/p>\n<ul>\n<li>Unzuverl\u00e4ssiges Netzwerk.\n<\/li>\n<li>Unzuverl\u00e4ssiger Speicher.\n<\/li>\n<li>Sehr gro\u00dfe Warteschlangen.<\/li>\n<\/ul>\n<p>\nWas die Einstellungen f\u00fcr hohe Verf\u00fcgbarkeit betrifft, so ziehen Sie Folgendes in Betracht:<\/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> (oder <code>autoheal<\/code>)\n<\/li>\n<li>ausfallsichere Nachrichten\n<\/li>\n<li>stellen Sie sicher, dass Clients sich mit einem aktiven Knoten verbinden, wenn ein Knoten ausf\u00e4llt.<\/li>\n<\/ul>\n<p>\nF\u00fcr Konsistenz (Datensicherheit) ziehen Sie die folgenden Einstellungen in Betracht:<\/p>\n<ul>\n<li>Publisher Confirms und manuelle Best\u00e4tigungen auf der Verbraucherseite\n<\/li>\n<li><code>ha-promote-on-failure=when-synced<\/code>, wenn die Publisher sp\u00e4ter erneut versuchen k\u00f6nnen und wenn Sie sehr zuverl\u00e4ssigen Speicher haben! Andernfalls setzen Sie <code>=always<\/code>.\n<\/li>\n<li><code>ha-sync-mode=automatic<\/code> (aber f\u00fcr gro\u00dfe inaktive Warteschlangen kann der manuelle Modus erforderlich sein; zudem sollten Sie \u00fcberlegen, ob eine Nichtverf\u00fcgbarkeit zu Nachrichtenverlust f\u00fchren k\u00f6nnte)\n<\/li>\n<li>Pause-Minderheitenmodus\n<\/li>\n<li>ausfallsichere Nachrichten<\/li>\n<\/ul>\n<p>\nWir haben noch nicht alle Fragen zur Fehlertoleranz und Hochverf\u00fcgbarkeit behandelt; zum Beispiel, wie man Verwaltungsverfahren sicher durchf\u00fchrt (wie gleitende Aktualisierungen). Wir m\u00fcssen auch \u00fcber F\u00f6deration und das Shovel-Plugin sprechen.<\/p>\n<p>Falls ich noch etwas \u00fcbersehen habe, lassen Sie es mich bitte wissen.<\/p>\n<p>Siehe auch meinen <noindex><a rel=\"nofollow\" href=\"https:\/\/jack-vanlightly.com\/blog\/2018\/9\/10\/how-to-lose-messages-on-a-rabbitmq-cluster\">Beitrag<\/a><\/noindex>, in dem ich einen Angriff auf ein RabbitMQ-Cluster mit Docker und Blockade durchf\u00fchre, um einige in diesem Artikel beschriebene Szenarien zum Nachrichtenverlust zu testen.<\/p>\n<p>Vorangegangene Artikel der Serie: <br \/>\nNr. 1 \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/416629\/\">habr.com\/de\/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\/de\/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\/de\/company\/itsumma\/blog\/437446<\/a><\/noindex><br \/>\n<br \/>Quelle: <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.0.1 - 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\/de\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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 gegen Kafka: Ausfallsicherheit und hohe Verf\u00fcgbarkeit in Clustern | ProHoster","description":".","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rabbitmq-protiv-kafka-otkazoustojchivost-i-vysokaya-dostupnost-v-klasterah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/52525","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=52525"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/52525\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=52525"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=52525"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=52525"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}