Ich werde die Rails-Anwendung erstellen, die die Cloud-Dienste von Amazon integriert.
Ich möchte wissen, was der mögliche Ansatz ist.
SQS klingt wie du willst.
Sie können mehrere "Worker" -Prozesse ausführen, die über Nachrichten in der Warteschlange konkurrieren. Jede Nachricht wird nur einmal verbraucht. Die Logik hinter der "Sperre" / Zeitüberschreitung, die Sie erwähnen, lautet wie folgt: Wenn einer Ihrer Mitarbeiter nach dem Herunterladen einer Nachricht, aber vor der Verarbeitung, sterben würde, möchten Sie, dass die Nachricht schließlich ausläuft und erneut zur Verarbeitung heruntergeladen wird auf einem anderen Knoten.
Ja, SQS basiert auf einem Abfragemodell. Zum Beispiel habe ich eine Reihe von Anwendungsfällen, in denen ich einen winzigen Cron-Job verwende, um nach neuen Nachrichten in der Warteschlange zu suchen und Maßnahmen für gefundene Nachrichten zu ergreifen. Dieses Muster ist dumm einfach zu erstellen und funktioniert Wunder für eine Reihe von Use Cases - ein praktisches kleines "Client" -Skript, das eine Nachricht in die Warteschlange schiebt, und das Cron-aktivierte Skript, das diese Nachricht innerhalb einer Minute oder so verarbeiten wird / p>
Wenn Ihr Nachrichtenmuster extrem spärlich ist - z. B. nur wenige Nachrichten pro Tag -, kann es unwirtschaftlich erscheinen, ständig abzufragen, solange die Warteschlange leer ist. Es spielt kaum eine Rolle.
Meine ursprüngliche Berechnung war, dass ein minutiöser Cron Job 0,04 $ (jetzt 0,02 $) pro Monat kosten würde. Seitdem hat SQS eine "Long-Polling" -Funktion hinzugefügt, mit der Sie bei der Verarbeitung neuer Nachrichten eine Latenz von weniger als einer Sekunde erreichen können, indem Sie alle 20 Sekunden eine "Long-Poll" -Meldung senden, um eine Warteschlange im Leerlauf abzurufen. Außerdem haben sie den Preis um 50% gesenkt. Also pro Monat sind das 131k Nachrichten (~ 0,06 $), ein bisschen teurer, aber mit fast Echtzeit-Anfrageverarbeitung.
Beachten Sie, dass ein winziger Cron-Job, den ich beschrieben habe, nur etwa 0,04 $ / Monat für die Anfrage (30d * 24h * 60m * 1c / 10k msg) kostet. Also, bei einem winzigen Clip sollten die Kosten hier eigentlich keine Rolle spielen. Selbst wenn jede Sekunde abgefragt wird, steigt der Preis nur auf 2,59 $ / Monat, nicht gerade ein Bankbuster.
Es ist jedoch möglich, häufiges Abfragen mit einem Webservice zu vermeiden, der eine SNS-HTTP-Nachricht entgegennimmt. Eine solche Architektur würde folgendermaßen funktionieren: Der Client sendet eine Nachricht an SNS, die die Nachricht an SQS sendet und eine HTTP-Anforderung an Ihren Webservice weiterleitet, wodurch die Warteschlange ausgeleert wird. Sie möchten dennoch die Warteschlange stündlich oder täglich abfragen, nur für den Fall, dass eine HTTP-Anfrage gelöscht wurde. Am Ende bin ich mir jedoch nicht sicher, ob mir irgendein Szenario einfällt, das diese Komplexität wirklich rechtfertigt. Ich würde lieber $ 0,04 pro Monat bezahlen, um einen schmutzigen Cron-Job zu haben, der meine Warteschlange abfragt.
Tags und Links ruby-on-rails amazon-web-services amazon-sns amazon-sqs