{"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 gegen Kafka: Fehlertoleranz und hohe Verf\u00fcgbarkeit in Clustern.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz und hohe Verf\u00fcgbarkeit in Clustern.\" src=\"\/wp-content\/uploads\/2019\/11\/d8e584d210a6a016a962ad6f956a2078.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFailover und hohe Verf\u00fcgbarkeit sind gro\u00dfe Themen, daher widmen wir RabbitMQ und Kafka separate Artikel. Dieser Artikel handelt von RabbitMQ, w\u00e4hrend der n\u00e4chste \u00fcber Kafka im Vergleich zu RabbitMQ sein wird. Der Artikel ist lang, also machen Sie es sich bequem.<\/p>\n<p>Wir betrachten Strategien zur Fehlertoleranz, Konsistenz und hohen Verf\u00fcgbarkeit (HA) sowie die Kompromisse, die man in jeder Strategie eingehen muss. RabbitMQ kann auf einem Cluster von Knoten arbeiten und wird dann als verteiltes System klassifiziert. Wenn es um verteilte Systeme geht, sprechen wir oft von Konsistenz und Verf\u00fcgbarkeit. <\/p>\n<p>Diese Begriffe beschreiben, wie sich das System im Falle eines Ausfalls verh\u00e4lt. Netzwerkunterbrechungen, Serverausf\u00e4lle, Festplattenfehler, tempor\u00e4re Nichtverf\u00fcgbarkeit des Servers aufgrund von Garbage Collection, Paketverluste oder langsame Netzwerkverbindungen. All dies kann zu Datenverlust oder Konflikten f\u00fchren. Es scheint praktisch unm\u00f6glich zu sein, ein System gleichzeitig vollst\u00e4ndig konsistent (ohne Datenverlust, ohne inkonsistente Daten) und f\u00fcr alle Ausfallvarianten verf\u00fcgbar zu machen (es wird Lese- und Schreiboperationen annehmen).<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nWir werden sehen, dass Konsistenz und Verf\u00fcgbarkeit an entgegengesetzten Enden des Spektrums stehen und Sie ausw\u00e4hlen m\u00fcssen, in welche Richtung Sie optimieren m\u00f6chten. Die gute Nachricht ist, dass dies mit RabbitMQ m\u00f6glich ist. Sie haben gewisserma\u00dfen \u201eNerd\u201c-Hebel, um das Gleichgewicht zugunsten von mehr Konsistenz oder mehr Verf\u00fcgbarkeit zu verschieben.<\/p>\n<p>Wir werden besonderes Augenmerk darauf legen, welche Konfigurationen zu Datenverlust aufgrund best\u00e4tigter Nachrichten f\u00fchren. Es gibt eine Verantwortungskette zwischen Publishern, Brokern und Verbrauchern. Sobald eine Nachricht an den Broker \u00fcbergeben wurde, liegt es an ihm, die Nachricht nicht zu verlieren. Wenn der Broker dem Publisher den Empfang der Nachricht best\u00e4tigt, erwarten wir nicht, dass sie verloren geht. Aber wir werden sehen, dass dies tats\u00e4chlich je nach Konfiguration Ihres Brokers und Publishers eintreten kann.<\/p>\n<h1>Primitiven der Fehlertoleranz eines Knotens<\/h1>\n<p><\/p>\n<h3>Fehlertolerante Warteschlangen\/Routing<\/h3>\n<p>\nIn RabbitMQ gibt es zwei Arten von Warteschlangen: langlebige (durable) und nicht-langlebige (non-durable). Alle Warteschlangen werden in der Mnesia-Datenbank gespeichert. Langlebige Warteschlangen werden beim Starten des Knotens erneut deklariert und \u00fcberstehen somit einen Neustart, einen Systemausfall oder einen Serverfehler (sofern die Daten gespeichert bleiben). Das bedeutet, dass solange Sie das Routing (exchange) und die Warteschlange als langlebig deklarieren, die Infrastruktur der Warteschlangen\/Routings in den Betriebszustand zur\u00fcckkehrt.<\/p>\n<p>Nicht-langlebige Warteschlangen und -routing werden beim Neustart des Knotens gel\u00f6scht.<\/p>\n<h3>Langlebige Nachrichten<\/h3>\n<p>\nNur weil eine Warteschlange langlebig ist, bedeutet das nicht, dass alle ihre Nachrichten den Neustart des Knotens \u00fcberstehen. Es werden nur die Nachrichten wiederhergestellt, die vom Publisher als <i>langlebig<\/i> (persistent) festgelegt wurden. Langlebige Nachrichten verursachen tats\u00e4chlich zus\u00e4tzliche Belastung f\u00fcr den Broker, aber wenn der Verlust einer Nachricht inakzeptabel ist, gibt es keinen anderen Weg.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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. Lebensdauer-Matrix<\/i><\/p>\n<h1>Clusterbildung mit Warteschlangen-Spiegelung<\/h1>\n<p>\nUm den Verlust eines Brokers zu \u00fcberstehen, ben\u00f6tigen wir Redundanz. Wir k\u00f6nnen mehrere RabbitMQ-Knoten in einem Cluster zusammenfassen und dann zus\u00e4tzliche Redundanz durch Replikation von Warteschlangen zwischen mehreren Knoten hinzuf\u00fcgen. So verlieren wir keine Daten und bleiben erreichbar, 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 existieren nicht zum Skalieren, sondern ausschlie\u00dflich zur Redundanz.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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>\nUm eine konsistente Nachrichtenaufzeichnung zu erreichen, sind Best\u00e4tigungen an den Publisher (Publisher Confirms) erforderlich. Ohne diese besteht das Risiko des Verlusts von Nachrichten. 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, in der Regel alle paar hundert Millisekunden, auf die Festplatte. Wenn die Warteschlange gespiegelt wird, erfolgt die Best\u00e4tigung erst, nachdem auch alle Spiegel ihre Kopie der Nachricht auf die Festplatte geschrieben haben. Das bedeutet, dass die Verwendung von Best\u00e4tigungen Verz\u00f6gerungen mit sich bringt, aber wenn Datensicherheit wichtig ist, sind sie notwendig.<\/p>\n<h1>Fehlertolerante Warteschlange<\/h1>\n<p>\nWenn der Broker heruntergefahren wird oder ausf\u00e4llt, fallen alle Hauptwarteschlangen (Master) auf diesem Knoten mit ihm aus. Dann w\u00e4hlt der Cluster das \u00e4lteste Spiegelbild jedes Masters aus und f\u00f6rdert es zum neuen Master.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 gespiegelte Warteschlangen und ihre Richtlinien<\/i><\/p>\n<p>Broker 3 f\u00e4llt aus. Beachten Sie, dass das Spiegelbild der Warteschlange C auf Broker 2 zum Master bef\u00f6rdert wird. Beachten Sie auch, dass ein neues Spiegelbild der Warteschlange C auf Broker 1 erstellt wurde. RabbitMQ versucht immer, den in Ihren Richtlinien angegebenen Replikationsfaktor aufrechtzuerhalten.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 zum Ausfall der Warteschlange C f\u00fchrt<\/i> <\/p>\n<p>Der n\u00e4chste Broker 1 f\u00e4llt aus! Wir haben nur noch einen Broker. Das Spiegelbild der Warteschlange B wird zum Master bef\u00f6rdert.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz und hohe Verf\u00fcgbarkeit in Clustern.\" src=\"\/wp-content\/uploads\/2019\/11\/dcc1d542c40c441194fd07e51046c619.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abbildung 5<\/i><\/p>\n<p>Wir haben Broker 1 wiederhergestellt. Unabh\u00e4ngig davon, wie erfolgreich die Daten den Verlust und die Wiederherstellung des Brokers \u00fcberstanden haben, werden alle gespiegelten Nachrichten der Warteschlange beim Neustart verworfen. Dies ist wichtig zu beachten, da es Konsequenzen hat. Diese Konsequenzen werden wir bald betrachten. Broker 1 ist nun wieder ein Mitglied des Clusters, und der Cluster versucht, die Richtlinien einzuhalten und erstellt daher Spiegelbilder auf Broker 1.<\/p>\n<p>In diesem Fall war der Verlust von Broker 1 vollst\u00e4ndig, ebenso wie die Daten, daher ist die nicht gespiegelte Warteschlange B vollst\u00e4ndig verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz und hohe Verf\u00fcgbarkeit in Clustern.\" src=\"\/wp-content\/uploads\/2019\/11\/7ac7ab65ea6dff9c5a49372c04c83a37.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 6. Broker 1 kehrt in den Dienst zur\u00fcck<\/i><\/p>\n<p>Broker 3 ist wieder betriebsbereit, sodass die Warteschlangen A und B ihre auf ihm erstellten Spiegel zur\u00fcckbekommen, um ihre HA-Politiken zu erf\u00fcllen. Doch jetzt befinden sich 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 zur Umverteilung der Master. Wir werden dieses Problem sp\u00e4ter erneut aufgreifen, da wir zuerst die Synchronisation der Warteschlange betrachten m\u00fcssen. <\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz und hohe Verf\u00fcgbarkeit in Clustern.\" src=\"\/wp-content\/uploads\/2019\/11\/a54e53bb01e2f830a54f88acaa668984.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Abb. 7. Broker 3 wird wieder betriebsbereit. Alle Hauptwarteschlangen auf einem Knoten!<\/i><\/p>\n<p>So sollten Sie jetzt eine Vorstellung davon haben, wie Spiegel Redundanz und Ausfallsicherheit bieten. Dies gew\u00e4hrleistet die Verf\u00fcgbarkeit im Falle eines Ausfalls eines Knotens und sch\u00fctzt vor Datenverlust. Aber wir sind noch nicht fertig, denn tats\u00e4chlich ist alles viel komplizierter.<\/p>\n<h1>Synchronisierung<\/h1>\n<p>\nWenn ein neuer Spiegel erstellt wird, werden alle neuen Nachrichten immer auf diesen Spiegel und auf alle anderen repliziert. Was die bestehenden Daten in der Hauptwarteschlange betrifft, k\u00f6nnen wir sie in den neuen Spiegel replizieren, der eine vollst\u00e4ndige Kopie des Masters wird. Wir k\u00f6nnen auch entscheiden, bestehende Nachrichten nicht zu replizieren und der Hauptwarteschlange und dem neuen Spiegel die Zeit zu lassen, sich beim Eingang neuer Nachrichten, w\u00e4hrend bestehende Nachrichten den Kopf der Hauptwarteschlange verlassen.<\/p>\n<p>Eine solche Synchronisation erfolgt automatisch oder manuell und wird durch Warteschlangenrichtlinien gesteuert. Sehen wir uns ein Beispiel an.<\/p>\n<p>Wir haben zwei gespiegelte Warteschlangen. Warteschlange A synchronisiert sich automatisch, w\u00e4hrend Warteschlange B manuell synchronisiert wird. In beiden Warteschlangen befinden sich zehn Nachrichten.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 Synchronisationsmodi<\/i><\/p>\n<p>Nun verlieren wir Broker 3.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 betriebsbereit. Der Cluster erstellt einen Spiegel f\u00fcr jede Warteschlange auf dem neuen Knoten und synchronisiert die neue Warteschlange A automatisch mit dem Master. Der Spiegel der neuen Warteschlange B bleibt jedoch leer. Somit haben wir vollst\u00e4ndige Redundanz f\u00fcr Warteschlange A und nur einen Spiegel f\u00fcr die bestehenden Nachrichten von Warteschlange B.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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. Der neue Spiegel der Warteschlange A erh\u00e4lt alle bestehenden Nachrichten, w\u00e4hrend der neue Spiegel der Warteschlange B dies nicht tut.<\/i><\/p>\n<p>In beiden Warteschlangen werden erneut jeweils zehn Nachrichten empfangen. Dann f\u00e4llt Broker 2 aus, und die Warteschlange A rollt auf das \u00e4lteste Spiegelbild zur\u00fcck, das sich auf Broker 1 befindet. Bei einem Ausfall gibt es keinen Datenverlust. In Warteschlange B befinden sich zwanzig Nachrichten im Master und nur zehn im Spiegel, da diese Warteschlange die urspr\u00fcnglichen zehn Nachrichten nie repliziert hat.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 rollt auf Broker 1 zur\u00fcck, ohne Nachrichten zu verlieren<\/i><\/p>\n<p>In beiden Warteschlangen werden erneut jeweils zehn Nachrichten empfangen. Jetzt f\u00e4llt Broker 1 aus. Warteschlange A wechselt problemlos auf das Spiegelbild, ohne Nachrichten zu verlieren. Allerdings hat Warteschlange B Probleme. An dieser Stelle k\u00f6nnen wir entweder Verf\u00fcgbarkeit oder Konsistenz optimieren. <\/p>\n<p>Wenn wir die Verf\u00fcgbarkeit optimieren wollen, sollte die Richtlinie <b><i>ha-promote-on-failure<\/i><\/b> auf <b><i>always<\/i><\/b>. Dieser Wert ist der Standardwert, daher kann die Richtlinie einfach weggelassen werden. In diesem Fall akzeptieren wir im Wesentlichen Ausf\u00e4lle in unsynchronisierten Spiegeln. Dies wird zu einem Nachrichtenverlust f\u00fchren, aber die Warteschlange bleibt f\u00fcr Lese- und Schreiboperationen verf\u00fcgbar.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 rollt auf Broker 3 zur\u00fcck, ohne Nachrichten zu verlieren. Warteschlange B rollt auf Broker 3 zur\u00fcck und verliert dabei zehn Nachrichten<\/i><\/p>\n<p>Wir k\u00f6nnen auch <code>ha-promote-on-failure<\/code> auf den Wert <code>when-synced<\/code>. In diesem Fall wird die Warteschlange auf das Spiegelbild warten, anstatt zur\u00fcckzurollen, bis Broker 1 mit seinen Daten wieder betriebsbereit ist. Nach seiner R\u00fcckkehr befindet sich die Hauptwarteschlange erneut auf Broker 1, ohne Datenverlust. Die Verf\u00fcgbarkeit wird auf Kosten der Datensicherheit geopfert. Aber dies ist ein riskanter Modus, der sogar zu einem vollst\u00e4ndigen Datenverlust f\u00fchren kann, was wir gleich er\u00f6rtern werden.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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. Warteschlange B bleibt nach dem Ausfall von Broker 1 nicht verf\u00fcgbar<\/i><\/p>\n<p>Sie k\u00f6nnten sich fragen: \u201eVielleicht ist es besser, die automatische Synchronisierung niemals zu verwenden?\u201c Die Antwort ist, dass Synchronisierung eine blockierende Operation ist. W\u00e4hrend der Synchronisierung kann die Hauptwarteschlange keine Lese- oder Schreiboperationen ausf\u00fchren!<\/p>\n<p>Betrachten wir ein Beispiel. Jetzt haben wir sehr gro\u00dfe Warteschlangen. Wie k\u00f6nnen sie so gro\u00df werden? Aus mehreren Gr\u00fcnden:<\/p>\n<ul>\n<li>Warteschlangen werden nicht aktiv verwendet\n<\/li>\n<li>Dies sind Hochgeschwindigkeitswarteschlangen, und im Moment arbeiten die Verbraucher langsam \n<\/li>\n<li>Dies sind Hochgeschwindigkeitswarteschlangen, ein Ausfall ist aufgetreten, und die Verbraucher holen auf<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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>Jetzt f\u00e4llt Broker 3 aus.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 Spiegelbild in jeder Warteschlange<\/i><\/p>\n<p>Broker 3 wird wieder in Betrieb genommen und es werden neue Spiegel erstellt. Die Hauptwarteschlange A beginnt mit der Replikation vorhandener Nachrichten auf das neue Spiegelbild, wobei die Warteschlange w\u00e4hrend dieser Zeit nicht verf\u00fcgbar ist. Die Datenreplikation dauert zwei Stunden, was zu zwei Stunden Ausfallzeit f\u00fcr diese Warteschlange f\u00fchrt!<\/p>\n<p>Die Warteschlange B bleibt jedoch w\u00e4hrend des gesamten Zeitraums verf\u00fcgbar. Sie hat etwas Redundanz f\u00fcr die Verf\u00fcgbarkeit geopfert.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 Warteschlange ist w\u00e4hrend der Synchronisierung nicht verf\u00fcgbar<\/i><\/p>\n<p>Nach zwei Stunden wird auch Warteschlange A verf\u00fcgbar und kann wieder Lese- und Schreiboperationen annehmen.<\/p>\n<h3>Updates<\/h3>\n<p>\nDieses blockierende 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 dem Spiegelbild oder die Deaktivierung der Warteschlange w\u00e4hrend des Serverupdates bedeutet. Wenn wir den Wechsel w\u00e4hlen, verlieren wir Nachrichten, wenn die Spiegel nicht synchronisiert sind. Standardm\u00e4\u00dfig wird beim Ausschalten des Brokers kein Wechsel zu nicht synchronisierten Spiegeln vorgenommen. Das bedeutet, dass wir, sobald der Broker zur\u00fcckkommt, keine Nachrichten verlieren; der einzige Schaden ist die Ausfallzeit der Warteschlange. Die Regeln f\u00fcr das Verhalten beim Ausschalten des Brokers werden durch die Politik festgelegt. <code>ha-promote-on-shutdown<\/code>. Es kann einer von zwei Werten eingestellt werden:<\/p>\n<ul>\n<li><code>always<\/code>= der Wechsel zu nicht synchronisierten Spiegeln ist aktiviert\n<\/li>\n<li><code>when-synced<\/code>= Wechsel nur zu synchronisierten Spiegeln, andernfalls wird die Warteschlange nicht f\u00fcr Lese- und Schreiboperationen verf\u00fcgbar. Die Warteschlange wird wieder in Betrieb genommen, 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 Verf\u00fcgbarkeit die Datensicherheit erh\u00f6ht<\/h3>\n<p>\nBevor eine Entscheidung getroffen wird, muss ein weiteres Komplikation ber\u00fccksichtigt werden. Auch wenn die automatische Synchronisierung besser f\u00fcr die Redundanz ist, wie wirkt sich das auf die Datensicherheit aus? Nat\u00fcrlich ist RabbitMQ mit besserer Redundanz weniger wahrscheinlich, dass vorhandene Nachrichten verloren gehen, aber wie steht es um neue Nachrichten von Publishern?<\/p>\n<p>Hier sind folgende Punkte zu beachten:<\/p>\n<ul>\n<li>Kann der Publisher einfach einen Fehler zur\u00fcckgeben, und der \u00fcbergeordnete Dienst oder der Benutzer versucht es sp\u00e4ter erneut?\n<\/li>\n<li>Kann der Publisher die Nachricht lokal oder in einer Datenbank speichern, um einen sp\u00e4teren Versuch zu erm\u00f6glichen?<\/li>\n<\/ul>\n<p>\nWenn der Publisher nur die Nachricht verwerfen kann, verbessert die Verf\u00fcgbarkeit tats\u00e4chlich auch die Datensicherheit.<\/p>\n<p>Daher muss ein Gleichgewicht gesucht werden, und die Entscheidung h\u00e4ngt von der konkreten Situation ab.<\/p>\n<h1>Probleme mit ha-promote-on-failure=when-synced<\/h1>\n<p>\nIdee <i><b>ha-promote-on-failure<\/b><\/i>= <i><b>when-synced<\/b><\/i> besteht darin, dass wir den Wechsel zu einem unsynchronisierten Spiegel verhindern und damit Datenverluste vermeiden. Die Warteschlange bleibt f\u00fcr Lese- oder Schreibvorg\u00e4nge nicht verf\u00fcgbar. Stattdessen versuchen wir, den ausgefallenen Broker mit intakten Daten zur\u00fcckzubringen, damit er als Master ohne Datenverlust weiterarbeitet. <\/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! Auch wenn Sie Spiegel haben, die gr\u00f6\u00dftenteils die Hauptwarteschlange einholen, werden diese Spiegel ebenfalls verworfen.<\/p>\n<p>Um einen Knoten mit dem gleichen Namen neu 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 den verlorenen Knoten im Ged\u00e4chtnis beh\u00e4lt, merkt es sich die alte Warteschlange und die unsynchronisierten Spiegel. Wenn dem Cluster gesagt wird, dass es den verlorenen Knoten vergessen soll, wird diese Warteschlange ebenfalls vergessen. Jetzt muss sie neu deklariert werden. Wir haben alle Daten verloren, obwohl wir Spiegel mit einem teilweisen Datensatz hatten. Es w\u00e4re besser gewesen, auf einen unsynchronisierten Spiegel umzuschalten!<\/p>\n<p>Daher ist eine manuelle Synchronisation (und das Ausbleiben einer Synchronisation) zusammen mit <code>ha-promote-on-failure=when-synced<\/code>, meiner Meinung nach ziemlich riskant. Dokumente besagen, dass diese Option f\u00fcr die Datensicherheit existiert, aber sie ist ein zweischneidiges Schwert.<\/p>\n<h1>Neuausbalancierung 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 \u201erollierendes\u201c Update des Clusters verursacht werden. In einem Cluster mit drei Knoten sammeln sich alle Hauptwarteschlangen auf einem oder zwei Knoten.<\/p>\n<p>Die Neuausbalancierung der Master kann aus zwei Gr\u00fcnden problematisch sein:<\/p>\n<ul>\n<li>Es gibt keine guten Werkzeuge zur Durchf\u00fchrung einer Neuausbalancierung<\/li>\n<li>Synchronisation der Warteschlangen<\/li>\n<\/ul>\n<p>\nUm das Gleichgewicht wiederherzustellen, gibt es ein Drittanbieter- <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Ayanda-D\/rabbitmq-queue-master-balancer\">Plugin<\/a><\/noindex>, das offiziell nicht unterst\u00fctzt wird. In der Dokumentation von RabbitMQ wird \u00fcber Drittanbieter-Plugins gesagt, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.rabbitmq.com\/upgrade.html\">gesagt<\/a><\/noindex>: \u201eDas Plugin bietet einige zus\u00e4tzliche Konfigurations- und Reporting-Tools, wird jedoch nicht von dem RabbitMQ-Team unterst\u00fctzt oder getestet. Verwenden Sie es auf eigenes Risiko.\u201c<\/p>\n<p>Es gibt noch einen weiteren Trick, um die Hauptwarteschlange \u00fcber HA-Richtlinien zu verschieben. In der Dokumentation wird <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/rabbitmq\/support-tools\/blob\/master\/scripts\/rebalance-queue-masters\">Skript<\/a><\/noindex> dar\u00fcber erw\u00e4hnt. Es funktioniert wie folgt:<\/p>\n<ul>\n<li>Es entfernt alle Spiegel mithilfe einer tempor\u00e4ren Richtlinie mit h\u00f6herer Priorit\u00e4t als die vorhandene HA-Richtlinie.\n<\/li>\n<li>Es \u00e4ndert die tempor\u00e4re HA-Richtlinie, um den \u201aKnoten\u2018-Modus zu verwenden, wobei der Knoten angegeben wird, auf den die Hauptwarteschlange verschoben werden soll.\n<\/li>\n<li>Es synchronisiert die Warteschlange f\u00fcr die erzwungene Migration.\n<\/li>\n<li>Nach Abschluss der Migration wird die tempor\u00e4re Richtlinie entfernt. Die urspr\u00fcngliche HA-Richtlinie tritt in Kraft, und es werden die erforderliche Anzahl an Spiegeln erstellt.<\/li>\n<\/ul>\n<p>\nDer Nachteil besteht darin, dass dieser Ansatz m\u00f6glicherweise nicht funktioniert, wenn Sie gro\u00dfe Warteschlangen oder strenge Anforderungen an die Redundanz haben.<\/p>\n<p>Jetzt schauen wir uns an, wie RabbitMQ-Cluster mit Netzwerkpartitionen umgehen.<\/p>\n<h1>Netzwerkunterbrechungen<\/h1>\n<p>\nDie Knoten eines verteilten Systems sind durch Netzwerkverbindungen miteinander verbunden, und diese Verbindungen k\u00f6nnen und werden ausfallen. Die H\u00e4ufigkeit von Ausf\u00e4llen h\u00e4ngt von der lokalen Infrastruktur oder der Zuverl\u00e4ssigkeit der gew\u00e4hlten Cloud ab. Auf jeden Fall sollten verteilte Systeme in der Lage sein, damit umzugehen. Wieder stehen wir vor der Wahl zwischen Verf\u00fcgbarkeit und Konsistenz, und erneut ist die gute Nachricht, dass RabbitMQ beide Optionen bietet (nur nicht gleichzeitig).<\/p>\n<p>Mit RabbitMQ haben wir zwei Hauptoptionen:<\/p>\n<ul>\n<li>Logische Partitionierung (split-brain) erlauben. Dies gew\u00e4hrleistet Verf\u00fcgbarkeit, kann jedoch zu Datenverlust f\u00fchren.\n<\/li>\n<li>Logische Partitionierung verbieten. Dies kann kurzfristig zu einem Verlust der Verf\u00fcgbarkeit f\u00fchren, abh\u00e4ngig davon, wie die Clients mit dem Cluster verbunden sind. Es kann auch zur vollst\u00e4ndigen Unzug\u00e4nglichkeit des Clusters bei zwei Knoten f\u00fchren.<\/li>\n<\/ul>\n<p>\nAber was ist logische Partitionierung? Das ist, wenn der Cluster aufgrund von Netzwerkverbindungsverlust in zwei Teile geteilt wird. Auf jeder Seite werden die Spiegel zu Meistern bef\u00f6rdert, sodass am Ende mehrere Meister auf jede Warteschlange kommen.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 an einem separaten Knoten. Dann tritt ein Netzwerkfehler auf, und ein Spiegel trennt sich. Der getrennte Knoten sieht, dass zwei andere abgebrochen sind, und bef\u00f6rdert seine Spiegel zum Master. Jetzt haben wir zwei Hauptwarteschlangen, und beide erlauben Schreib- und Lesezugriffe.<\/i> <\/p>\n<p>Wenn Publisher Daten an beide Master senden, haben wir zwei divergente Kopien der Warteschlange.<\/p>\n<p>Die verschiedenen Modi von RabbitMQ gew\u00e4hrleisten entweder Verf\u00fcgbarkeit oder Konsistenz.<\/p>\n<h3>Modus Ignore (Standardmodus)<\/h3>\n<p>\nDieser Modus gew\u00e4hrleistet die Verf\u00fcgbarkeit. Nach dem Verlust der Konnektivit\u00e4t tritt eine logische Trennung auf. Nach der Wiederherstellung der Konnektivit\u00e4t muss der Administrator entscheiden, welchem Partition der Vorzug gegeben wird. Die unterlegene Seite wird neu gestartet, und alle gesammelten Daten dieser Seite gehen verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 der Cluster alle Anfragen an die Hauptwarteschlange auf Broker 2.<\/i><\/p>\n<p>Jetzt verlieren wir Broker 3. Er sieht, dass die anderen Broker abgebrochen sind, und bef\u00f6rdert seinen Spiegel zum Master. So tritt eine logische Trennung ein.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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). Schreibvorg\u00e4nge erfolgen in zwei Hauptwarteschlangen, und zwei Kopien divergieren.<\/i><\/p>\n<p>Die Konnektivit\u00e4t 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 dieser noch nicht \u00fcbermitteln konnte, gehen verloren.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 schaltet Broker 3 aus.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 tritt dem Cluster bei, wobei er alle Nachrichten verliert, die dort geblieben sind.<\/i><\/p>\n<p>W\u00e4hrend des Verlusts der Konnektivit\u00e4t und nach deren Wiederherstellung waren der Cluster und diese Warteschlange f\u00fcr Lese- und Schreibzugriffe verf\u00fcgbar.<\/p>\n<h3>Modus Autoheal<\/h3>\n<p>\nFunktioniert \u00e4hnlich wie der Modus Ignore, mit dem Unterschied, dass der Cluster automatisch nach der Trennung und Wiederherstellung der Konnektivit\u00e4t die unterlegene Seite 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>Modus Pause Minority<\/h3>\n<p>\nWenn wir eine logische Trennung vermeiden wollen, ist unsere einzige Option, das Lesen und Schreiben auf der kleineren Seite nach der Clustertrennung zu verweigern. Wenn der Broker sieht, dass er sich auf der kleineren Seite befindet, stoppt er den Betrieb, schlie\u00dft 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 schlie\u00dft sich dem Cluster wieder an.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 das Cluster alle Anfragen an die Hauptwarteschlange auf Broker 2 weiter.<\/i><\/p>\n<p>Dann trennen sich die Broker 1 und 2 von Broker 3. Anstatt sein Spiegelbild zum Master zu erheben, stoppt Broker 3 die Arbeit und wird nicht mehr verf\u00fcgbar.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 Clients und lehnt Verbindungsgesuche ab.<\/i><\/p>\n<p>Sobald die Konnektivit\u00e4t wiederhergestellt ist, kehrt er ins Cluster zur\u00fcck.<\/p>\n<p>Schauen wir uns ein anderes Beispiel an, bei dem die Hauptwarteschlange auf Broker 3 liegt.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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. Hauptwarteschlange auf Broker 3.<\/i><\/p>\n<p>Dann tritt dasselbe Konnektivit\u00e4tsproblem auf. Broker 3 pausiert, da er sich auf der kleineren Seite befindet. Auf der anderen Seite sehen die Knoten, dass Broker 3 ausgefallen ist, sodass das \u00e4ltere Spiegelbild von Broker 1 und 2 zum Master erhoben wird.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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. \u00dcbergang zu Broker 2 bei Nichterreichbarkeit von Broker 3.<\/i><\/p>\n<p>Wenn die Konnektivit\u00e4t wiederhergestellt ist, wird Broker 3 dem Cluster beitreten.<\/p>\n<p><img decoding=\"async\" alt=\"RabbitMQ gegen Kafka: Fehlertoleranz 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 ist wieder im Normalbetrieb.<\/i><\/p>\n<p>Hier ist es wichtig zu verstehen, dass wir Konsistenz erzielen, aber gleichzeitig auch Verf\u00fcgbarkeit erreichen k\u00f6nnen, <i><b>wenn<\/b><\/i> wir die Clients erfolgreich auf den gr\u00f6\u00dferen Teil der Partition umstellen. F\u00fcr die meisten Situationen w\u00fcrde ich pers\u00f6nlich den Modus \"Pause Minority\" w\u00e4hlen, aber das h\u00e4ngt wirklich vom spezifischen Fall ab.<\/p>\n<p>F\u00fcr die Gew\u00e4hrleistung der Verf\u00fcgbarkeit ist es wichtig sicherzustellen, dass die Clients erfolgreich mit dem Knoten verbunden werden. Schauen wir uns unsere Optionen an.<\/p>\n<h1>Gew\u00e4hrleistung der Konnektivit\u00e4t der Clients<\/h1>\n<p>\nWir haben mehrere Optionen, um nach einem Verlust der Verbindung Kunden zum Hauptteil des Clusters oder zu den funktionierenden Knoten (nach einem Fehler eines Knotens) zu leiten. Lassen Sie uns zun\u00e4chst daran erinnern, dass eine bestimmte Warteschlange auf einem bestimmten Knoten platziert ist, aber die Routen und Richtlinien auf allen Knoten repliziert werden. Kunden k\u00f6nnen sich mit jedem Knoten verbinden, und das interne Routing leitet sie dorthin, wo sie hin m\u00fcssen. Wenn jedoch ein Knoten ausgesetzt ist, wird er Verbindungen ablehnen, sodass sich die Kunden mit einem anderen Knoten verbinden m\u00fcssen. Wenn ein Knoten ausgefallen ist, kann er \u00fcberhaupt nichts tun.<\/p>\n<p>Unsere Optionen:<\/p>\n<ul>\n<li>Der Zugang zum Cluster erfolgt \u00fcber einen Lastenausgleich, der einfach zyklisch die Knoten durchl\u00e4uft, w\u00e4hrend die Kunden Wiederholungsversuche zur Verbindung durchf\u00fchren, bis sie erfolgreich sind. Wenn ein Knoten nicht funktioniert oder ausgesetzt ist, schlagen die Versuche, sich mit diesem Knoten zu verbinden, fehl, aber die folgenden Versuche werden an andere Server weitergeleitet (im zyklischen Modus). Dies eignet sich f\u00fcr kurzfristige Verbindungsverluste oder einen ausgefallenen Server, der schnell wiederhergestellt wird.\n<\/li>\n<li>Zugang zum Cluster \u00fcber einen Lastenausgleich und sofortige Entfernung von ausgesetzten\/fehlgeschlagenen Knoten aus der Liste, sobald sie erkannt werden. Wenn dies schnell geschieht und die Kunden in der Lage sind, Wiederholungsversuche durchzuf\u00fchren, erhalten wir eine st\u00e4ndige Verf\u00fcgbarkeit.\n<\/li>\n<li>Jeden Kunden eine Liste aller Knoten geben, und der Kunde w\u00e4hlt beim Verbinden zuf\u00e4llig einen davon aus. Wenn er bei dem Verbindungsversuch einen Fehler erh\u00e4lt, wechselt er zum n\u00e4chsten Knoten in der Liste, bis er verbunden ist.\n<\/li>\n<li>Leiten Sie den Datenverkehr von einem ausgefallenen\/ausgesetzten Knoten \u00fcber DNS um. Dies geschieht mit einer kurzen TTL.<\/li>\n<\/ul>\n<p><\/p>\n<h1>Das DBMS Tarantool ist ein attraktives, zukunftstr\u00e4chtiges Produkt zur Erstellung von hochbelasteten Anwendungen.<\/h1>\n<p>\nDie Clusterbildung von RabbitMQ hat ihre eigenen Vor- und Nachteile. Die schwerwiegendsten Nachteile sind:<\/p>\n<ul>\n<li>bei der Verbindung zum Cluster verwerfen die Knoten ihre Daten;\n<\/li>\n<li>die blockierende Synchronisierung f\u00fchrt zur Unzug\u00e4nglichkeit der Warteschlange.<\/li>\n<\/ul>\n<p>\nAlle schwierigen Entscheidungen ergeben sich aus diesen beiden Merkmalen der Architektur. Wenn RabbitMQ Daten beim Wiederverbinden des Clusters speichern k\u00f6nnte, w\u00fcrde die Synchronisierung schneller erfolgen. Wenn es in der Lage w\u00e4re, nicht-blockierende Synchronisierung zu unterst\u00fctzen, k\u00f6nnte es gro\u00dfe Warteschlangen besser verwalten. Die Behebung dieser beiden Probleme w\u00fcrde die Eigenschaften 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\u00e4ssige Speicherung.\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>Persistente Nachrichten\n<\/li>\n<li>Stellen Sie sicher, dass die Clients mit dem aktiven Knoten verbunden sind, wenn ein Knoten ausf\u00e4llt<\/li>\n<\/ul>\n<p>\nF\u00fcr Konsistenz (Datensicherheit) ziehen Sie folgende 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 eine sehr zuverl\u00e4ssige Speicherung 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 ein manueller Modus erforderlich sein; au\u00dferdem \u00fcberlegen Sie, ob die Nichtverf\u00fcgbarkeit zum Verlust von Nachrichten f\u00fchren k\u00f6nnte)\n<\/li>\n<li>Pause-Minority-Modus\n<\/li>\n<li>Persistente Nachrichten<\/li>\n<\/ul>\n<p>\nWir haben noch nicht alle Fragen zur Ausfallsicherheit und hochverf\u00fcgbaren Verf\u00fcgbarkeit behandelt; zum Beispiel, wie man administrative Verfahren sicher durchf\u00fchrt (wie rollierende Updates). Auch \u00fcber die F\u00f6deration und das Shovel-Plugin muss gesprochen werden.<\/p>\n<p>Wenn 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\">Post<\/a><\/noindex>, in dem ich ein Chaos im RabbitMQ-Cluster mit Docker und Blockade verursache, um einige der in diesem Artikel beschriebenen Verlustszenarien zu \u00fcberpr\u00fcfen.<\/p>\n<p>Fr\u00fchere Artikel der 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 \/>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.2 - 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.2\" \/>\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}]}}