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 Amazon SQS
Amazon SQS verwaltet und verarbeitet Nachrichtenwarteschlangen, sodass verschiedene Teile einer Anwendung Nachrichten zuverlässig und in großem Umfang austauschen können. In diesem Thema werden die wichtigsten bewährten Methoden für den Betrieb behandelt, darunter die Verwendung langer Abfragen zur Reduzierung leerer Antworten, die Implementierung von Warteschlangen für unberechtigte Nachrichten zur Behandlung von Verarbeitungsfehlern und die Optimierung von Warteschlangenberechtigungen aus Sicherheitsgründen.
****Topics****
+ [Fehlerbehandlung und problematische Meldungen](best-practices-error-handling.md)
+ [Deduplizierung und Gruppierung von Nachrichten](best-practices-message-deduplication.md)
+ [Nachrichtenverarbeitung und Timing](best-practices-message-processing.md)
# Amazon SQS SQS-Fehlerbehandlung und problematische Meldungen
Dieses Thema enthält detaillierte Anweisungen zur Verwaltung und Minimierung von Fehlern in Amazon SQS, einschließlich Techniken zur Behandlung von Anforderungsfehlern, zur Erfassung problematischer Nachrichten und zur Konfiguration der Aufbewahrung von Warteschlangen für unzustellbare Nachrichten, um die Nachrichtenzuverlässigkeit zu gewährleisten.
****Topics****
+ [Behandlung von Anforderungsfehlern in Amazon SQS](handling-request-errors.md)
+ [Erfassung problematischer Nachrichten in Amazon SQS](capturing-problematic-messages.md)
+ [Einrichtung der Aufbewahrung von Warteschlangen für unzustellbare Briefe in Amazon SQS](setting-up-dead-letter-queue-retention.md)
# Behandlung von Anforderungsfehlern in Amazon SQS
Für den Umgang mit Anforderungsfehlern nutzen Sie eine der folgenden Strategien:
+ Wenn Sie ein AWS SDK verwenden, steht Ihnen bereits eine automatische *Wiederholungs- und Backoff-Logik* zur Verfügung. Weitere Informationen finden Sie unter [Wiederholversuche bei Fehlern und exponentielles Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html) im *Allgemeine Amazon Web Services-Referenz*.
+ Wenn Sie die AWS SDK-Funktionen für Wiederholungen und Backoffs nicht verwenden, warten Sie eine Pause (z. B. 200 ms), bevor Sie die [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)Aktion erneut versuchen, nachdem Sie keine Nachrichten, eine Zeitüberschreitung oder eine Fehlermeldung von Amazon SQS erhalten haben. Für die nachfolgende Verwendung der Aktion `ReceiveMessage`, mit der dieselben Ergebnisse erzielt werden, lassen Sie eine längere Pause (z. B. 400 ms) zu.
# Erfassung problematischer Nachrichten in Amazon SQS
Um alle Nachrichten zu erfassen, die nicht verarbeitet werden können, und um genaue CloudWatch Messwerte zu sammeln, konfigurieren Sie eine Warteschlange für [unzustellbare Nachrichten.](sqs-dead-letter-queues.md)
+ Die Redrive-Richtlinie leitet Nachrichten an eine Warteschlange für unzustellbare Nachrichten weiter, nachdem die Quell-Warteschlange eine Nachricht mehrfach nicht verarbeiten kann.
+ Durch Verwenden einer Warteschlange für unzustellbare Nachrichten wird die Anzahl der Nachrichten reduziert und das Risiko von *Poison-Pill*-Nachrichten gesenkt, d. h. Nachrichten, die empfangen, aber nicht verarbeitet werden können.
+ Die Aufnahme einer Giftpillen-Nachricht in eine Warteschlange kann die [`ApproximateAgeOfOldestMessage`](sqs-available-cloudwatch-metrics.md) CloudWatch Metrik verfälschen, da das falsche Alter der Giftpillen-Nachricht angegeben wird. Das Konfigurieren einer Warteschlange für unzustellbare Nachrichten hilft, Fehlalarme bei der Verwendung dieser Metrik zu vermeiden.
# Einrichtung der Aufbewahrung von Warteschlangen für unzustellbare Briefe in Amazon SQS
Bei Standard-Warteschlangen basiert der Ablauf einer Nachricht immer auf dem ursprünglichen Enqueue-Zeitstempel. Wenn eine Nachricht in eine Warteschlange für unzustellbare Nachrichten verschoben wird, bleibt der Enqueue-Zeitstempel unverändert. Die `ApproximateAgeOfOldestMessage`-Metrik gibt an, wann die Nachricht in die Warteschlange für unzustellbare Nachrichten verschoben wurde, und *nicht*, wann die Nachricht ursprünglich gesendet wurde. Nehmen wir beispielsweise an, dass sich eine Nachricht einen Tag in der ursprünglichen Warteschlange befindet, bevor sie in eine Warteschlange für unzustellbare Nachrichten verschoben wird. Wenn die Aufbewahrungsfrist der Warteschlange für unzustellbare Nachrichten 4 Tage beträgt, wird die Nachricht nach 3 Tagen aus der Warteschlange für unzustellbare Nachrichten gelöscht und das `ApproximateAgeOfOldestMessage` ist 3 Tage. Es hat sich daher bewährt, die Aufbewahrungsdauer einer Warteschlange für unzustellbare Nachrichten immer so festzulegen, dass sie länger ist als die Aufbewahrungsdauer der ursprünglichen Warteschlange.
Bei FIFO-Warteschlangen wird der Enqueue-Zeitstempel zurückgesetzt, wenn die Nachricht in eine Warteschlange für unzustellbare Nachrichten verschoben wird. Die `ApproximateAgeOfOldestMessage`-Metrik gibt an, wann die Nachricht in die Warteschlange für unzustellbare Nachrichten verschoben wird. Im obigen Beispiel wird die Nachricht nach 4 Tagen aus der Warteschlange für unzustellbare Nachrichten gelöscht und das `ApproximateAgeOfOldestMessage` ist 4 Tage.
# Deduplizierung und Gruppierung von Amazon SQS SQS-Nachrichten
Dieses Thema enthält bewährte Methoden zur Sicherstellung einer konsistenten Nachrichtenverarbeitung in Amazon SQS. Es erklärt, wie man Folgendes verwendet:
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html#API_SendMessage_RequestSyntax)um doppelte Nachrichten in FIFO-Warteschlangen zu verhindern.
+ [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)um die Reihenfolge der Nachrichten innerhalb verschiedener Nachrichtengruppen zu verwalten.
****Topics****
+ [Vermeidung inkonsistenter Nachrichtenverarbeitung in Amazon SQS](avoiding-inconsistent-message-processing.md)
+ [Verwenden der Nachrichtendeduplizierungs-ID](using-messagededuplicationid-property.md)
+ [Verwenden der Nachrichtengruppen-ID](using-messagegroupid-property.md)
+ [Verwenden der Empfangsanforderungsversuch-ID](using-receiverequestattemptid-request-parameter.md)
# Vermeidung inkonsistenter Nachrichtenverarbeitung in Amazon SQS
Da es sich bei Amazon SQS um ein verteiltes System handelt, ist es möglich, dass ein Konsument selbst dann keine Nachricht empfängt, wenn Amazon SQS die Nachricht als übermittelt markiert, während sie erfolgreich von einem [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)-API-Methodenaufruf zurückgegeben wird. In diesem Fall vermerkt Amazon SQS die Nachricht mindestens einmal als zugestellt, obwohl der Konsument sie nie erhalten hat. Da unter diesen Bedingungen keine zusätzlichen Versuche zur Zustellung von Nachrichten unternommen werden, empfehlen wir nicht, als Anzahl der maximalen Eingänge für eine [Warteschlange für unzustellbare Nachrichten](sqs-dead-letter-queues.md) „1“ einzustellen.
# Verwenden der Nachrichtendeduplizierungs-ID in Amazon SQS
[https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)ist ein Token, das nur in Amazon SQS FIFO-Warteschlangen verwendet wird, um eine doppelte Nachrichtenzustellung zu verhindern. Es stellt sicher, dass innerhalb eines 5-minütigen Deduplizierungsfensters nur eine Instanz einer Nachricht mit derselben Deduplizierungs-ID verarbeitet und zugestellt wird.
Wenn Amazon SQS bereits eine Nachricht mit einer bestimmten Deduplizierungs-ID akzeptiert hat, werden alle nachfolgenden Nachrichten mit derselben ID bestätigt, aber nicht an Verbraucher zugestellt.
**Anmerkung**
Amazon SQS verfolgt weiterhin die Deduplizierungs-ID, auch nachdem die Nachricht empfangen und gelöscht wurde.
**Topics**
+ [Wann muss eine Nachrichtendeduplizierungs-ID in Amazon SQS angegeben werden?](providing-message-deduplication-id.md)
+ [Aktivierung der Deduplizierung für ein Einzelprodukt-/Verbrauchersystem in Amazon SQS](single-producer-single-consumer.md)
+ [Wiederherstellungsszenarien bei Ausfällen in Amazon SQS](designing-for-outage-recovery-scenarios.md)
+ [Konfiguration von Sichtbarkeits-Timeouts in Amazon SQS](working-with-visibility-timeouts.md)
# Wann muss eine Nachrichtendeduplizierungs-ID in Amazon SQS angegeben werden?
In den folgenden Szenarien sollte ein Hersteller eine ID für die Nachrichtendeduplizierung angeben:
+ Beim Senden identischer Nachrichtentexte müssen diese als einzigartig behandelt werden.
+ Stellen Sie beim Senden von Nachrichten mit demselben Inhalt, aber unterschiedlichen Nachrichtenattributen sicher, dass jede Nachricht separat verarbeitet wird.
+ Wenn Nachrichten mit unterschiedlichem Inhalt gesendet werden (z. B. ein Wiederholungszähler im Nachrichtentext), Amazon SQS sie aber als Duplikate erkennen muss.
# Aktivierung der Deduplizierung für ein Einzelprodukt-/Verbrauchersystem in Amazon SQS
Wenn Sie nur einen Produzenten und einen einzigen Verbraucher haben und Nachrichten einzigartig sind, weil sie eine anwendungsspezifische Nachrichten-ID im Hauptteil enthalten, gehen Sie wie folgt vor:
+ Aktivieren Sie die inhaltsbasierte Deduplizierung für die Warteschlange (jede Ihrer Nachrichten hat einen eindeutigen Text). Der Produzent kann die Nachrichtendeduplizierungs-ID weglassen.
+ Wenn die inhaltsbasierte Deduplizierung für eine Amazon SQS FIFO-Warteschlange aktiviert ist und eine Nachricht mit einer Deduplizierungs-ID gesendet wird, überschreibt die Deduplizierungs-ID die generierte inhaltsbasierte [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)Deduplizierungs-ID.
+ Obwohl der Konsument keine Empfangsanforderungsversuch-ID für jede Anforderung angeben muss, hat sich dies als Methode bewährt, da Wiederholungen nach Fehlschlägen schneller durchgeführt werden können.
+ Sie können erneut versuchen, Anforderungen zu senden oder zu empfangen, da diese die Reihenfolge der Nachrichten in FIFO-Warteschlangen nicht stören.
# Wiederherstellungsszenarien bei Ausfällen in Amazon SQS
Der Deduplizierungsprozess in FIFO-Warteschlangen ist zeitkritisch. Achten Sie beim Entwerfen Ihrer Anwendung darauf, dass sowohl der Hersteller als auch der Endverbraucher nach Client- oder Netzwerkausfällen wieder fit sind, ohne dass es zu Duplikaten oder Verarbeitungsfehlern kommt.
Überlegungen des Herstellers
+ Amazon SQS erzwingt ein Deduplizierungsfenster von 5 Minuten.
+ Wenn ein Producer eine [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)Anfrage nach 5 Minuten erneut versucht, behandelt Amazon SQS sie als neue Nachricht, wodurch möglicherweise Duplikate erstellt werden.
Überlegungen für Verbraucher
+ Wenn ein Verbraucher eine Nachricht nicht verarbeitet, bevor das Sichtbarkeits-Timeout abgelaufen ist, kann es sein, dass ein anderer Verbraucher sie empfängt und verarbeitet, was zu einer doppelten Verarbeitung führt.
+ Passen Sie das Sichtbarkeits-Timeout an die Bearbeitungszeit Ihrer Anwendung an.
+ Verwenden Sie die [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ChangeMessageVisibility.html)API, um das Timeout zu verlängern, solange eine Nachricht noch verarbeitet wird.
+ Wenn eine Nachricht wiederholt nicht verarbeitet werden kann, leiten Sie sie an eine [Warteschlange mit unerlaubten Briefen (DLQ)](sqs-dead-letter-queues.md) weiter, anstatt sie auf unbestimmte Zeit erneut verarbeiten zu lassen.
+ Der Produzent muss das Deduplizierungsintervall der Warteschlange kennen. Amazon SQS verfügt über ein Deduplizierungsintervall von 5 Minuten. Wiederholungsversuche von `SendMessage`-Anforderungen nach Ablauf des Deduplizierungsintervalls können zu doppelten Nachrichten in der Warteschlange führen. Beispiel: Ein mobiles Gerät in einem Auto sendet Nachrichten, deren Reihenfolge wichtig ist. Wenn das Auto für einen bestimmten Zeitraum die Funkverbindung verliert, bevor eine Bestätigung eingeht, kann ein Wiederholungsversuch der Anforderungen nach Wiederherstellung der Funkverbindung zu einem Duplikat führen.
+ Der Konsument muss über eine Zeitbeschränkung für die Sichtbarkeit verfügen, die das Risiko minimiert, dass Nachrichten nicht verarbeitet werden können, bevor die Zeitbeschränkung für die Sichtbarkeit abgelaufen ist. Sie können die Zeitbeschränkung für die Sichtbarkeit erweitern, während die Nachrichten verarbeitet werden, indem Sie die Aktion `ChangeMessageVisibility` aufrufen. Wenn die Zeitbeschränkung für die Sichtbarkeit jedoch abgelaufen ist, kann ein anderer Konsument sofort mit der Nachrichtenverarbeitung beginnen, was dazu führt, dass eine Nachricht mehrfach verarbeitet wird. Um dieses Szenario zu vermeiden, konfigurieren Sie eine [Warteschlange für unzustellbare Nachrichten](sqs-dead-letter-queues.md).
# Konfiguration von Sichtbarkeits-Timeouts in Amazon SQS
Um eine zuverlässige Nachrichtenverarbeitung zu gewährleisten, legen Sie das Sichtbarkeits-Timeout so fest, dass es länger ist als das AWS SDK-Lese-Timeout. Dies gilt, wenn die [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)API sowohl für kurze als auch für lange Abfragen verwendet wird. Ein längeres Sichtbarkeits-Timeout verhindert, dass Nachrichten anderen Benutzern zur Verfügung stehen, bevor die ursprüngliche Anfrage abgeschlossen ist, wodurch das Risiko einer doppelten Verarbeitung verringert wird.
# Verwenden der Nachrichtengruppen-ID mit Amazon SQS FIFO Queues
In FIFO-Warteschlangen (First-In-First-Out) [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)ist dies ein Attribut, das Nachrichten in verschiedene Gruppen unterteilt. Nachrichten innerhalb derselben Nachrichtengruppe werden immer einzeln und in strikter Reihenfolge verarbeitet, sodass sichergestellt wird, dass keine zwei Nachrichten aus derselben Gruppe gleichzeitig verarbeitet werden. In Standardwarteschlangen `MessageGroupId` ermöglicht die Verwendung [fairer Warteschlangen](sqs-fair-queues.md). Wenn eine strikte Reihenfolge erforderlich ist, verwenden Sie eine FIFO-Warteschlange.
**Topics**
+ [Verschachteln mehrerer bestellter Nachrichtengruppen in Amazon SQS](interleaving-multiple-ordered-message-groups.md)
+ [Vermeidung doppelter Verarbeitung in einem System mit mehreren Herstellern/Verbrauchern in Amazon SQS](avoding-processing-duplicates-in-multiple-producer-consumer-system.md)
+ [Vermeiden Sie große Nachrichtenrückstände mit derselben Nachrichtengruppen-ID in Amazon SQS](avoid-backlog-with-the-same-message-group-id.md)
+ [Vermeiden Sie die Wiederverwendung derselben Nachrichtengruppen-ID mit virtuellen Warteschlangen in Amazon SQS](avoiding-reusing-message-group-id-with-virtual-queues.md)
# Verschachteln mehrerer bestellter Nachrichtengruppen in Amazon SQS
Um mehrere geordnete Nachrichtengruppen innerhalb einer einzigen FIFO-Warteschlange zu verschachteln, weisen Sie jeder Gruppe eine [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)zu (z. B. Sitzungsdaten für verschiedene Benutzer). Auf diese Weise können mehrere Benutzer gleichzeitig aus der Warteschlange lesen und gleichzeitig sicherstellen, dass Nachrichten innerhalb derselben Gruppe der Reihe nach verarbeitet werden.
Wenn eine Nachricht mit einer bestimmten `MessageGroupId` Nachricht verarbeitet wird und unsichtbar ist, kann kein anderer Verbraucher Nachrichten aus derselben Gruppe verarbeiten, bis das Sichtbarkeits-Timeout abgelaufen ist oder die Nachricht gelöscht wird.
# Vermeidung doppelter Verarbeitung in einem System mit mehreren Herstellern/Verbrauchern in Amazon SQS
In einem System mit hohem Durchsatz und niedriger Latenz, in dem die Reihenfolge der Nachrichten keine Priorität hat, können Produzenten jeder Nachricht eine eindeutige [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)Nummer zuweisen. Dadurch wird sichergestellt, dass Amazon SQS FIFO-Warteschlangen Duplikate eliminieren, selbst in einer Konfiguration mit mehreren Produzenten/mehreren Verbrauchern. Dieser Ansatz verhindert zwar doppelte Nachrichten, garantiert jedoch nicht die Reihenfolge der Nachrichten, da jede Nachricht als eigene unabhängige Gruppe behandelt wird.
In jedem System mit mehreren Herstellern und Verbrauchern besteht immer die Gefahr einer doppelten Zustellung. Wenn ein Verbraucher eine Nachricht nicht verarbeitet, bevor das Sichtbarkeits-Timeout abgelaufen ist, stellt Amazon SQS die Nachricht wieder zur Verfügung, sodass sie möglicherweise von einem anderen Verbraucher abgeholt werden kann. Um dies zu vermeiden, stellen Sie sicher, dass die Einstellungen für die Nachrichtenbestätigung und das Sichtbarkeits-Timeout auf der Grundlage der Verarbeitungszeit korrekt sind.
# Vermeiden Sie große Nachrichtenrückstände mit derselben Nachrichtengruppen-ID in Amazon SQS
FIFO-Warteschlangen unterstützen maximal 120.000 Nachrichten während der Übertragung (Nachrichten, die von einem Verbraucher empfangen, aber noch nicht gelöscht wurden). Wenn dieses Limit erreicht wird, gibt Amazon SQS keinen Fehler zurück, aber die Verarbeitung kann beeinträchtigt werden. Sie können eine Erhöhung über dieses Limit hinaus beantragen, indem Sie sich an den [AWS Support](https://docs.aws.amazon.com/awssupport/latest/user/create-service-quota-increase.html) wenden.
FIFO-Warteschlangen scannen die ersten 120.000 Nachrichten, um die verfügbaren Nachrichtengruppen zu ermitteln. Wenn sich in einer einzelnen Nachrichtengruppe ein großer Rückstand ansammelt, bleiben Nachrichten von anderen Gruppen, die später gesendet werden, blockiert, bis der Rückstand verarbeitet ist.
**Anmerkung**
Ein Nachrichtenrückstand kann entstehen, wenn ein Verbraucher eine Nachricht wiederholt nicht verarbeiten kann. Dies kann auf Probleme mit dem Nachrichteninhalt oder auf Fehler auf Kundenseite zurückzuführen sein. Um Verzögerungen bei der Nachrichtenverarbeitung zu vermeiden, konfigurieren Sie eine [Warteschlange für unzustellbare Nachrichten, sodass](sqs-dead-letter-queues.md) unverarbeitete Nachrichten nach mehreren fehlgeschlagenen Versuchen verschoben werden. Dadurch wird sichergestellt, dass andere Nachrichten in derselben Nachrichtengruppe verarbeitet werden können, wodurch Systemengpässe vermieden werden.
# Vermeiden Sie die Wiederverwendung derselben Nachrichtengruppen-ID mit virtuellen Warteschlangen in Amazon SQS
Wenn Sie virtuelle Warteschlangen mit einer gemeinsam genutzten Host-Warteschlange verwenden, vermeiden Sie es, dieselben [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SendMessage.html)in verschiedenen virtuellen Warteschlangen wiederzuverwenden. Wenn sich mehrere virtuelle Warteschlangen dieselbe Host-Warteschlange teilen und Nachrichten derselben enthalten, können sich diese Nachrichten gegenseitig blockieren`MessageGroupId`, wodurch eine effiziente Verarbeitung verhindert wird. Um eine reibungslose Nachrichtenverarbeitung zu gewährleisten, weisen Sie Nachrichten in verschiedenen virtuellen Warteschlangen eindeutige `MessageGroupId` Werte zu.
# Verwenden der Amazon-SQS-Empfangsanforderungsversuch-ID
Die ID des Versuchs einer Empfangsanforderung ist ein eindeutiges Token, das zur Deduplizierung von [https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)Aufrufen in Amazon SQS verwendet wird. Bei einem Netzwerkausfall oder Verbindungsproblem zwischen Ihrer Anwendung und Amazon SQS empfiehlt es sich, Folgendes zu tun:
+ Geben Sie bei einem Anruf eine ID für den Versuch, eine Empfangsanfrage zu erhalten, an`ReceiveMessage`.
+ Versuchen Sie es erneut mit derselben ID für den Versuch, eine Empfangsanfrage zu empfangen, falls der Vorgang fehlschlägt.
# Amazon SQS SQS-Nachrichtenverarbeitung und Timing
Dieses Thema bietet umfassende Anleitungen zur Optimierung der Geschwindigkeit und Effizienz der Nachrichtenverarbeitung in Amazon SQS, einschließlich Strategien für die zeitnahe Nachrichtenverarbeitung, die Auswahl des besten Abfragemodus und die Konfiguration langer Abfragen zur Verbesserung der Leistung.
****Topics****
+ [Rechtzeitige Verarbeitung von Nachrichten in Amazon SQS](best-practices-processing-messages-timely-manner.md)
+ [Einrichtung von Long Polling in Amazon SQS](best-practices-setting-up-long-polling.md)
+ [Verwenden des entsprechenden Abfragemodus in Amazon SQS](best-practices-using-appropriate-polling-mode.md)
# Rechtzeitige Verarbeitung von Nachrichten in Amazon SQS
Die Einstellung der Zeitbeschränkung für die Sichtbarkeit hängt davon ab, wie lange Ihre Anwendung braucht, um eine Nachricht zu verarbeiten und zu löschen. Benötigt Ihre Anwendung beispielsweise 10 Sekunden für die Verarbeitung einer Nachricht und Sie setzen die Zeitbeschränkung für die Sichtbarkeit auf 15 Minuten, müssen Sie relativ lange warten, bis Sie erneut versuchen können, die Nachricht zu verarbeiten, wenn der vorherige Versuch einer Verarbeitung fehlgeschlagen ist. Benötigt Ihre Anwendung alternativ 10 Sekunden für die Verarbeitung einer Nachricht, Sie setzen die Zeitbeschränkung für die Sichtbarkeit jedoch auf nur 2 Sekunden, wird eine duplizierte Nachricht von einem anderen Verbraucher empfangen, während der ursprüngliche Verbraucher die Nachricht noch verarbeitet.
Um sicherzustellen, dass ausreichend Zeit für die Verarbeitung von Nachrichten vorhanden ist, nutzen Sie eine der folgenden Strategien:
+ Wenn Sie wissen (oder annähernd schätzen können), wie lange die Verarbeitung einer Nachricht dauert, erweitern Sie die *Zeitbeschränkung für die Sichtbarkeit* auf die maximale Zeit, die erforderlich ist, um die Nachricht zu verarbeiten und zu löschen. Weitere Informationen finden Sie unter [Konfiguration der Sichtbarkeitszeitbeschränkung](sqs-visibility-timeout.md#configuring-visibility-timeout).
+ Wenn Sie nicht wissen, wie lange die Bearbeitung einer Nachricht dauert, erstellen Sie einen *Heartbeat* für Ihren Kundenprozess: Geben Sie das anfängliche Timeout für die Sichtbarkeit an (z. B. 2 Minuten) und verlängern Sie dann, solange Ihr Kunde noch an der Nachricht arbeitet, die Sichtbarkeitszeitbeschränkung jede Minute um 2 Minuten.
**Wichtig**
Die maximale Zeitbeschränkung für die Sichtbarkeit beträgt 12 Stunden ab dem Zeitpunkt, an dem Amazon SQS die `ReceiveMessage`-Anforderung empfängt. Durch die Verlängerung der Sichtbarkeitszeitbeschränkung wird das Maximum von 12 Stunden nicht zurückgesetzt.
Darüber hinaus können Sie das Timeout für eine einzelne Nachricht möglicherweise nicht auf die vollen 12 Stunden (z. B. 43 200 Sekunden) festlegen, seit die `ReceiveMessage`-Anfrage den Timer initiiert hat. Wenn Sie beispielsweise eine Nachricht erhalten und sofort das Maximum von 12 Stunden festlegen, indem Sie einen `ChangeMessageVisibility`-Aufruf mit einem `VisibilityTimeout` von 43 200 Sekunden senden, schlägt der Vorgang wahrscheinlich fehl. Die Verwendung eines Werts von 43 195 Sekunden funktioniert jedoch, sofern es nicht zu einer erheblichen Verzögerung zwischen dem Anfordern der Nachricht über `ReceiveMessage` und der Aktualisierung der Sichtbarkeitszeitbeschränkung kommt. Wenn Ihr Verbraucher länger als 12 Stunden benötigt, sollten Sie die Verwendung von Step Functions in Betracht ziehen.
# Einrichtung von Long Polling in Amazon SQS
Ist die Wartezeit für die `[ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html)`-API-Aktion größer als 0, ist eine *lange Abfrage* wirksam. Die maximale Wartezeit für lange Abfragen beträgt 20 Sekunden. Lange Abfragen tragen dazu bei, die Kosten für die Nutzung von Amazon SQS zu senken, indem die Anzahl der leeren Antworten (wenn für eine `ReceiveMessage` Anfrage keine Nachrichten verfügbar sind) und der falschen leeren Antworten (wenn Nachrichten verfügbar sind, aber nicht in einer Antwort enthalten sind) reduziert wird. Weitere Informationen finden Sie unter [Kurz- und Langabfragen in Amazon SQS](sqs-short-and-long-polling.md).
Um eine optimale Nachrichtenverarbeitung sicherzustellen, wenden Sie die folgenden Strategien an:
+ In den meisten Fällen können Sie die `ReceiveMessage`-Wartezeit auf 20 Sekunden setzen. Wenn 20 Sekunden für Ihre Anwendung zu lang ist, legen Sie eine kürzere `ReceiveMessage`-Wartezeit fest (mindestens 1 Sekunde). Wenn Sie kein AWS SDK für den Zugriff auf Amazon SQS verwenden oder wenn Sie ein AWS SDK für eine kürzere Wartezeit konfigurieren, müssen Sie Ihren Amazon SQS SQS-Client möglicherweise ändern, um entweder längere Anfragen zuzulassen oder eine kürzere Wartezeit für lange Abfragen zu verwenden.
+ Wenn Sie Langabfragen für mehrere Warteschlangen implementieren, verwenden Sie einen Thread für jede Warteschlange statt eines einzelnen Threads für alle Warteschlangen. Durch die Verwendung eines einzelnen Threads für jede Warteschlange kann Ihre Anwendung die Nachrichten in jeder der Warteschlangen verarbeiten, sobald diese verfügbar sind, während bei Verwendung eines einzelnen Threads für die Abfrage mehrerer Warteschlangen dazu führen könnte, dass Ihre Anwendung die Nachrichten nicht verarbeiten kann, die in anderen Warteschlangen zur Verfügung stehen, während die Anwendung auf die Warteschlange wartet (bis zu 20 Sekunden), die keine verfügbaren Nachrichten enthält.
**Wichtig**
Um HTTP-Fehler zu vermeiden, stellen Sie sicher, dass das HTTP-Reaktions-Timeout für `ReceiveMessage`-Anforderungen länger ist als der `WaitTimeSeconds`-Parameter. Weitere Informationen finden Sie unter [ReceiveMessage](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ReceiveMessage.html).
# Verwenden des entsprechenden Abfragemodus in Amazon SQS
+ Mit einer Langabfrage können Sie Nachrichten aus Ihrer Amazon-SQS-Warteschlange nutzen, sobald diese verfügbar sind.
+ Um die Verwendungskosten für Amazon SQS zu senken und die Anzahl der leeren Empfangsvorgänge in einer leeren Warteschlange zu reduzieren, (Antworten auf die `ReceiveMessage`-Aktion, mit der keine Nachrichten zurückgegeben werden), aktivieren Sie die Langabfrage. Weitere Informationen finden Sie unter [Amazon-SQS-Langabfragen](sqs-short-and-long-polling.md).
+ Um die Effizienz beim Abfragen für mehrere Threads mit mehreren Empfangsvorgängen zu steigern, verringern Sie die Anzahl der Threads.
+ Langabfragen sind Kurzabfragen in den meisten Fällen vorzuziehen.
+ Eine Kurzabfrage gibt Antworten sofort zurück, auch wenn die abgefragte Amazon-SQS-Warteschlange leer ist.
+ Um die Anforderungen einer Anwendung zu erfüllen, die sofortige Antworten auf die Abfrage `ReceiveMessage` erwartet, verwenden Sie die Kurzabfrage.
+ Die Kurzabfrage wird mit denselben Kosten in Rechnung gestellt wie die Langabfrage.