Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Best Practices für Amazon MQ for RabbitMQ

Verwenden Sie dies als Referenz, um schnell Empfehlungen zur Maximierung der Leistung und Minimierung der Durchsatzkosten bei der Arbeit mit RabbitMQ-Brokern auf Amazon MQ zu finden.

Aktivieren Sie automatische Upgrades für kleinere Versionen

Verwenden Sie die neuesten Sicherheits- und Bugfixes sowie Leistungsverbesserungen der neuesten Broker-Version. Sie können automatische Upgrades für Nebenversionen für Amazon MQ aktivieren, um Upgrades auf die neueste Patch-Version zu verwalten.

Verwenden veralteter Funktionen

Wenn Sie Version 3.13 für RabbitMQ auf Amazon MQ verwenden, sehen Sie in der RabbitMQ Management UI ein Banner mit der Aufschrift: Deprecated features are being used.

Dies liegt daran, dass RabbitMQ auf Amazon MQ die folgenden Funktionen verwendet, die auf RabbitMQ nicht mehr angeboten werden oder automatisch für RabbitMQ auf Amazon MQ konfiguriert sind:

Dies ist ein Informationsbanner für Version 3.13, für das keine Aktion erforderlich ist. Ihr Amazon MQ-Broker wird diese Funktionen weiterhin verwenden.

Wählen Sie den richtigen Broker-Instance-Typ für den besten Durchsatz

Der Nachrichtendurchsatz eines Broker-Instance-Typs hängt von Ihrem Anwendungsfall ab. Kleinere Broker-Instance-Typen wie t3.micro sollten nur zum Testen der Anwendungsleistung verwendet werden. Wenn Sie diese Mikro-Instances verwenden, bevor Sie größere Instances in der Produktion einsetzen, können Sie die Anwendungsleistung verbessern und die Entwicklungskosten niedrig halten. Bei Instance-Typen m5.large und höher können Sie Cluster-Bereitstellungen für hohe Verfügbarkeit und Nachrichtenbeständigkeit verwenden. Größere Broker-Instance-Typen können das Produktionsniveau von Clients und Warteschlangen, einen hohen Durchsatz, Nachrichten im Speicher und redundante Nachrichten bewältigen. Weitere Informationen zur Auswahl des richtigen Instance-Typs finden Sie unter Richtlinien zur Größenbestimmung.

Verwenden Sie mehrere Kanäle

Verwenden Sie mehrere Kanäle über eine einzige Verbindung, um Verbindungsabwanderungen zu vermeiden. Anwendungen sollten ein Verhältnis von Verbindung zu Kanal von 1:1 vermeiden. Wir empfehlen, eine Verbindung pro Prozess und dann einen Kanal pro Thread zu verwenden. Vermeiden Sie eine übermäßige Kanalnutzung, um Kanallecks zu vermeiden.

Lazy-Warteschlangen aktivieren

Wenn Sie mit sehr langen Warteschlangen arbeiten, die große Mengen an Nachrichten verarbeiten, kann die Aktivierung verzögerter Warteschlangen die Leistung des Brokers verbessern.

Das Standardverhalten von RabbitMQ besteht darin, Nachrichten im Speicher zwischenzuspeichern und sie nur dann auf die Festplatte zu verschieben, wenn der Broker mehr verfügbaren Speicher benötigt. Das Verschieben von Nachrichten vom Speicher auf die Festplatte nimmt Zeit in Anspruch und stoppt die Nachrichtenverarbeitung. Lazy Queues beschleunigt den Prozess zwischen Speicher und Festplatte erheblich, da Nachrichten so schnell wie möglich auf der Festplatte gespeichert werden. Dadurch werden weniger Nachrichten im Arbeitsspeicher zwischengespeichert.

Sie können Lazy-Queues aktivieren, indem Sie die queue.declare-Argumente zum Zeitpunkt der Deklaration oder durch Konfigurieren einer Richtlinie über die RabbitMQ-Verwaltungskonsole. Das folgende Beispiel veranschaulicht das Deklarieren einer Lazy-Queue mit der RabbitMQ Java-Client-Bibliothek.

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);

Alle Amazon MQ for RabbitMQ-Warteschlangen auf Version 3.12.13 und höher verhalten sich standardmäßig wie faule Warteschlangen. Informationen zum Upgrade auf die neueste Version von Amazon MQ für RabbitMQ finden Sie unter. Aktualisieren einer Amazon MQ-Broker-Engine-Version

Verwenden Sie persistente Nachrichten und dauerhafte Warteschlangen

Persistente Nachrichten können dazu beitragen, Datenverlust in Situationen zu verhindern, in denen ein Broker abstürzt oder neu gestartet wird. Persistente Nachrichten werden auf die Festplatte geschrieben, sobald sie eintreffen. Im Gegensatz zu Lazy Queues werden jedoch persistente Nachrichten sowohl im Arbeitsspeicher als auch auf der Festplatte zwischengespeichert, es sei denn, der Broker benötigt mehr Speicher. In Fällen, in denen mehr Speicher benötigt wird, werden Nachrichten vom RabbitMQ-Broker-Mechanismus aus dem Speicher entfernt, der das Speichern von Nachrichten auf der Festplatte verwaltet, allgemein alsSitzungspersistenz bezeichnet.

Um die Nachrichtenpersistenz zu aktivieren, können Sie Ihre Warteschlangen alsdurable erklären und den Nachrichtenübermittlungsmodus aufpersistent stellen. Das folgende Beispiel veranschaulicht die Verwendung der RabbitMQ-Java-Client-Bibliothek, um eine dauerhafte Warteschlange zu deklarieren. Wenn Sie mit AMQP 0-9-1 arbeiten, können Sie Nachrichten als persistent markieren, indem Sie den Zustellungsmodus „2" einstellen.

boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);

Nachdem Sie die Warteschlange als dauerhaft konfiguriert haben, können Sie eine dauerhafte Nachricht an Ihre Warteschlange senden, indem SieMessageProperties auf PERSISTENT_TEXT_PLAIN stellen, wie im folgenden Beispiel gezeigt.

import com.rabbitmq.client.MessageProperties;

channel.basicPublish("", "my_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes());

Warteschlangen kurz halten

In Clusterbereitstellungen können Warteschlangen mit einer großen Anzahl von Nachrichten zu einer Überlastung der Ressourcen führen. Wenn ein Broker übermäßig ausgelastet ist, kann ein Neustart eines Amazon MQ für RabbitMQ Brokers zu weiteren Leistungseinbußen führen. Wenn ein Neustart durchgeführt wird, reagieren überlastete Broker möglicherweise nicht im REBOOT_IN_PROGRESS Zustand.

Während dem Wartungsfenster führt Amazon MQ alle Wartungsarbeiten jeweils einen Knoten aus, um sicherzustellen, dass der Broker betriebsbereit bleibt. Daher müssen Warteschlangen möglicherweise synchronisiert werden, wenn jeder Knoten den Vorgang fortsetzt. Während der Synchronisation werden Nachrichten, die auf Spiegel repliziert werden müssen, vom entsprechenden Amazon Elastic Block Store (AmazonEBS) -Volume in den Speicher geladen und stapelweise verarbeitet. Durch die Verarbeitung von Nachrichten in Batches können Warteschlangen schneller synchronisiert werden.

Wenn Warteschlangen kurz gehalten werden und Nachrichten klein sind, werden die Warteschlangen erfolgreich synchronisiert und wie erwartet fortgesetzt. Wenn sich die Datenmenge in einem Batch jedoch dem Speicherlimit des Knotens nähert, löst der Knoten einen Alarm mit hohem Speicher aus, der die Warteschlangen-Synchronisierung pausiert. Sie können die Speichernutzung überprüfen, indem Sie die Metriken der Knoten RabbitMemUsed und des RabbitMqMemLimit Broker-Nodes unter vergleichen. CloudWatch Die Synchronisierung kann erst abgeschlossen werden, wenn Nachrichten verbraucht oder gelöscht oder die Anzahl der Nachrichten im Batch reduziert wird.

Wenn die Warteschlangensynchronisierung für eine Clusterbereitstellung angehalten wird, wird empfohlen, Nachrichten zu verwenden oder zu löschen, um die Anzahl der Nachrichten in Warteschlangen zu verringern. Sobald die Warteschlangentiefe reduziert und die Warteschlangensynchronisierung abgeschlossen ist, ändert sich der Broker-Status zuRUNNING. Um eine angehaltene Warteschlangensynchronisierung aufzulösen, können Sie eine Richtlinie auch aufReduzierung der Batch-Größe der Warteschlangensynchronisation anwenden.

Sie können auch automatische Löschvorgänge und TTL Richtlinien definieren, um den Ressourcenverbrauch proaktiv zu reduzieren und die Anzahl der Benutzer auf ein Minimum zu reduzieren. NACKs Das Warteschleifen von Nachrichten auf dem Broker ist CPU aufwändig, sodass eine hohe Anzahl von Nachrichten die Leistung des NACKs Brokers beeinträchtigen kann.

Bestätigung und Bestätigung konfigurieren

Wenn eine Client-Anwendung die Bestätigung der Zustellung und des Verbrauchs von Nachrichten an den Broker sendet, wird sie alsVerbraucherbestätigung bezeichnet. In ähnlicher Weise wird der Prozess der Bestätigung an einen Herausgeber alsVerlag bestätigen bezeichnet. Der Herausgeber bestätigt, dass Ihre Anwendung darüber informiert wird, wann Nachrichten zuverlässig gespeichert wurden. Ohne Bestätigung durch den Herausgeber akzeptiert Ihr Broker möglicherweise weiterhin Nachrichten, auch wenn der Speicherplatz knapp wird oder er sie nicht verarbeiten kann. Sowohl die Bestätigung als auch die Bestätigung sind unerlässlich, um die Datensicherheit bei der Arbeit mit RabbitMQ-Brokern zu gewährleisten.

Die Bestätigung der Verbraucherzustellung wird in der Regel in der Clientanwendung konfiguriert. Wenn Sie mit AMQP 0-9-1 arbeiten, kann die Bestätigung aktiviert werden, indem Sie das basic.consume oder, wann eine Nachricht mit der Methode abgerufen wird, konfigurieren. basic.code AMQP0-9-1-Clients können auch Bestätigungen durch den Herausgeber konfigurieren, indem sie die Methode senden. confirm.select

In der Regel ist die Zustellungsbestätigung in einem Kanal aktiviert. Wenn Sie beispielsweise mit der RabbitMQ Java-Client-Bibliothek arbeiten, können Sie dieChannel#basicAck verwenden, um eine einfachebasic.ackBestätigungsaufforderung erstellen, wie im folgenden Beispiel gezeigt.

// this example assumes an existing channel instance

boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
     new DefaultConsumer(channel) {
         @Override
         public void handleDelivery(String consumerTag,
                                    Envelope envelope,
                                    AMQP.BasicProperties properties,
                                    byte[] body)
             throws IOException
         {
             long deliveryTag = envelope.getDeliveryTag();
             // positively acknowledge a single delivery, the message will
             // be discarded
             channel.basicAck(deliveryTag, false);
         }
     });

Konfigurieren des Vorabrufs

Sie können den RabbitMQ-Prefetch-Wert verwenden, um zu optimieren, wie Ihre Verbraucher Nachrichten konsumieren. RabbitMQ implementiert den von AMQP 0-9-1 bereitgestellten Channel-Pre-Fetch-Mechanismus, indem der Pre-Fetch-Zähler auf Verbraucher und nicht auf Kanäle angewendet wird. Der Prefetch-Wert wird verwendet, um anzugeben, wie viele Nachrichten an den Verbraucher zu einem bestimmten Zeitpunkt gesendet werden. Standardmäßig legt RabbitMQ eine unbegrenzte Puffergröße für Clientanwendungen fest.

Es gibt eine Vielzahl von Faktoren zu berücksichtigen, wenn Sie eine Pre-Fetch-Anzahl für Ihre RabbitMQ-Verbraucher festlegen. Berücksichtigen Sie zunächst die Umgebung und Konfiguration Ihrer Verbraucher. Da Verbraucher alle Nachrichten während der Verarbeitung im Speicher behalten müssen, kann ein hoher Pre-Fetch-Wert negative Auswirkungen auf die Leistung Ihrer Verbraucher haben und in einigen Fällen dazu führen, dass ein Verbraucher alle zusammen abstürzt. Ebenso behält der RabbitMQ-Broker selbst alle Nachrichten, die er im Speicher sendet, zwischengespeichert, bis er die Verbraucherbestätigung erhält. Ein hoher Prefetch-Wert kann dazu führen, dass Ihr RabbitMQ-Server schnell über den Arbeitsspeicher verfügt, wenn die automatische Bestätigung nicht für Verbraucher konfiguriert ist und wenn Verbraucher relativ lange Zeit benötigen, um Nachrichten zu verarbeiten.

In Anbetracht der obigen Überlegungen empfehlen wir, immer einen Pre-Fetch-Wert festzulegen, um Situationen zu vermeiden, in denen ein RabbitMQ-Broker oder seine Verbraucher aufgrund einer großen Anzahl von unverarbeiteten oder nicht bestätigten Nachrichten nicht genügend Arbeitsspeicher auslaufen. Wenn Sie Ihre Broker optimieren müssen, um große Mengen von Nachrichten zu verarbeiten, können Sie Ihre Broker und Verbraucher mit einer Reihe von Pre-Fetch-Zählungen testen, um den Wert zu bestimmen, an dem der Netzwerk-Overhead im Vergleich zu der Zeit, die ein Verbraucher benötigt, um Nachrichten zu verarbeiten, weitgehend unbedeutend wird.

Das folgende Beispiel demonstriert das Festlegen eines Vorabruf-Werts von10für einen einzelnen Verbraucher mit der RabbitMQ Java-Client-Bibliothek.

ConnectionFactory factory = new ConnectionFactory();

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();

channel.basicQos(10, false);

QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);

Konfigurieren von Celery

Python Celery sendet viele unnötige Nachrichten, die das Auffinden und Verarbeiten nützlicher Informationen erschweren können. Geben Sie den folgenden Befehl ein, um das Rauschen zu reduzieren und die Verarbeitung zu vereinfachen:

celery -A app_name worker --without-heartbeat --without-gossip --without-mingle

Automatische Wiederherstellung nach Netzwerkausfällen

Es wird empfohlen, die automatische Netzwerkwiederherstellung immer zu aktivieren, um erhebliche Ausfallzeiten zu vermeiden, wenn Clientverbindungen zu RabbitMQ-Knoten fehlschlagen. Die RabbitMQ Java-Client-Bibliothek unterstützt standardmäßig automatische Netzwerkwiederherstellung, beginnend mit Version4.0.0.

Die automatische Verbindungswiederherstellung wird ausgelöst, wenn eine nicht behandelte Ausnahme in der I/O-Schleife der Verbindung ausgelöst wird, wenn ein Timeout für den Socket-Lesevorgang erkannt wird oder wenn der Server eineHerzschlag verpasst.

In Fällen, in denen die anfängliche Verbindung zwischen einem Client und einem RabbitMQ-Knoten fehlschlägt, wird die automatische Wiederherstellung nicht ausgelöst. Wir empfehlen, Ihren Anwendungscode zu schreiben, um anfängliche Verbindungsfehler zu berücksichtigen, indem Sie die Verbindung erneut versuchen. Das folgende Beispiel veranschaulicht den erneuten Versuch von anfänglichen Netzwerkfehlern mithilfe der RabbitMQ-Java-Client-Bibliothek.

ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings

try {
  Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
  Thread.sleep(5000);
  // apply retry logic
}

Aktivieren von Classic Queue v2 für Ihren RabbitMQ-Broker

Wir empfehlen, Classic Queue v2 (CQv2) auf den Broker-Engine-Versionen 3.10 und 3.11 zu aktivieren, um unter anderem folgende Leistungsverbesserungen zu erzielen:

Alle Amazon MQ for RabbitMQ-Warteschlangen ab 3.12.13 werden standardmäßig verwendet. CQv2 Informationen zum Upgrade auf die neueste Version von Amazon MQ für RabbitMQ finden Sie unter. Aktualisieren einer Amazon MQ-Broker-Engine-Version

Migration von zu CQv1 CQv2

Um es verwenden zu könnenCQv2, müssen Sie zuerst das classic_mirrored_queue_version Feature-Flag aktivieren. Weitere Informationen zu Feature-Flags finden Sie unter So aktivieren Sie Feature-Flags.

Um von CQv1 zu migrierenCQv2, müssen Sie eine neue Warteschlangenrichtlinie erstellen oder eine bestehende Warteschlangenrichtlinie bearbeiten, wobei die queue-version Richtlinienschlüsseldefinition auf eingestellt ist2. Weitere Informationen zur Anwendung von Richtlinien finden Sie unterAnwenden von Richtlinien auf Amazon MQ für RabbitMQ. Weitere Informationen zur Aktivierung CQv2 mit einer Warteschlangenrichtlinie finden Sie unter Classic Queues in der RabbitMQ-Dokumentation.

Wir empfehlen, vor Beginn der Migration unsere anderen bewährten Methoden zur Leistungsoptimierung zu befolgen.

Wenn du eine Warteschlangenrichtlinie verwendest, führt das Löschen der Warteschlangenrichtlinie dazu, dass die Warteschlangen wieder heruntergestuft CQv2 werden. CQv1 Wir empfehlen nicht, Warteschlangen auf herunterzustufen, CQv1 da RabbitMQ die Darstellung der CQv2 Warteschlange auf der Festplatte konvertiert. Dies kann bei Warteschlangen mit großer Tiefe speicherintensiv und zeitaufwändig sein.