RabbitMQ 4.2

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

Local Shovels: 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 jedoch keine separaten TCP-Verbindungen, sondern clusterinterne Verbindungen zwischen Clusterknoten und internen APIs zum Veröffentlichen und Verarbeiten von Nachrichten. 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: Nachrichtenprioritäten in Quorum-Warteschlangen sind immer aktiv und erfordern keine Richtlinie. Wenn eine Quorumwarteschlange eine Nachricht mit einer festgelegten Priorität empfängt, ermöglicht sie die Priorisierung. Quorumwarteschlangen unterstützen nur zwei interne Prioritätsstufen — hoch und normal.

RabbitMQordnet Nachrichten ohne Priorität und Nachrichten mit den Prioritäten 0—4 dem Normalwert zu. Nachrichten mit einer höheren Priorität als 4 werden der Priorität „Hoch“ zugeordnet. High-priority Nachrichten werden Nachrichten mit normaler Priorität im Verhältnis 2:1 vorgezogen. Für jeweils 2 Nachrichten mit hoher Priorität liefert die Warteschlange eine Nachricht mit normaler Priorität, sofern eine verfügbar ist. Daher implementieren Quorumwarteschlangen ein nicht striktes Verarbeitungsmodell mit Fair-Share-Priorität, das den Fortschritt bei Nachrichten mit normaler Priorität sicherstellt.

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

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. Konfiguration von mTLS

Plug-in für die SSL-Zertifikatsauthentifizierung: Das SSL-Authentifizierungs-Plugin verwendet Client-Zertifikate von mTLS-Verbindungen, um Benutzer zu authentifizieren. Dies ermöglicht die Authentifizierung mithilfe von X.509 Client-Zertifikaten anstelle von Anmeldeinformationen für Benutzername und Passwort. 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.

JMS-Unterstützung: Der Broker unterstützt jetzt JMS-Workloads mit aktiviertem JMS-Themenaustausch-Plugin, sodass JMS-Anwendungen mithilfe des JMS-Clients eine Verbindung herstellen können. RabbitMQ

Konfigurierbare Speichergröße: RabbitMQ 4.x-Broker, die im CLUSTER_MULTI_AZ-Modus bereitgestellt werden, unterstützen konfigurierbare EBS-Speichergrößen. Weitere Informationen finden Sie unter mq.m7g-Instance-Typen. Instanztypen für die m7g-Cluster-Bereitstellung

Spiegelung klassischer Warteschlangen: Klassische Warteschlangen werden weiterhin unterstützt, ohne dass grundlegende Änderungen für Clientbibliotheken und Anwendungen vorgenommen werden, aber sie sind jetzt ein nicht replizierter Warteschlangentyp. Clients können sich mit jedem beliebigen Knoten verbinden, um in beliebigen, nicht replizierten klassischen Warteschlangen zu veröffentlichen und diese zu nutzen. Quorum-Warteschlangen werden aus Gründen der Replikation und Datensicherheit empfohlen.

Abschaffung der globalen QoS: Kunden wird empfohlen, QoS pro Verbraucher (nicht global) einzurichten, anstatt globale QoS, bei der ein einziger gemeinsamer Prefetch für einen gesamten Kanal verwendet wird.

Unterstützung 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 wurden. In einem Single-Instance-Broker werden sie entfernt, wenn der Knoten neu gestartet wird. In einer Cluster-Bereitstellung werden sie entfernt, wenn der Knoten, auf dem sie gehostet werden, neu gestartet wird. Wir empfehlen, Warteschlangen-TTL zu verwenden, um ungenutzte, inaktive Warteschlangen nach einiger Zeit der Inaktivität automatisch zu löschen. Exklusive Warteschlangen werden weiterhin unterstützt und gelöscht, sobald alle Verbindungen zur Warteschlange entfernt wurden.

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

Das Standardlimit für die erneute Zustellung von Quorumwarteschlangen ist auf 20 festgelegt: Nachrichten, die mindestens 20 Mal erneut zugestellt werden, werden unleserlich angezeigt oder verworfen (entfernt). Wenn 20 Übermittlungen pro Nachricht ein übliches Szenario für eine Warteschlange sind, muss für solche Warteschlangen ein unlesbares Ziel oder ein höheres Limit konfiguriert werden, um Datenverlust zu vermeiden. Die empfohlene Methode hierfür ist eine Richtlinie.

amqplib: Der Node-JS-Client, amqplib-Versionen, die älter als 0.10.7 sind, oder eine AMQP-Clientbibliothek, die frame_max < 8192 verwendet, können keine Verbindung herstellen RabbitMQ

Standard-Ressourcenbeschränkungen: Amazon MQ for RabbitMQ hat Standardgrenzwerte 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.