RabbitMQ 4

AMQP 1.0 als Kernprotokoll: Weitere Informationen finden Sie unter Protokolle.

Lokale Schaufeln: Shovels unterstützen jetzt zusätzlich zu AMQP 0-9-1 und AMQP 1.0 ein neues Protokoll namens „local“. Local Shovels basieren intern auf AMQP 1.0, verwenden aber keine separaten TCP-Verbindungen, sondern clusterinterne Verbindungen zwischen Clusterknoten und interne Verbindungen für die Veröffentlichung und Nutzung von Nachrichten. APIs Dies kann nur für die Nutzung und Veröffentlichung innerhalb desselben Clusters verwendet werden und bietet einen höheren Durchsatz bei geringerem Ressourcenverbrauch als AMQP 0-9-1 und AMQP 1.0.

Quorum-Warteschlangen unterstützen Nachrichtenprioritäten: Die Nachrichtenprioritäten von Quorum-Warteschlangen sind immer aktiv und erfordern keine Richtlinie, um zu funktionieren. Sobald eine Quorum-Warteschlange eine Nachricht mit einer festgelegten Priorität empfängt, wird die Priorisierung aktiviert. Quorum-Warteschlangen unterstützen intern nur zwei Prioritäten: hoch und normal. Nachrichten ohne Prioritätssatz werden der normalen Priorität zugeordnet, ebenso wie die Prioritäten 0-4. Nachrichten mit einer höheren Priorität als 4 werden der höchsten Priorität zugeordnet. Nachrichten mit hoher Priorität werden Nachrichten mit normaler Priorität im Verhältnis 2:1 vorgezogen, d. h. für jeweils 2 Nachrichten mit hoher Priorität wird die Warteschlange 1 Nachricht mit normaler Priorität zugestellt (falls verfügbar). In Quorumwarteschlangen wird daher eine Art nicht strikter Prioritätsverarbeitung nach dem Prinzip „fair share“ implementiert. Auf diese Weise wird gewährleistet, dass bei Nachrichten mit normaler Priorität stets Fortschritte erzielt werden, hohe Prioritäten jedoch in einem Verhältnis von 2:1 bevorzugt werden.

Khepri: Khepri wird als Standard-Metadatenspeicher für RabbitMQ 4-Broker verwendet

Mutual TLS (mTLS): Amazon MQ unterstützt Mutual TLS (mTLS) für RabbitMQ-Broker, sodass sich Kunden mithilfe von Zertifikaten authentifizieren können. Weitere Informationen finden Sie unter mTLS-Konfiguration.

SSL-Zertifikat-Authentifizierungs-Plugin: Das SSL-Authentifizierungs-Plugin verwendet Client-Zertifikate von mTLS-Verbindungen, um Benutzer zu authentifizieren, sodass die Authentifizierung mithilfe von X.509-Clientzertifikaten anstelle von Benutzernamen und Kennwortanmeldeinformationen ermöglicht wird. Weitere Informationen finden Sie unter SSL-Zertifikatsauthentifizierung.

HTTP-Authentifizierungs-Plugin: Das HTTP-Authentifizierungs-Backend-Plugin ermöglicht das Delegieren von Authentifizierung und Autorisierung an einen externen HTTP-Dienst. Weitere Informationen finden Sie unter HTTP-Authentifizierung und Autorisierung.

Spiegelung klassischer Warteschlangen: Klassische Warteschlangen werden weiterhin unterstützt, ohne dass grundlegende Änderungen für Client-Bibliotheken und -anwendungen vorgenommen wurden, aber sie sind jetzt ein nicht replizierter Warteschlangentyp. Die Clients können sich mit jedem beliebigen Knoten verbinden, um Inhalte auf allen nicht replizierten klassischen Warteschlangen zu veröffentlichen und Daten aus diesen zu nutzen. Quorum-Warteschlangen werden aus Gründen der Replikation und Datensicherheit empfohlen.

Entfernung von Global QoS: Kunden wird empfohlen, QoS pro Verbraucher (nicht global) anstelle von Global QoS festzulegen, bei dem ein einziger gemeinsam genutzter Prefetch für einen gesamten Kanal verwendet wird.

Support für vorübergehende, nicht exklusive Warteschlangen: Transiente Warteschlangen sind Warteschlangen, deren Lebensdauer von der Verfügbarkeit des Knotens abhängt, auf dem sie deklariert sind. In einem Single-Instance-Broker werden sie entfernt, wenn der Knoten neu gestartet wird. In einer Clusterbereitstellung werden sie entfernt, wenn der Knoten, auf dem sie gehostet werden, neu gestartet wird. Wir empfehlen die Verwendung von Queue-TTL für das automatische Löschen ungenutzter Warteschlangen im Leerlauf nach einer gewissen Zeit der Inaktivität. Exklusive Warteschlangen werden weiterhin unterstützt und werden gelöscht, sobald alle Verbindungen zur Warteschlange entfernt wurden.

Standard-Warteschlangentyp: Der Standard-Warteschlangentyp auf einem RabbitMQ 4-Broker ist auf Quorum eingestellt. Wenn bei der Erstellung der Warteschlange kein Argument für den Warteschlangentyp angegeben wird, wird eine Quorum-Warteschlange erstellt.

Das Standardlimit für die erneute Zustellung von Quorumwarteschlangen ist auf 20 festgelegt: Nachrichten, die 20 Mal oder öfter erneut zugestellt werden, werden als unleserlich markiert oder gelöscht (entfernt). Wenn 20 Zustellungen pro Nachricht ein übliches Szenario für eine Warteschlange sind, muss für solche Warteschlangen ein Ziel mit unerlaubter Nachricht oder ein höheres Limit konfiguriert werden, um Datenverlust zu vermeiden. Der empfohlene Weg, dies zu tun, ist eine Richtlinie.

amqplib: Amqplib-Versionen des Node-JS-Clients, die älter als 0.10.7 sind, oder jede AMQP-Clientbibliothek, die frame_max < 8192 verwendet, können keine Verbindung zu RabbitMQ herstellen

Standard-Ressourcenlimits: Amazon MQ for RabbitMQ hat Standardbeschränkungen für die Ressourcennutzung für Verbindungen, Kanäle, Verbraucher pro Kanal, Warteschlangen, Vhosts, Shovels, Exchanges und die maximale Nachrichtengröße eingeführt. Diese dienen als Leitplanken zum Schutz der Verfügbarkeit von Brokern und können mithilfe von Konfigurationen an Ihre spezifischen Anforderungen angepasst werden.

Lokaler zufälliger Austausch: Lokale zufällige Börsen werden auf Amazon MQ nicht unterstützt, da sich die Amazon MQ-Knoten hinter einem Netzwerk-Load-Balancer befinden.

Message Interceptor: RabbitMQ-Nachrichtenabfanger werden auf Amazon MQ nicht unterstützt.

Metriken pro Warteschlange: Amazon MQ verkauft keine RabbitMQ-Warteschlangenmetriken für RabbitMQ 4-Broker. AWS CloudWatch Amazon MQ wird weiterhin Metriken auf Brokerebene bereitstellen. AWS CloudWatch Sie können Warteschlangenmetriken mithilfe der RabbitMQ-Management-API abfragen. Wir empfehlen, Metriken für bestimmte Warteschlangen in Intervallen von einer Minute oder länger abzufragen.