Was ist der Unterschied zwischen Amazon SNS und Amazon SQS?


438

Ich verstehe nicht, wann ich SNS im Vergleich zu SQS verwenden würde, und warum sind sie immer miteinander gekoppelt?


Was ich aus Ihrem Kommentar verstehe, wird im folgenden Ablauf beschrieben. Ist es richtig? Publisher -> SNS -> SQL (Nachrichten in der Warteschlange halten) -> Abonnent (derzeit offline)
friendyogi


@friendyogi meinst du SQS und nicht SQL?
Elena

Antworten:


624

SNS ist ein verteiltes Publish-Subscribe- System. Die Nachrichten werden gedrückt , um Abonnenten , wie und wann sie von den Verlegern an SNS gesendet werden.

SQS ist ein verteiltes Warteschlangensystem . Nachrichten werden NICHT an Empfänger gesendet. Empfänger müssen Nachrichten von SQS abrufen oder abrufen . Nachrichten können nicht von mehreren Empfängern gleichzeitig empfangen werden. Jeder Empfänger kann eine Nachricht empfangen, verarbeiten und löschen. Andere Empfänger erhalten später nicht dieselbe Nachricht. Das Abrufen führt in SQS zu einer gewissen Latenz bei der Nachrichtenübermittlung, im Gegensatz zu SNS, bei dem Nachrichten sofort an Abonnenten weitergeleitet werden. SNS unterstützt mehrere Endpunkte wie E-Mail, SMS, http-Endpunkt und SQS. Wenn Sie möchten, dass unbekannte Anzahl und Art von Abonnenten Nachrichten empfangen, benötigen Sie SNS.

Sie müssen SNS und SQS nicht immer koppeln. Sie können SNS veranlassen, Nachrichten an E-Mail, SMS oder http-Endpunkt zu senden, abgesehen von SQS. Die Kopplung von SNS mit SQS bietet Vorteile. Möglicherweise möchten Sie nicht, dass ein externer Dienst Verbindungen zu Ihren Hosts herstellt (die Firewall blockiert möglicherweise alle eingehenden Verbindungen zu Ihrem Host von außen). Ihr Endpunkt stirbt möglicherweise nur aufgrund der großen Anzahl von Nachrichten. E-Mail und SMS sind möglicherweise nicht Ihre Wahl, um Nachrichten schnell zu verarbeiten. Durch die Kopplung von SNS mit SQS können Sie Nachrichten in Ihrem Tempo empfangen. Es ermöglicht Clients, offline zu sein und Netzwerk- und Hostfehler zu tolerieren. Sie erreichen auch eine garantierte Lieferung. Wenn Sie SNS so konfigurieren, dass Nachrichten an einen http-Endpunkt oder eine E-Mail oder eine SMS gesendet werden, können mehrere Fehler beim Senden von Nachrichten dazu führen, dass Nachrichten gelöscht werden.

SQS wird hauptsächlich zum Entkoppeln von Anwendungen oder zum Integrieren von Anwendungen verwendet. Nachrichten können für kurze Zeit (max. 14 Tage) in SQS gespeichert werden. SNS verteilt mehrere Kopien der Nachricht an mehrere Abonnenten. Angenommen, Sie möchten von einer Anwendung generierte Daten auf mehrere Speichersysteme replizieren. Sie können SNS verwenden und diese Daten an mehrere Abonnenten senden, wobei jeder die empfangenen Nachrichten an verschiedene Speichersysteme (s3, Festplatte auf Ihrem Host, Datenbank usw.) repliziert.


3
Um so etwas wie Push-Benachrichtigungsnachrichten zu implementieren, wird grundsätzlich empfohlen, SNS und SQS zu verwenden, damit die Pushs mit sns in die Warteschlange gestellt werden, bis der Benutzer sie nur noch aus der Warteschlange abrufen soll. Ist es möglich, eine Warteschlange pro Benutzer zu erstellen?
Nick Ginanto

2
Ja. Sie können so viele Abonnenten für SNS haben, wie Sie möchten. Sie können Benachrichtigungen an mehrere Warteschlangen senden lassen.
Srikanth

Hallo, sorry, ich sehe, dass diese Frage alt ist, aber ich frage mich, ob SQS Offline-Nachrichten kennt und speichert. Da APNS keine Offline-Nachrichten speichert, nur die neueste Nachricht. Würde es wissen, wann die IOS-Geräte offline sind und die Offline-Nachrichten sofort speichern? Und später versenden, wenn die Geräte wieder online sind?
John

2
@ NickGinanto Warteschlange pro Benutzer ist wahrscheinlich nicht das, was Sie wollen. Sie möchten wahrscheinlich eine Warteschlange für jeden Dienst, der dann benutzerspezifische Nachrichten verarbeitet. Dieses Diagramm kann helfen: aws.amazon.com/blogs/aws/…
Trenton

2
Es sollte wahrscheinlich beachtet werden, dass SQS ab Mitte 2018 Lambdas auslösen kann und daher in diesem Fall eher einem Pubsub ähnelt.
Cyberwombat

238

Hier ist ein Vergleich der beiden:

Entitätstyp

  • SQS: Queue (ähnlich wie JMS)
  • SNS: Thema (Pub / Sub-System)

Nachrichtenverbrauch

  • SQS: Pull-Mechanismus - Verbraucher rufen Nachrichten von SQS ab und ziehen sie ab
  • SNS: Push-Mechanismus - SNS sendet Nachrichten an Verbraucher

Anwendungsfall

  • SQS: 2 Anwendungen entkoppeln und parallele asynchrone Verarbeitung ermöglichen
  • SNS: Fanout - Verarbeitung derselben Nachricht auf verschiedene Arten

Beharrlichkeit

  • SQS: Nachrichten bleiben für eine gewisse (konfigurierbare) Dauer erhalten, wenn kein Verbraucher verfügbar ist
  • SNS: Keine Persistenz. Welcher Verbraucher zum Zeitpunkt des Eintreffens der Nachricht anwesend ist, erhält die Nachricht und die Nachricht wird gelöscht. Wenn keine Verbraucher verfügbar sind, geht die Nachricht verloren.

Verbrauchertyp

  • SQS: Alle Verbraucher sollen identisch sein und daher die Nachrichten genauso verarbeiten
  • SNS: Die Verbraucher können die Nachrichten auf unterschiedliche Weise verarbeiten

Beispielanwendungen

  • SQS: Jobs Framework: Die Jobs werden an SQS gesendet und die Verbraucher am anderen Ende können die Jobs asynchron verarbeiten. Wenn die Auftragshäufigkeit zunimmt, kann die Anzahl der Verbraucher einfach erhöht werden, um einen besseren Durchsatz zu erzielen.
  • SNS: Bildverarbeitung. Wenn jemand ein Bild in S3 hochlädt, setzen Sie ein Wasserzeichen auf dieses Bild, erstellen Sie eine Miniaturansicht und senden Sie eine Dankes-E-Mail. In diesem Fall kann S3 Benachrichtigungen zu einem SNS-Thema veröffentlichen, wobei 3 Verbraucher darauf hören. Das erste Wasserzeichen markiert das Bild, das zweite erstellt ein Miniaturbild und das dritte sendet eine Dankes-E-Mail. Alle von ihnen erhalten dieselbe Nachricht (Bild-URL) und verarbeiten sie parallel.

1
Wenn keine Verbraucher verfügbar sind, gibt es einen Wiederholungsmechanismus. Selbst der Standardwert ist 10 Wiederholungsversuche.
Arpit Solanki

Schöner ausführlicher Beitrag. Wir haben unterschiedliche Nachrichten für unterschiedliche Verbraucher - Was sollen wir tun - SNS verwenden und unterschiedliche Themen definieren oder SQS verwenden und unterschiedliche Warteschlangen definieren? Ein Thema / eine Warteschlange kann jedoch einen oder mehrere Verbraucher haben.
Andy Dufresne

Wenn Ihre Anforderung ist, dass Ihr Tooic / Ihre Warteschlange mehr als einen Verbraucher haben soll, gehen Sie vermutlich davon aus, dass dieselbe Nachricht an mehrere Verbraucher gesendet werden soll ... Und wenn meine Annahme richtig ist, ist die Verwendung von SNS die einzige verfügbare Option Sie
Arafat Nalkhande

Ich denke nicht, dass "SQS: Alle Verbraucher sollen identisch sein und daher die Nachrichten genauso verarbeiten", das ist richtig. Ich habe SQS verwendet, bei dem zwei verschiedene AWS-Services aus der SQS-Warteschlange abgerufen und die Nachricht auf ihre eigene Weise verarbeitet werden (unterschiedliche Anwendungslogik in diesen verschiedenen Services). Vermisse ich etwas
nad

@nad Ich muss Ihren Anwendungsfall verstehen, aber für mich macht es keinen Sinn, dass 2 SQS-Konsumenten Nachrichten auf nicht identische Weise verarbeiten.
Dies

31

Aus aws doc:

Mit Amazon SNS können Anwendungen zeitkritische Nachrichten über einen Push-Mechanismus an mehrere Abonnenten senden, sodass keine regelmäßigen Überprüfungen oder Abfragen nach Updates erforderlich sind.

Amazon SQS ist ein Nachrichtenwarteschlangendienst, der von verteilten Anwendungen zum Austausch von Nachrichten über ein Abfragemodell verwendet wird. Er kann zum Entkoppeln von sendenden und empfangenden Komponenten verwendet werden, ohne dass jede Komponente gleichzeitig verfügbar sein muss.

http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html


29

AWS SNS ist ein Publisher-Abonnentennetzwerk, in dem Abonnenten Themen abonnieren können und Nachrichten erhalten, wenn ein Publisher dieses Thema veröffentlicht.

AWS SQS ist ein Warteschlangendienst, der Nachrichten in einer Warteschlange speichert. SQS kann keine Nachrichten übermitteln, für die ein externer Dienst (Lambda, EC2 usw.) erforderlich ist, um SQS abzufragen und Nachrichten von SQS abzurufen.

SNS und SQS können aus mehreren Gründen zusammen verwendet werden.

  1. Es kann verschiedene Arten von Abonnenten geben, bei denen einige die sofortige Zustellung von Nachrichten benötigen, bei anderen die Beibehaltung der Nachricht für die spätere Verwendung durch Abfrage. Siehe diesen Link .

  2. Das " Fanout-Muster ". Dies ist für die asynchrone Verarbeitung von Nachrichten. Wenn eine Nachricht in SNS veröffentlicht wird, kann sie parallel an mehrere SQS-Warteschlangen verteilt werden. Dies kann hilfreich sein, wenn Miniaturansichten parallel in eine Anwendung geladen werden, wenn Bilder veröffentlicht werden. Siehe diesen Link .

  3. Dauerhafte Speicherung . Wenn ein Dienst, der eine Nachricht verarbeitet, nicht zuverlässig ist. In einem solchen Fall geht die Benachrichtigung verloren, wenn SNS eine Benachrichtigung an einen Dienst sendet und dieser Dienst nicht verfügbar ist. Daher können wir SQS als persistenten Speicher verwenden und anschließend verarbeiten.


29

Die Antworten in diesem Thread sind etwas veraltet, daher habe ich beschlossen, meine zwei Cent hinzuzufügen:

Sie können SNS als traditionelles Thema betrachten, für das Sie mehrere Abonnenten haben können. Sie können heterogene Abonnenten für ein bestimmtes SNS-Thema haben, einschließlich Lambda und SQS. Sie können mit SNS auch sofort SMS-Nachrichten oder sogar E-Mails senden. In SNS ist zu beachten, dass nur eine Nachricht (Benachrichtigung) gleichzeitig empfangen wird, sodass Sie die Stapelverarbeitung nicht nutzen können.

SQS hingegen ist nichts anderes als eine Warteschlange, in der Sie Nachrichten speichern und einen Verbraucher abonnieren (ja, Sie können N Verbraucher in einer SQS-Warteschlange haben, aber es würde sehr schnell chaotisch und viel schwieriger zu verwalten sein, wenn man bedenkt, dass alle Verbraucher dies tun würden Sie müssen die Nachricht mindestens einmal lesen, daher ist SNS in Kombination mit SQS für diesen Anwendungsfall besser geeignet, wenn SNS Benachrichtigungen an N SQS-Warteschlangen sendet und jede Warteschlange nur einen Teilnehmer hat, um diese Nachrichten zu verarbeiten. Ab dem 28. Juni 2018 unterstützt AWS Lambda-Trigger für SQS , sodass Sie keine Abfragen durchführen müssenfür Nachrichten mehr. Darüber hinaus können Sie einen DLQ in Ihrer Quell-SQS-Warteschlange konfigurieren, an den im Fehlerfall Nachrichten gesendet werden sollen. Im Erfolgsfall werden Nachrichten automatisch gelöscht (dies ist eine weitere große Verbesserung), sodass Sie sich keine Sorgen machen müssen, dass die bereits verarbeiteten Nachrichten erneut gelesen werden, falls Sie vergessen haben, sie manuell zu löschen. Ich schlage vor, einen Blick auf das Lambda-Wiederholungsverhalten zu werfenum besser zu verstehen, wie es funktioniert. Ein großer Vorteil der Verwendung von SQS besteht darin, dass die Stapelverarbeitung ermöglicht wird. Jeder Stapel kann bis zu 10 Nachrichten enthalten. Wenn also 100 Nachrichten gleichzeitig in Ihrer SQS-Warteschlange eintreffen, werden 10 Lambda-Funktionen gestartet (unter Berücksichtigung des standardmäßigen automatischen Skalierungsverhaltens für Lambda) und diese 100 Nachrichten verarbeitet (behalten Sie bei) Beachten Sie, dass dies der glückliche Weg ist, da in der Praxis einige weitere Lambda-Funktionen möglicherweise weniger als die 10 Nachrichten im Stapel lesen, aber Sie haben die Idee). Wenn Sie dieselben 100 Nachrichten an SNS senden, werden jedoch 100 Lambda-Funktionen gestartet, was die Kosten unnötig erhöht und Ihre Lambda-Parallelität verbraucht. Wenn Sie jedoch weiterhin herkömmliche Server (wie EC2-Instanzen) ausführen, müssen Sie weiterhin nach Nachrichten suchen und diese manuell verwalten.

Sie haben auch FIFO SQS-Warteschlangen , die die Zustellreihenfolge der Nachrichten garantieren. Dies ist kein von Lambda unterstützter Auslöser. Beachten Sie daher bei der Auswahl dieses Warteschlangentyps, dass weiterhin Abfragen erforderlich sind und die Nachrichten manuell gelöscht werden müssen.

Obwohl es in ihren Anwendungsfällen einige Überschneidungen gibt, haben sowohl SQS als auch SNS ihr eigenes Rampenlicht.

Verwenden Sie SNS, wenn:

  • Mehrere Teilnehmer sind Voraussetzung
  • Das sofortige Versenden von SMS / E-Mails ist praktisch

Verwenden Sie SQS, wenn:

  • Es wird nur ein Teilnehmer benötigt
  • Dosierung ist wichtig

4

In einfachen Worten, SNS - sendet Nachrichten per Push-Mechanismus an den Teilnehmer, ohne dass ein Pull erforderlich ist. SQS - Dies ist ein Nachrichtenwarteschlangendienst, der von verteilten Anwendungen zum Austausch von Nachrichten über ein Abfragemodell verwendet wird und zum Entkoppeln von sendenden und empfangenden Komponenten verwendet werden kann.

Ein gängiges Muster ist die Verwendung von SNS zum Veröffentlichen von Nachrichten in Amazon SQS-Warteschlangen, um Nachrichten zuverlässig asynchron an eine oder mehrere Systemkomponenten zu senden. Referenz von https://aws.amazon.com/sns/faqs/


SQS kann keine Nachricht an viele Systeme senden , da die Nachrichten nicht ausgeblendet werden. Ja, viele Poller können Nachrichten daraus abrufen. Wenn jedoch einer der Verbraucher die Nachricht löscht, können andere Abonnenten dieselbe Nachricht nicht mehr verwenden. SNS wird gegenüber SQS bevorzugt, wenn Sie ein Fan-Out-Muster erzielen möchten. Wenn das festgelegt visibilityTimeoutist, kann kein anderes System die Nachricht verarbeiten, sobald sie von einem anderen System verarbeitet wird.
Thales Minussi

Ein gängiges Muster ist die Verwendung von SNS zum Veröffentlichen von Nachrichten in Amazon SQS-Warteschlangen, um Nachrichten zuverlässig asynchron an eine oder mehrere Systemkomponenten zu senden. Referenz von aws.amazon.com/sns/faqs
Krunal Barot

Wenn Sie das gemeint haben (SNS -> mehrere SQS-Warteschlangen), bearbeiten Sie bitte Ihre Antwort und ich werde meine Ablehnung gerne entfernen. So wie Sie es ausdrücken, klingt es so, als ob SQS auffächern kann.
Thales Minussi

1
Ja ... da war die Verwirrung. Ich habe es bearbeitet .. Danke :)
Krunal Barot
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.