Ratenbegrenzung Anfragen und Amazon SQS

Question

Ich habe eine Frage darüber, wie ich meine API-Anfragen verlangsamen. Für eine bestimmte Drittanbieter-API, die ich treffe, kann ich alle 2 Sekunden 3 Anfragen stellen. Wenn ich über diese Nummer gehe, werde ich status code 429 zusammen mit einer Wartezeit in Millisekunden zurückgegeben.

Diese API wird oft aufgerufen und ist ein direktes Ergebnis meines eigenen Servers mit eingehenden Anfragen, die nicht Rate-begrenzt sind.

Da ich keine synchrone Behandlung der API-Anfragen von Drittanbietern benötige, entschied ich mich, die Arbeit auf meine EFS-Worker-Box in AWS zu verlagern, die standardmäßig von Amazon SQS liest.

Als Ergebnis wird mein Worker die SQS-Nachricht in die Warteschlange zurückwerfen, wenn ein Statuscode 429 von der API der dritten Partei zurückgegeben wird. Dies führt unweigerlich dazu, dass der API-Anruf funktioniert, wenn die Wartezeit erreicht ist. Dies scheint jedoch eine schlechte Lösung zu sein

Gibt es eine Möglichkeit, den Dämon in der Worker-Box zu sagen, die Nachricht in der Warteschlange für die zugewiesene Wartezeit zu verlassen? Oder kann ich vielleicht die Rate einstellen, mit der der Daemon aus der Warteschlange liest? Ich suche nach einem geeigneten Weg (implementierungsspezifisch), um das Limit mit dem Arbeiter und der Warteschlange auf AWS zu begrenzen. Vielen Dank für die Hilfe!

EDIT: Ich hätte angenommen, dass es Konfigurationen gibt, die auf AWS geändert werden könnten, um das zu tun, was ich frage, aber auf jede Art suche ich nach spezifischen Lösungen für das Setup, das ich beschrieben habe. Ich bin mir nicht ganz sicher, wie man den Daemon auf der Box mit den elastischen Bohnenranken verändert oder kontrolliert.

Answer 1

Wie ich verstehe, haben Sie viele Auslöser für das Anrufen eines Drittanbieterdienstes und Sie müssen Ihre API-Aufrufe begrenzen.

Der beste Weg besteht darin, den Daemon, der von SQS liest, mit einer Rate zu begrenzen. Abhängig von der Sprache, in der der Daemon geschrieben ist, sollten Sie in der Lage sein, Ratenbegrenzer-Bibliotheken zu finden, die Sie wiederverwenden können. Zum Beispiel haben Java und Python gut getestete Bibliotheken here bzw. here.

Beachten Sie, dass diese Bibliotheken X-Anfragen pro Sekunde pro Worker zulassen. Wenn Sie einen Daemon ausführen, ist X für Ihren Anwendungsfall 1,5. Wenn Sie zwei Daemons haben (z. B. je einen auf zwei verschiedenen Rechnern), sollte X 0,75 sein.

Answer 2

Es hört sich an, als ob Sie eine Nachricht aus der SQS-Warteschlange abholen und während der Verarbeitung dieser Nachricht feststellen, dass Sie nicht in der Lage sind um die Verarbeitung jetzt abzuschließen und nach einer bekannten Zeit in der Zukunft einen erneuten Versuch zu verschieben.

Wenn das der Fall ist, dann möchten Sie wahrscheinlich changing the message visibility Zeit betrachten.

Wenn Sie eine Nachricht aus einer Warteschlange lesen, wird sie nicht automatisch gelöscht. Stattdessen wird es automatisch wieder verfügbar gemacht, wenn Sie die Nachricht nicht innerhalb des Sichtbarkeits-Timeouts löschen. Die Idee besteht darin, sicherzustellen, dass alle Nachrichten wiederholt werden, bis sie gelöscht werden, aber nicht erneut versuchen, bevor der Verbraucher die Möglichkeit hat, die Nachricht zu verarbeiten und zu löschen. Die Warteschlange verfügt über ein standardmäßiges Sichtbarkeits-Timeout, das Sie für jede Nachricht überschreiben können.

Beachten Sie, dass dieser Ansatz nur dazu führt, dass Sie die bestimmte Nachricht aus der Warteschlange vor dem Timeout nicht erhalten. Wenn der Clientprozess weiterhin versucht, Nachrichten zu lesen, erhält er in der Zwischenzeit weitere Nachrichten. Dies ist wahrscheinlich das, was Sie möchten, wenn verschiedene Ratenbeschränkungen für verschiedene Nachrichten gelten. Wenn dies nicht der Fall ist, möchten Sie möglicherweise Ihre Client-Threads deaktivieren, bis die Rate-Limit-Wartezeit erreicht ist.Die Details dazu, wie mehrere Threads über mehrere Server verteilt werden, bis sie zu einem bestimmten Zeitpunkt nicht mehr funktionieren, beziehen sich nicht auf AWS und sind stark von der verwendeten Sprache abhängig. Wenn Sie sich für diesen Weg entscheiden, sollten Sie wahrscheinlich eine separate Frage stellen.