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

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

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.).

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.

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

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

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.

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/