Die API-Referenz doumentation widerspricht sich tatsächlich selbst on the same page darüber.
DeleteMessage
Löscht die angegebene Nachricht aus der Warteschlange angegeben. Sie geben die Nachricht an, indem Sie den Empfangsbeleg der Nachricht verwenden und nicht die , die Sie erhalten, wenn Sie die Nachricht senden.
Auch wenn die Nachricht aufgrund der Einstellung für die Sichtbarkeitszeitlimitüberschreitung von einem anderen Lesegerät gesperrt wurde, wird sie dennoch aus der Warteschlange gelöscht.
Dies scheint einfach genug, bis Sie weiterlesen.
Hinweis
Der Empfang Griff ist mit einer bestimmten Instanz des Empfangens der Nachricht zugeordnet ist. Wenn Sie eine Nachricht mehr als einmal erhalten, unterscheidet sich die Empfangsbestätigung, die Sie jedes Mal erhalten, wenn Sie die Nachricht erhalten. Wenn Sie bei der Verwendung der Aktion DeleteMessage nicht die zuletzt empfangene Empfangskennung für die Nachricht bereitstellen, ist die Anforderung erfolgreich, die Nachricht wird jedoch möglicherweise nicht gelöscht.
Also, die Antwort auf Ihre Frage ist "Ja, absolut, außer Nein, nicht unbedingt."
Aber es erklärt, warum Sie stille Fehler haben sollten - Löschen scheint anscheinend nicht fehl, wenn die Anfrage gültig ist.
Dies ist wahrscheinlich ein grundlegendes Artefakt der verteilten Natur von SQS - wenn der bestimmte Knoten in SQS, der die Nachricht lieferte, fehlschlagen sollte, könnte es sein, dass ältere Nachrichtenquittungen verloren gehen könnten. Ich spekuliere natürlich.
Grundsätzlich scheinen Sie jedoch einen Designfehler zu haben, wenn dies eine Situation ist, der Sie begegnen.Entweder senden Sie eine nachfolgende Anforderung, um das Sichtbarkeits-Timeout zu erhöhen, oder Sie setzen das standardmäßige Sichtbarkeits-Timeout so hoch, dass es unter normalen Bedingungen nicht mehr auftritt. Der maximale Wert beträgt 12 Stunden, was für die meisten Anwendungsfälle viel zu lang ist.
Ihr Verbraucher benötigt auch eine Möglichkeit, zu überprüfen, ob die Nachricht bereits bearbeitet wurde.
Stellen Sie sich das Sichtbarkeits-Timeout als Wiederholungstimer vor.
Ein Beispiel aus meiner Infrastruktur ist ein System, das auf eine Datei reagiert, die in S3 in einen temporären Staging-Bucket abgelegt wird. Der Warteschlangenbenutzer sucht die Datei nach und führt einige Datenbankabfragen durch, um zu bestimmen, welches System oder welche Systeme diese Datei wünschen. Anschließend kopiert es die Datei in die Zielsystem-Buckets und kann je nach Regel Datenbankeinträge erstellen und/oder eine Nachricht an eine andere Warteschlange zur Verarbeitung dieser Datei senden. Dies geschieht normalerweise in wenigen Sekunden, und wenn alles gut geht, wird die Nachricht aus der Warteschlange gelöscht. Wenn etwas schief geht, vergisst es einfach die Nachricht und geht zurück zum Abrufen der Warteschlange.
Das standardmäßige Sichtbarkeits-Timeout für diese Warteschlange ist auf 5 Minuten festgelegt. Dies ist viel länger als normalerweise erforderlich, da die Nachricht so bald erneut versucht werden soll, wenn die Verarbeitung fehlschlägt. So möchten Sie das Sichtbarkeits-Timeout verwenden.
Beachten Sie, dass der Normalmodus unter Standardverarbeitungsbedingungen niemals 5 Minuten benötigt.
Nach 5 Wiederholungen entfernt SQS die Nachricht aus der Hauptwarteschlange und löscht die Nachricht stattdessen in eine Warteschlange für unzustellbare Nachrichten (Sie können die Nummer wählen, meine Einstellung ist 5). Diese Warteschlange wird von einem separaten Prozess beansprucht, der die Nachricht speichert und mich darauf aufmerksam macht, dass diese Nachricht die erlaubte Anzahl an empfangenen Nachrichten überschritten hat und nie gelöscht wurde - entweder als Giftpille oder als unbehandelter Fehler chronische Versagensbedingung.