Quelle est la différence entre Amazon SNS et Amazon SQS?


439

Je ne comprends pas quand j'utiliserais SNS contre SQS, et pourquoi sont-ils toujours couplés ensemble?


Ce que je comprends de votre commentaire est décrit dans le flux suivant .. est-ce correct? Éditeur -> SNS -> SQL (contenant des messages dans la file d'attente) -> Abonné (actuellement hors ligne)
friendyogi


@friendyogi tu veux dire SQS et pas SQL?
elena

Réponses:


626

SNS est un système de publication-abonnement distribué. Les messages sont poussés aux abonnés et quand ils sont envoyés par les éditeurs à SNS.

SQS est un système de mise en file d'attente distribué . Les messages ne sont PAS transmis aux récepteurs. Les récepteurs doivent interroger ou extraire des messages de SQS . Les messages ne peuvent pas être reçus par plusieurs destinataires en même temps. Tout destinataire peut recevoir un message, le traiter et le supprimer. D'autres récepteurs ne recevront pas le même message ultérieurement. L'interrogation introduit de manière inhérente une certaine latence dans la remise des messages dans SQS contrairement à SNS où les messages sont immédiatement envoyés aux abonnés. SNS prend en charge plusieurs points de terminaison tels que le courrier électronique, les sms, le point de terminaison http et SQS. Si vous voulez qu'un nombre et un type d'abonnés inconnus reçoivent des messages, vous avez besoin de SNS.

Vous n'avez pas toujours besoin de coupler SNS et SQS. Vous pouvez demander à SNS d'envoyer des messages par e-mail, sms ou point final http en dehors de SQS. Il y a des avantages à coupler SNS avec SQS. Il se peut que vous ne souhaitiez pas qu'un service externe établisse des connexions avec vos hôtes (le pare-feu peut bloquer toutes les connexions entrantes avec votre hôte de l'extérieur). Votre point final peut juste mourir à cause du volume important de messages. L'email et le SMS ne sont peut-être pas votre choix de traitement rapide des messages. En couplant SNS avec SQS, vous pouvez recevoir des messages à votre rythme. Il permet aux clients d'être hors ligne, tolérants aux pannes de réseau et d'hôte. Vous obtenez également une livraison garantie. Si vous configurez SNS pour envoyer des messages vers un point de terminaison http ou un e-mail ou SMS, plusieurs échecs d'envoi de message peuvent entraîner la suppression du message.

SQS est principalement utilisé pour découpler des applications ou intégrer des applications. Les messages peuvent être stockés dans SQS pour une courte durée (max 14 jours). SNS distribue plusieurs copies de message à plusieurs abonnés. Par exemple, supposons que vous souhaitiez répliquer les données générées par une application sur plusieurs systèmes de stockage. Vous pouvez utiliser SNS et envoyer ces données à plusieurs abonnés, chacun reproduisant les messages qu'il reçoit sur différents systèmes de stockage (s3, disque dur sur votre hôte, base de données, etc.).


3
Donc, fondamentalement, pour implémenter quelque chose comme des messages de notification push, il est recommandé d'utiliser SNS et SQS pour que les push avec sns soient mis en file d'attente jusqu'à ce que l'utilisateur ne les récupère que de la file d'attente. Est-il possible de créer une file d'attente par utilisateur?
Nick Ginanto

2
Ouais. Vous pouvez avoir autant d'abonnés que vous le souhaitez pour SNS. Vous pouvez envoyer des notifications à plusieurs files d'attente.
Srikanth

Salut désolé, je vois que cette question est ancienne mais je me demande si SQS connaît et stocke les messages hors ligne? Étant donné qu'APNS ne stocke pas les messages hors ligne, seul le message le plus récent. Saurait-il que les appareils IOS sont hors ligne et stockent immédiatement les messages hors ligne? Et l'envoyer plus tard lorsque les appareils seront de nouveau en ligne?
John

2
@NickGinanto Queue par utilisateur n'est probablement pas ce que vous voulez. Vous souhaiterez probablement une file d'attente pour chaque service qui gère ensuite les messages spécifiques à l'utilisateur. Ce diagramme peut aider: aws.amazon.com/blogs/aws/…
Trenton

2
Il convient probablement de noter qu'à partir de la mi-2018, SQS peut déclencher des lambdas et s'apparente donc davantage à un pubsub dans ce cas.
cyberwombat

239

Voici une comparaison des deux:

Type d'entité

  • SQS: file d'attente (similaire à JMS)
  • SNS: Sujet (système Pub / Sub)

Consommation de messages

  • SQS: Pull Mechanism - Les consommateurs interrogent et extraient des messages de SQS
  • SNS: mécanisme de poussée - SNS envoie des messages aux consommateurs

Cas d'utilisation

  • SQS: découplage de 2 applications et permettant un traitement asynchrone parallèle
  • SNS: Fanout - Traitement du même message de plusieurs manières

Persistance

  • SQS: les messages sont conservés pendant une certaine durée (configurable) si aucun consommateur n'est disponible
  • SNS: Pas de persistance. Quel que soit le consommateur présent au moment de l'arrivée du message, le message est reçu et le message est supprimé. Si aucun consommateur n'est disponible, le message est perdu.

Type de consommateur

  • SQS: Tous les consommateurs sont censés être identiques et donc traiter les messages exactement de la même manière
  • SNS: les consommateurs peuvent traiter les messages de différentes manières

Exemples d'applications

  • SQS: structure des travaux: les travaux sont soumis à SQS et les consommateurs à l'autre extrémité peuvent traiter les travaux de manière asynchrone. Si la fréquence des travaux augmente, le nombre de consommateurs peut simplement être augmenté pour obtenir un meilleur débit.
  • SNS: Traitement d'image. Si quelqu'un télécharge une image sur S3, filigrane cette image, créez une miniature et envoyez également un e-mail de remerciement. Dans ce cas, S3 peut publier des notifications dans un sujet SNS avec 3 consommateurs qui l'écoutent. Le premier filigrane l'image, le deuxième crée une vignette et le troisième envoie un e-mail de remerciement. Tous reçoivent le même message (URL de l'image) et effectuent leur traitement en parallèle.

1
si aucun consommateur n'est disponible, il existe un mécanisme de nouvelle tentative, même la valeur par défaut est de 10 tentatives.
Arpit Solanki

Joli post détaillé. Nous avons des messages différents pour différents consommateurs - Que devons-nous faire - utiliser SNS et définir différents sujets ou utiliser SQS et définir différentes files d'attente? Un sujet / file d'attente peut cependant avoir un ou plusieurs consommateurs.
Andy Dufresne

Si votre exigence est que votre trop / file d'attente devrait avoir plus d'un consommateur, je suppose que vous dites que le même message devrait être diffusé à plusieurs consommateurs ... Et si cette supposition est correcte, alors l'utilisation de SNS est la seule option disponible pour vous
Arafat Nalkhande

Je ne pense pas "SQS: tous les consommateurs sont censés être identiques et donc traiter les messages exactement de la même manière", c'est vrai. J'ai utilisé SQS où deux services AWS différents récupèrent de la file d'attente SQS et traitent le message à leur manière (logique d'application différente dans ces différents services). Suis-je en train de manquer quelque chose?
nad

@nad J'aurai besoin de comprendre votre cas d'utilisation, mais pour moi, cela n'a aucun sens que 2 consommateurs SQS traitent les messages de manière non identique. C'est un cas d'utilisation pour SNS
Arafat Nalkhande

31

De aws doc:

Amazon SNS permet aux applications d'envoyer des messages urgents à plusieurs abonnés via un mécanisme «push», éliminant ainsi la nécessité de vérifier ou «interroger» périodiquement les mises à jour.

Amazon SQS est un service de file d'attente de messages utilisé par les applications distribuées pour échanger des messages via un modèle d'interrogation, et peut être utilisé pour dissocier les composants d'envoi et de réception, sans que chaque composant soit disponible simultanément.

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


30

Les réponses sur ce fil sont un peu dépassées, j'ai donc décidé d'y ajouter mes deux cents:

Vous pouvez voir SNS comme un sujet traditionnel auquel vous pouvez avoir plusieurs abonnés. Vous pouvez avoir des abonnés hétérogènes pour un sujet SNS donné, notamment Lambda et SQS, par exemple. Vous pouvez également envoyer des SMS ou même des e-mails hors de la boîte en utilisant SNS. Une chose à considérer dans SNS est qu'un seul message (notification) est reçu à la fois, vous ne pouvez donc pas tirer parti du traitement par lots.

SQS , d'autre part, n'est rien d'autre qu'une file d'attente, où vous stockez des messages et abonnez un consommateur (oui, vous pouvez avoir N consommateurs dans une file d'attente SQS, mais cela deviendrait très rapide et beaucoup plus difficile à gérer compte tenu du fait que tous les consommateurs le feraient besoin de lire le message au moins une fois, il vaut donc mieux utiliser SNS combiné avec SQS pour ce cas d'utilisation, où SNS pousserait les notifications vers N files d'attente SQS et chaque file d'attente aurait un seul abonné) pour traiter ces messages. Depuis le 28 juin 2018, AWS prend en charge les déclencheurs Lambda pour SQS , ce qui signifie que vous n'avez pas à interrogerpour les messages plus. De plus, vous pouvez configurer un DLQ sur votre file d'attente SQS source pour envoyer des messages en cas d'échec. En cas de succès, les messages sont automatiquement supprimés (c'est une autre grande amélioration), vous n'avez donc pas à vous soucier de la relecture des messages déjà traités au cas où vous auriez oublié de les supprimer manuellement. Je suggère de jeter un œil à comportement Lambda Retrypour mieux comprendre son fonctionnement. Un grand avantage de l'utilisation de SQS est qu'il permet le traitement par lots. Chaque lot peut contenir jusqu'à 10 messages, donc si 100 messages arrivent en même temps dans votre file d'attente SQS, alors 10 fonctions Lambda tourneront (en considérant le comportement de mise à l'échelle automatique par défaut pour Lambda) et ils traiteront ces 100 messages (gardez dans l'esprit c'est le chemin heureux car dans la pratique, quelques fonctions Lambda supplémentaires pourraient tourner en lisant moins que les 10 messages du lot, mais vous avez l'idée). Si vous publiez ces mêmes 100 messages sur SNS, cependant, 100 fonctions Lambda tourneraient, augmentant inutilement les coûts et utilisant votre concurrence Lambda. Cependant, si vous utilisez toujours des serveurs traditionnels (comme les instances EC2), vous devrez toujours interroger les messages et les gérer manuellement.

Vous disposez également de files d'attente FIFO SQS , qui garantissent l'ordre de livraison des messages. Ce n'est pas un déclencheur pris en charge par Lambda, donc lorsque vous choisissez ce type de file d'attente, gardez à l'esprit que l'interrogation est toujours nécessaire ainsi que la suppression manuelle des messages.

Même s'il y a un certain chevauchement dans leurs cas d'utilisation, SQS et SNS ont leur propre projecteur.

Utilisez SNS si:

  • plusieurs abonnés est une exigence
  • l'envoi de SMS / E-mail hors de la boîte est pratique

Utilisez SQS si:

  • un seul abonné est nécessaire
  • le traitement par lots est important

29

AWS SNS est un réseau d'abonnés d'éditeurs, où les abonnés peuvent s'abonner à des rubriques et recevoir des messages chaque fois qu'un éditeur publie sur cette rubrique.

AWS SQS est un service de file d'attente, qui stocke les messages dans une file d'attente. SQS ne peut délivrer aucun message, lorsqu'un service externe (lambda, EC2, etc.) est nécessaire pour interroger SQS et récupérer des messages de SQS.

SNS et SQS peuvent être utilisés ensemble pour plusieurs raisons.

  1. Il peut y avoir différents types d'abonnés où certains ont besoin de la livraison immédiate des messages, où certains exigeraient que le message persiste, pour une utilisation ultérieure via l'interrogation. Voir ce lien .

  2. Le " modèle de fanout ". C'est pour le traitement asynchrone des messages. Lorsqu'un message est publié sur SNS, il peut le distribuer en parallèle à plusieurs files d'attente SQS. Cela peut être utile lors du chargement de miniatures dans une application en parallèle, lors de la publication d'images. Voir ce lien .

  3. Stockage persistant . Lorsqu'un service qui va traiter un message n'est pas fiable. Dans un cas comme celui-ci, si SNS envoie une notification à un service et que ce service n'est pas disponible, la notification sera perdue. Par conséquent, nous pouvons utiliser SQS comme stockage persistant et le traiter ensuite.


4

En termes simples, SNS - envoie des messages à l'abonné à l'aide du mécanisme push et sans besoin de tirer. SQS - il s'agit d'un service de file d'attente de messages utilisé par les applications distribuées pour échanger des messages via un modèle d'interrogation, et peut être utilisé pour dissocier les composants d'envoi et de réception.

Un modèle courant consiste à utiliser SNS pour publier des messages dans les files d'attente Amazon SQS afin d'envoyer de manière fiable des messages à un ou plusieurs composants système de manière asynchrone. Référence de https://aws.amazon.com/sns/faqs/


SQS ne peut pas envoyer de message à de nombreux systèmes car il ne déploie pas les messages. Oui, de nombreux sondeurs peuvent en extraire des messages, mais si l'un des consommateurs supprime le message, les autres abonnés ne pourront plus consommer le même message. SNS est préféré à SQS si vous souhaitez obtenir un modèle de fan out. De plus, si le visibilityTimeoutest défini, aucun autre système ne pourra consommer le message une fois qu'il sera traité par un autre système.
Thales Minussi

Un modèle courant consiste à utiliser SNS pour publier des messages dans les files d'attente Amazon SQS afin d'envoyer de manière fiable des messages à un ou plusieurs composants système de manière asynchrone. Référence de aws.amazon.com/sns/faqs
Krunal Barot

Si c'est ce que vous vouliez dire (SNS -> plusieurs files d'attente SQS), veuillez modifier votre réponse et je supprimerai volontiers mon downvote. Comme vous le dites, il semble que SQS puisse se déployer.
Thales Minussi

1
Oui .. c'est là que la confusion était. Je l'ai édité .. Merci :)
Krunal Barot
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.