Ursprüngliche URL: RabbitMQ Hochverfügbarkeit – Prinzip der Spiegelwarteschlange – Programmierer gesucht
Einführung
veranschaulichen
Dieser Artikel stellt das Prinzip der Spiegelwarteschlange von RabbitMQ vor. Die Spiegelwarteschlange kann die Hochverfügbarkeit von RabbitMQ sicherstellen und Nachrichtenverlust verhindern.
Was ist eine Spiegelwarteschlange?
Spiegelwarteschlange: Die Warteschlange wird auf andere Broker-Knoten im Cluster kopiert, und alle in der Spiegelwarteschlange veröffentlichten Nachrichten werden auch an den Master und alle Slaves veröffentlicht. Wenn ein Knoten im Cluster ausfällt, kann die Warteschlange automatisch zu einem anderen Knoten im Spiegel wechseln, um die Dienstverfügbarkeit sicherzustellen.
Verdoppelung der Warteschlange
Eine gespiegelte Warteschlange repliziert die Warteschlange auf andere Broker-Knoten im Cluster.
Kopie der Nachricht
Alle vom Producer an die Mirror-Queue veröffentlichten Nachrichten werden auch an den Master und alle Slaves veröffentlicht.
Prozess, nachdem ein Knoten ausgefallen ist
Slave-Knoten ausgefallen
Wenn der Slave ausgefallen ist, hat dies keine weiteren Auswirkungen, außer dass alle mit dem Slave verbundenen Client-Verbindungen getrennt werden.
Der Masterknoten ist ausgefallen
Wenn der Master ausfällt, kommt es zu folgenden Kettenreaktionen:
- Alle mit dem Master verbundenen Client-Verbindungen werden getrennt;
- Der älteste Slave-Knoten wird zum Master gewählt (weil der Synchronisationszustand zwischen dem ältesten Slave und dem vorherigen Master der beste sein sollte). Wenn zu diesem Zeitpunkt nicht alle Slaves vollständig synchronisiert sind, gehen einige nicht synchronisierte Nachrichten verloren;
- Der neue Master-Knoten stellt alle Unack-Nachrichten erneut in die Warteschlange, da der neue Knoten nicht unterscheiden kann, ob diese Unack-Nachrichten den Client erreicht haben oder ob die ACK-Nachricht auf der Verbindung des alten Masters oder in der Multicast-ACK-Nachricht des Masters auf allen Slave-Verbindungen verloren gegangen ist . Stellen Sie daher aus Gründen der Nachrichtenzuverlässigkeit alle nicht bestätigten Nachrichten erneut in die Warteschlange. Zu diesem Zeitpunkt verfügt der Client möglicherweise über doppelte Nachrichten;
- Wenn der Client mit dem Slave verbunden ist und der x-cancel-on-ha-failover-Parameter angegeben wird, wenn Basic.Consume verbraucht, erhält der Client eine Consumer Cancellation Notification. Wenn der Parameter x-cancal-on-ha-failover nicht angegeben ist, weiß der Verbraucher nicht, dass der Master ausgefallen ist, und wartet ewig.
Dies sagt uns, dass es riskant ist, den Master-Knoten erneut zu wählen, wenn es gespiegelte Warteschlangen im Cluster gibt.
Startsequenz des Knotens
Die Startreihenfolge der Knoten in der Spiegelwarteschlange ist sehr speziell: Unter der Annahme, dass der Cluster zwei Knoten enthält, werden normalerweise drei Knoten in der Produktionsumgebung bereitgestellt, aber zur Vereinfachung der Beschreibung erfolgt die Beschreibung in Form von zwei Knoten.
Szenario 1: A stoppt zuerst, dann stoppt B
In diesem Szenario ist B der Master, solange Sie zuerst B und dann A starten. Oder starten Sie zuerst A und starten Sie dann B innerhalb von 30 Sekunden, um die Spiegelwarteschlange wiederherzustellen. (Wenn B nicht innerhalb von 30 Sekunden antwortet, stoppt A sich selbst)
Szenario 2: A, B halten gleichzeitig an
In diesem Szenario kann dies durch einen Stromausfall oder andere Gründe verursacht werden. Es muss nur A und B innerhalb von 30 Sekunden kontinuierlich gestartet werden, um die Spiegelwarteschlange wiederherzustellen.
Szenario 3: A stoppt zuerst, dann stoppt B und A kann nicht fortfahren.
Da B der Master ist, rufen Sie nach dem Aufstehen von B rabbitmqctl forget_cluster_node A auf Knoten B auf, um die Clusterbeziehung von A zu kontaktieren, und fügen Sie dann den neuen Slave-Knoten zu B hinzu, um die Spiegelwarteschlange wiederherzustellen.
Szenario 4: A stoppt zuerst, dann stoppt B und B kann nicht fortfahren
Dieses Szenario ist schwer zu handhaben. Für die alte Version von RabbitMQ gibt es keine effektive Lösung. In der aktuellen Version ist es nicht möglich, A direkt zu starten, da B der Master ist. Wenn A nicht gestartet werden kann, gibt es keine Version zu Aufruf auf Node A. rabbitmqctl forget_cluster_node B, forget_cluster_node unterstützt den Parameter -offline in der neuen Version, der Parameter offline erlaubt rabbitmqctl, den Befehl forget_cluster_node auf dem Offline-Node auszuführen, wodurch RabbitMQ gezwungen wird, einen der Slave-Nodes auszuwählen, die nicht als gestartet wurden der Meister. Wenn rabbitmqctl forget_cluster_node -offline B auf Knoten A ausgeführt wird, verspottet RabbitMQ einen Knoten im Namen von A, führt den forget_cluster_node-Befehl aus, um B aus dem Cluster zu holen, und dann kann A normal starten. Fügen Sie schließlich den neuen Slave-Knoten zu A hinzu, um die Spiegelwarteschlange wiederherzustellen
Szenario 5: A stoppt zuerst, dann stoppt B, und weder A noch B können wiederhergestellt werden, aber die Plattendateien von A oder B können abgerufen werden
Dieses Szenario ist schwieriger zu handhaben. Kopieren Sie die Datenbankdatei von A oder B (im Verzeichnis $RabbitMQ_HOME/var/lib) in das Verzeichnis des neuen Knotens C und ändern Sie dann den Hostnamen von C in den Hostnamen von A oder B. Wenn die kopierte Datei die Plattendatei von Knoten A ist, wird sie gemäß Szenario 4 verarbeitet; wenn die kopierte Datei die Plattendatei von Knoten B ist, wird sie gemäß Szenario 3 verarbeitet. Fügen Sie schließlich den neuen Slave-Knoten zu C hinzu, um die Spiegelwarteschlange wiederherzustellen.
Szenario 6: A stoppt zuerst, dann stoppt B, und weder A noch B können wiederhergestellt werden, und die Festplattendateien von A und B können nicht abgerufen werden
Keine Lösung.
Es gibt ein Konzept von 30 Sekunden in der Startsequenz.Dies ist das Zeitintervall von MQ, das verwendet wird, um zu erkennen, ob Master undSlave verfügbar sind, daher sind 30 Sekunden sehr kritisch.
Für den Restart-Vorgang des MQ-Clusters in der Produktivumgebung ist eine Analyse der konkreten Operationsreihenfolge erforderlich, ein ungeordneter Restart darf keine irreparablen Schäden (Datenverlust, Node-Startausfall) verursachen.
Achtung bei der Verwendung
Gespiegelte Warteschlangen können nicht für den Lastenausgleich verwendet werden
Die gespiegelte Warteschlange ist kein Lastausgleich, und die gespiegelte Warteschlange kann die Übertragungseffizienz von Nachrichten nicht verbessern, oder ferner wird die Übertragungseffizienz der Nachricht verbraucht, da die gespiegelte Warteschlange zwischen verschiedenen Knoten synchronisiert wird.
Das Einstellen der Spiegelung für die exklusive Warteschlange hat keine Auswirkung
Das Spiegeln der exklusiven Warteschlange hat keine Auswirkung, da die exklusive Warteschlange exklusiv für die Verbindung ist. Wenn die Verbindung getrennt wird, wird die Warteschlange automatisch gelöscht. Diese beiden Parameter haben also eigentlich keine Bedeutung für die exklusive Warteschlange. Welche Warteschlangen sind also exklusiv? Im Allgemeinen sind Publish-Subscribe-Warteschlangen und Warteschlangen mit diesem Parametersatz exklusive Warteschlangen. Wie kann festgestellt werden, ob eine Warteschlange eine exklusive Warteschlange ist? Wenn die Merkmale der Warteschlange Excl enthalten, bedeutet dies, dass es sich um eine exklusive Warteschlange handelt.
Designfehler von Spiegelschlangen
Das größte Problem bei gespiegelten Warteschlangen ist die geringe Leistung, die durch ihre Synchronisationsalgorithmen verursacht wird. Die Spiegelwarteschlange hat die folgenden Designfehler
Designfehler 1: Der Broker ist wieder online
Wenn der Broker offline geht und wieder hochfährt, werden alle Daten, die er im Mirror hatte, verworfen (der Mirror kam wieder online, aber leer), und der Administrator muss eine Entscheidung treffen: ob der Mirror synchronisiert werden soll oder nicht. "Sync" bedeutet, die aktuelle Nachricht vom Leader auf den Mirror zu kopieren.
(Voreingestellt ist natürlich die manuelle Synchronisierung, es kann aber auch auf automatische Synchronisierung umgestellt werden).
Konstruktionsfehler 2: synchrones Blockieren
Wenn Sie Nachrichten synchronisieren möchten, wird die gesamte Warteschlange blockiert, sodass diese Warteschlange nicht verfügbar ist. Dies ist normalerweise kein Problem, wenn die Warteschlange kurz ist, aber wenn die Warteschlange lang oder die gesamte Nachrichtengröße groß ist, dauert die Synchronisierung lange. Darüber hinaus kann die Synchronisierung Speicherprobleme im Cluster verursachen und manchmal sogar dazu führen, dass die Synchronisierung hängen bleibt und einen Neustart erfordert.
Standardmäßig werden alle gespiegelten Warteschlangen automatisch synchronisiert, aber es gibt Benutzer, die Spiegel nicht synchronisieren. Auf diese Weise werden alle neuen Nachrichten repliziert und alte Nachrichten werden nicht repliziert, was die Redundanz verringert und die Wahrscheinlichkeit eines Nachrichtenverlusts erhöht.
Dieses Problem wirft auch das Problem fortlaufender Upgrades auf, da ein neu gestarteter Broker alle seine Daten verwirft und eine Synchronisierung erfordert, um die vollständige Datenredundanz wiederherzustellen.