Bewährte Methoden für die Beständigkeit und Zuverlässigkeit von Nachrichten in Amazon MQ für RabbitMQ

Bevor Sie Ihre Anwendung in die Produktionsumgebung überführen, sollten Sie sich an die folgenden bewährten Methoden halten, um Nachrichtenverlust und Ressourcenüberlastung zu verhindern.

Schritt 1: 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());

Schritt 2: Konfigurieren Sie die Bestätigung durch den Herausgeber und die Empfangsbestätigung für Verbraucher

Der Vorgang der Bestätigung, dass eine Nachricht an den Broker gesendet wurde, wird als Bestätigung durch den Herausgeber bezeichnet. Durch Bestätigungen des Herausgebers wird Ihre Anwendung darüber informiert, wann Nachrichten zuverlässig gespeichert wurden. Mithilfe von Bestätigungen durch den Herausgeber können Sie auch kontrollieren, wie viele Nachrichten auf dem Broker gespeichert werden. Ohne Bestätigung durch den Herausgeber gibt es keine Bestätigung dafür, dass eine Nachricht erfolgreich verarbeitet wurde, und Ihr Broker kann Nachrichten löschen, die er nicht verarbeiten kann.

Wenn eine Kundenanwendung eine Bestätigung über die Zustellung und den Empfang von Nachrichten an den Broker zurücksendet, wird dies auch als Empfangsbestätigung für Verbraucher bezeichnet. Sowohl Bestätigung als auch Bestätigung sind für die Gewährleistung der Datensicherheit bei der Zusammenarbeit mit RabbitMQ-Brokern unerlässlich.

Die Bestätigung der Verbraucherzustellung wird in der Regel in der Clientanwendung konfiguriert. Bei der Arbeit mit AMQP 0-9-1 kann die Bestätigung durch Konfiguration der Methode aktiviert werden. basic.consume AMQP 0-9-1-Clients können auch Herausgeberbestätigungen 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);
         }
     });

Anmerkung

Nicht bestätigte Nachrichten müssen im Speicher zwischengespeichert werden. Sie können die Anzahl der Nachrichten einschränken, die ein Konsumenten vorabruft, indem SieVorabruf-Einstellungen für eine Client-Anwendung konfigurieren.

Sie können die Konfiguration so konfigurierenconsumer_timeout, dass erkannt wird, wenn Verbraucher Lieferungen nicht bestätigen. Wenn der Kunde innerhalb des Timeout-Werts keine Empfangsbestätigung sendet, wird der Kanal geschlossen und Sie erhalten eine. PRECONDITION_FAILED Um den Fehler zu diagnostizieren, verwenden Sie die UpdateConfigurationAPI, um den Wert zu erhöhen. consumer_timeout

Schritt 3: Halten Sie die Warteschlangen kurz

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 Synchronisierung werden Nachrichten, die auf Spiegelungen repliziert werden müssen, vom entsprechenden Amazon Elastic Block Store (Amazon EBS) -Volume in den Speicher geladen, um in Batches verarbeitet zu werden. 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 Messwerte für den Knoten RabbitMemUsed und den RabbitMqMemLimit Broker 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 Richtlinien für automatisches Löschen und TTL definieren, um den Ressourcenverbrauch proaktiv zu reduzieren und die Anzahl der Benutzer auf ein NACKs Minimum zu reduzieren. Das Warteschleifen von Nachrichten auf dem Broker ist CPU-intensiv, sodass eine hohe Anzahl von Nachrichten die Leistung des Brokers beeinträchtigen kann. NACKs