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.
Bewährte Methoden für die Haltbarkeit und Zuverlässigkeit von Nachrichten in Amazon MQ für RabbitMQ
Bevor Sie Ihre Anwendung in die Produktionsumgebung überführen, sollten Sie die folgenden bewährten Methoden beachten, um Nachrichtenverlust und Ressourcenüberlastung zu verhindern.
Schritt 1: Verwenden Sie persistente Nachrichten und langlebige Warteschlangen
Dauerhafte Nachrichten können dazu beitragen, die Haltbarkeit von Daten in Situationen zu schützen, 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
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 Verlag und die Empfangsbestätigung durch den Verbraucher
Der Vorgang, bei dem bestätigt wird, dass eine Nachricht an den Broker gesendet wurde, wird als Bestätigung durch den Herausgeber bezeichnet. Bestätigungen durch den Herausgeber teilen Sie Ihrer Anwendung mit, wenn Nachrichten zuverlässig gespeichert wurden. Publisher-Bestätigungen können auch dazu beitragen, die Anzahl der beim Broker gespeicherten Nachrichten zu kontrollieren. Ohne die Bestätigung durch den Herausgeber gibt es keine Bestätigung, dass eine Nachricht erfolgreich verarbeitet wurde, und Ihr Broker löscht möglicherweise Nachrichten, die er nicht verarbeiten kann.
Wenn eine Kundenanwendung die Bestätigung der Zustellung und des Empfangs von Nachrichten an den Broker zurücksendet, wird dies ebenfalls als Empfangsbestätigung für den Verbraucher bezeichnet. Sowohl die Bestätigung als auch die Bestätigung sind unerlässlich, um die Datensicherheit bei der Zusammenarbeit mit RabbitMQ-Brokern zu gewährleisten.
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 Publisher-Bestä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 Verbraucher innerhalb des Timeout-Werts keine Bestätigung sendet, wird der Kanal geschlossen und Sie erhalten eine. PRECONDITION_FAILED Um den Fehler zu diagnostizieren, verwenden Sie die UpdateConfiguration API, 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 Metriken des RabbitMemUsed RabbitMqMemLimit Broker-Knotens 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 den Zugriff von Verbrauchern auf ein Minimum zu beschränken. CPU-intensive Da Nachrichten auf dem Broker erneut in die Warteschlange gestellt werden, kann eine hohe Anzahl von NACKs die Leistung des Brokers beeinträchtigen.
