Im Allgemeinen ist es keine gute Idee, Aufgaben mit sehr langen ETAs zu haben.
Zunächst gibt es das Problem "Sichtbarkeitszeit". Und Sie möchten wahrscheinlich kein sehr großes Sichtbarkeits-Timeout, denn wenn der Worker 1 Minute vor der Ausführung der Aufgabe abstürzt, wartet die Queue immer noch darauf, dass die Sichtbarkeitszeit abgelaufen ist, bevor die Aufgabe an einen anderen Arbeiter gesendet wird das ist noch 1 Monat.
Von Sellerie docs:
Beachten Sie, dass Sellerie-Nachrichten an Arbeitnehmern Abschaltung zu wird, so hat ein Timeout lange Sicht wird die Nachlieferung von ‚verlorenen‘ Aufgaben im Fall eines Stromausfalls nur verzögern oder gewaltsam beendet Arbeiter.
Und auch, SQS erlaubt nur so viele Aufgaben in der Liste zu sein bestätigt werden.
SQS nennt diese Aufgaben "Inflight Messages". Von http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html:
wird eine Meldung im Flug zu sein betrachtet, nachdem er von einer Warteschlange von einem Verbraucher, aber noch nicht gelöscht aus der Warteschlange empfangen wird.
Für Standardwarteschlangen können maximal 120.000 Inflight-Nachrichten pro Warteschlange vorhanden sein. Wenn Sie dieses Limit erreichen, gibt Amazon SQS die OverLimit-Fehlermeldung zurück. Um zu vermeiden, dass das Limit erreicht wird, sollten Sie die Nachrichten aus der Warteschlange löschen, nachdem sie verarbeitet wurden. Sie können auch die Anzahl der Warteschlangen erhöhen, die Sie zum Verarbeiten Ihrer Nachrichten verwenden.
Für FIFO-Warteschlangen können maximal 20.000 Flugmeldungen pro Warteschlange vorhanden sein. Wenn Sie dieses Limit erreichen, gibt Amazon SQS keine Fehler Nachrichten zurück.
ich zwei mögliche Lösungen zu sehen, können Sie entweder RabbitMQ statt, die auf Sicht Timeouts verlassen tun (es „RabbitMQ als Service“ -Dienste ist, wenn Sie wollen nicht selbst verwalten) oder den Code ändern müssen wirklich kleine ETAs (best practice)
Das sind meine 2 Cent, vielleicht kann @asksol einige zusätzliche Einblicke liefern.
Meine vorherige Konfiguration war mit Sichtbarkeit Timeouts = 5 Minuten. Nach der Erstellung der Aufgabe wurde sie zur Ausführung in die Warteschlange hinzugefügt (sagen wir mit ETA innerhalb von 6 Stunden). Was als nächstes passierte, überraschte mich. In Protokollen sah ich, dass alle fünf Minuten eine neue Aufgabe zur Warteschlange auf dem Server hinzugefügt wird. Und ich vermute, dass alle gesammelten Aufgaben in 6 Stunden nacheinander ausgeführt werden. Aus diesem Grund habe ich mich entschieden, das Sichtbarkeits-Timeout zu erhöhen. Ja, wenn der Arbeiter abstürzt, kommt die redeliverd-Aufgabe zu spät, aber es gibt mindestens eine Aufgabe im Worker-Log und nicht 1000 von ihnen. Wenn ich nicht richtig denke, korrigiere mich bitte. –
Es wird erwartet, dass alle 5 Minuten eine neue Aufgabe angezeigt wird, da dies das Sichtbarkeits-Timeout ist. Das bedeutet, wenn der Sachbearbeiter die Ausführung dieser Aufgabe nicht innerhalb von 5 Minuten gestartet hat, ist SQS der Ansicht, dass der Sachbearbeiter diese Aufgabe verpasst hat, sodass SQS sie neu plant, um sie an einen anderen Sachbearbeiter zu senden. Das Erhöhen des Sichtbarkeitszeitlimits ist eine Lösung für dieses Problem, obwohl es auch eigene Kompromisse hat. – giorgosp
Hier habe ich zwei Fragen. Erstens, mit SQS habe ich keine andere Möglichkeit, die Warteschlange außer Protokoll zu steuern. Ich gehe also davon aus, dass alle Aufgaben, die im Queue-Protokoll aufgelistet sind, ausgeführt werden. Ist es wahr? Oder Sellery überprüft die ID der Aufgabe vor der Ausführung? Zweiter: Jetzt habe ich nur eine Warteschlange auf einem Server. Was passiert, wenn der SQS-Broker die gleiche Aufgabe an den Mitarbeiter auf einem anderen Server sendet? Wie denkst du, wird es zweimal ausgeführt? –