Nachrichtenwarteschlange ist eine wesentliche Fähigkeit in Szenarien mit hoher Parallelität. Da wir sie verwenden, gibt es viele Probleme in der Produktionsumgebung, wie zum Beispiel: Wie erreicht man eine hohe Verfügbarkeit der Nachrichtenwarteschlange?
Es gibt viele Arten von Middleware für Szenarien. Hier bereiten wir einige häufig verwendete Middleware für die Analyse und Verarbeitung vor.
1. Hohe Verfügbarkeit von RabbitMQ
RabbitMQ ist relativ repräsentativ, da es auf einer Master-Slave-Hochverfügbarkeit (nicht verteilt) basiert. Daher verwenden wir RabbitMQ Beispiel zur Erläuterung, wie die Hochverfügbarkeit des ersten MQ implementiert wird.
RabbitMQ verfügt über drei Modi: Standalone-Modus, normaler Cluster-Modus und Spiegel-Cluster-Modus.
Einzelspielermodus
Der Standalone-Modus ist Demo-Level und kann zum Spaß lokal gestartet werden.
Normaler Clustermodus (keine Hochverfügbarkeit)
Normaler Clustermodus bedeutet, dass mehrere RabbitMQ-Instanzen auf mehreren Maschinen gestartet werden, eine für jede Maschine. Die von Ihnen erstellte Warteschlange wird nur auf einer RabbitMQ-Instanz platziert, aber jede Instanz synchronisiert die Metadaten der Warteschlange (Metadaten können als einige Konfigurationsinformationen der Warteschlange betrachtet werden. Mithilfe von Metadaten können Sie die Instanz finden, in der sich die Warteschlange befindet). .
Wenn Sie beim Konsumieren tatsächlich mit einer anderen Instanz verbunden sind, ruft diese Instanz Daten von der Instanz ab, in der sich die Warteschlange befindet.
Diese Methode ist wirklich mühsam und nicht sehr gut. Sie erreicht nicht die sogenannte Verteilung und ist nur ein gewöhnlicher Cluster. Denn dies führt dazu, dass der Verbraucher entweder jedes Mal eine zufällige Verbindung zu einer Instanz herstellt und Daten abruft oder eine feste Verbindung zu der Instanz herstellt, in der sich die Warteschlange befindet, um Daten zu verbrauchen. Ersteres hat den Overhead des Datenabrufs und letzteres führt zu einem Single-Pull. Engpass bei der Instanzleistung.
Und wenn die Instanz, die die Warteschlange stellt, ausfällt, können andere Instanzen nicht von dieser Instanz abrufen. Wenn Sie die Nachrichtenpersistenz aktivieren und RabbitMQ Nachrichten speichern lassen, müssen die Nachrichten nicht unbedingt verloren gehen Warten Sie, bis sich diese Instanz erholt hat, bevor Sie mit dem Abrufen von Daten aus dieser Warteschlange fortfahren können.
Diese Angelegenheit ist also noch peinlicher. Es gibt keine sogenannte Hochverfügbarkeit. Diese Lösung besteht hauptsächlich darin, den Durchsatz zu verbessern, d Warteschlange. .
Spiegelclustermodus (Hochverfügbarkeit)
Dieser Modus ist der sogenannte Hochverfügbarkeitsmodus von RabbitMQ. Der Unterschied zum normalen Cluster-Modus besteht darin, dass die von Ihnen erstellte Warteschlange unabhängig von Metadaten oder Nachrichten in der Warteschlange auf mehreren Instanzen vorhanden ist. Das heißt, jeder RabbitMQ-Knoten verfügt über eine vollständige Kopie dieser Warteschlange. Spiegeln bedeutet, dass alle Daten der Warteschlange enthalten sind. Jedes Mal, wenn Sie eine Nachricht in die Warteschlange schreiben, wird die Nachricht automatisch mit den Warteschlangen mehrerer Instanzen synchronisiert.
Wie aktiviert man also diesen Spiegel-Cluster-Modus? Tatsächlich ist es sehr einfach, eine Richtlinie im Hintergrund hinzuzufügen. Bei dieser Richtlinie können Sie festlegen, dass Daten mit allen Knoten synchronisiert werden Wenn der Knoten die Warteschlange erneut erstellt, werden die Daten durch die Anwendung dieser Strategie automatisch mit anderen Knoten synchronisiert.
In diesem Fall besteht der Vorteil darin, dass, wenn einer Ihrer Computer ausfällt, auch andere Computer (Knoten) die vollständigen Daten dieser Warteschlange enthalten und andere Verbraucher zu anderen Knoten wechseln können Daten verbrauchen.
Die Nachteile sind erstens, dass der Leistungsaufwand zu hoch ist. Die Nachrichten müssen auf allen Maschinen synchronisiert werden, was zu hohem Druck und Verbrauch von Netzwerkbandbreite führt!
Zweitens werden diese Spiele nicht verteilt und sind nicht skalierbar. Wenn eine Warteschlange stark ausgelastet ist und Sie eine Maschine hinzufügen, enthält die neue Maschine auch alle Daten der Warteschlange, und es gibt keine Möglichkeit dazu Erweitern Sie Ihre Warteschlange linear.
2. Hohe Verfügbarkeit von Kafka
Eines der grundlegendsten Architekturverständnisse von Kafka: Es besteht aus mehreren Brokern, jeder Broker ist ein Knoten Thema: Dieses Thema kann in mehrere Partitionen unterteilt werden, jede Partition kann auf verschiedenen Brokern vorhanden sein und jede Partition speichert einen Teil der Daten.
Dies ist eine natürlich verteilte Nachrichtenwarteschlange, was bedeutet, dass die Daten eines Themas auf mehrere Computer verteilt sind und jeder Computer einen Teil der Daten speichert.
Tatsächlich sind RabbmitMQ und dergleichen keine verteilten Nachrichtenwarteschlangen. Sie bieten lediglich einige Clustering- und HA-Mechanismen (Hochverfügbarkeit, Hochverfügbarkeit), denn egal, wie Sie spielen Daten einer Warteschlange in RabbitMQ werden auf einem Knoten platziert. Unter dem Spiegelcluster werden auch die vollständigen Daten der Warteschlange auf jedem Knoten platziert.
Vor Kafka 0.8 gab es keinen HA-Mechanismus. Wenn ein Broker ausfiel, war die Partition auf diesem Broker nutzlos und konnte weder geschrieben noch gelesen werden. Es gab überhaupt keine Hochverfügbarkeit.
Wir gehen beispielsweise davon aus, dass wir ein Thema erstellen und angeben, dass die Anzahl der Partitionen 3 beträgt, jeweils auf drei Maschinen. Wenn jedoch die zweite Maschine ausfällt, gehen 1/3 der Daten zu diesem Thema verloren, sodass diese nicht hochverfügbar sein können.
Kafka 0.8 und höher bietet einen HA-Mechanismus, bei dem es sich um einen Replikatmechanismus handelt. Die Daten jeder Partition werden mit anderen Maschinen synchronisiert, um eigene Mehrfachreplikate zu bilden. Alle Nachbildungen werden einen Anführer wählen, dann werden sich Produktion und Konsum um diesen Anführer kümmern, und andere Nachbildungen werden Anhänger sein. Beim Schreiben ist der Anführer dafür verantwortlich, die Daten mit allen Followern zu synchronisieren. Beim Lesen lesen Sie einfach die Daten direkt am Anführer. Kann Anführer nur lesen und schreiben?
Es ist ganz einfach. Wenn Sie jeden Follower nach Belieben lesen und schreiben können, müssen Sie sich um das Problem der Datenkonsistenz kümmern. Die Systemkomplexität ist zu hoch und es können leicht Probleme auftreten. Kafka verteilt alle Replikate einer Partition gleichmäßig auf verschiedene Maschinen, um die Fehlertoleranz zu verbessern.
Auf diese Weise gibt es eine sogenannte Hochverfügbarkeit, denn wenn ein bestimmter Broker ausfällt, wird er ausfallen Gut. Die Partitionen auf diesem Broker haben Kopien auf anderen Computern. Wenn der gestürzte Broker einen Anführer einer bestimmten Partition hat, wird aus den Anhängern ein neuer Anführer wiedergewählt, und jeder kann den neuen Anführer weiterhin lesen und schreiben. Dies wird als Hochverfügbarkeit bezeichnet.
Beim Schreiben von Daten schreibt der Produzent an den Anführer, und dann schreibt der Anführer die Daten auf die lokale Festplatte, und dann ergreifen andere Follower die Initiative, um Daten vom Anführer abzurufen. Sobald alle Follower die Daten synchronisiert haben, senden sie Bestätigungen an den Anführer. Nachdem der Anführer die Bestätigungen von allen Followern erhalten hat, sendet er eine erfolgreich geschriebene Nachricht an den Produzenten zurück. (Natürlich ist dies nur einer der Modi, und dieses Verhalten kann entsprechend angepasst werden)
Beim Konsumieren wird nur vom Anführer gelesen, aber nur, wenn eine Nachricht von allen Followern erfolgreich synchronisiert wurde Gibt ack zurück, diese Nachricht wird von Verbrauchern gelesen.
Weitere PHP-Kenntnisse finden Sie im PHP-Tutorial!
Das obige ist der detaillierte Inhalt vonWie kann die hohe Verfügbarkeit der Nachrichtenwarteschlange sichergestellt werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
