Qual è la differenza tra Amazon SNS e Amazon SQS?

Non capisco quando userei SNS contro SQS e perché sono sempre accoppiati insieme?

SNS è un sistema distribuito di sottoscrizione e pubblicazione . I messaggi vengono inviati agli abbonati, come e quando vengono inviati dagli editori per SNS.

SQS è un sistema di accodamento distribuito . I messaggi NON vengono inviati ai destinatari. I ricevitori devono eseguire il polling o estrarre i messaggi da SQS . I messaggi non possono essere ricevuti da più destinatari contemporaneamente. Ogni destinatario può ricevere un messaggio, elaborarlo ed eliminarlo. Altri ricevitori non riceveranno lo stesso messaggio in un secondo momento. Il polling introduce intrinsecamente una certa latenza nella consegna dei messaggi in SQS, diversamente da SNS, dove i messaggi vengono immediatamente inviati agli abbonati. SNS supporta diversi endpoint come e-mail, sms, endpoint http e SQS. Se si desidera che il numero e il tipo di abbonati sconosciuti ricevano messaggi, è necessario SNS.

Non devi sempre accoppiare SNS e SQS. Puoi fare in modo che SNS invii messaggi a e-mail, sms o http end point oltre a SQS. Ci sono vantaggi nell'accoppiare SNS con SQS. È possibile che non si desideri che un servizio esterno effettui connessioni ai propri host (il firewall potrebbe bloccare tutte le connessioni esterne al proprio host dall'esterno). Il tuo end point potrebbe semplicemente morire a causa del pesante volume di messaggi. Email e SMS potrebbero non essere la tua scelta di elaborare rapidamente i messaggi. Associando SNS a SQS, puoi ricevere messaggi al tuo ritmo. Consente ai client di essere offline, tolleranti alla rete e agli errori dell'host. Ottieni anche la consegna garantita. Se si configura SNS per l'invio di messaggi a un end point http o e-mail o SMS, diversi errori nell'invio del messaggio potrebbero comportare l'eliminazione del messaggio.

SQS viene utilizzato principalmente per disaccoppiare applicazioni o integrare applicazioni. I messaggi possono essere memorizzati in SQS per un breve periodo di tempo (massimo 14 giorni). SNS distribuisce diverse copie del messaggio a diversi abbonati. Ad esempio, supponiamo che tu voglia replicare i dati generati da un'applicazione su diversi sistemi di archiviazione. È possibile utilizzare SNS e inviare questi dati a più abbonati, ciascuno replicando i messaggi che riceve su diversi sistemi di archiviazione (s3, disco rigido sull'host, database, ecc.).

Ecco un confronto tra i due:

Tipo di entità

• SQS: Queue (simile a JMS)
• SNS: Argomento (Pub / Sottosistema)

Consumo di messaggi

• SQS: Pull Mechanism - I sondaggi dei consumatori e i messaggi pull da SQS
• SNS: Push Mechanism - SNS invia i messaggi ai consumatori

Caso d'uso

• SQS: disaccoppiamento di 2 applicazioni e elaborazione parallela asincrona
• SNS: Fanout - Elaborazione dello stesso messaggio in più modi

Persistenza

• SQS: i messaggi persistono per un certo periodo (configurabile) se non è disponibile alcun utente
• SNS: nessuna persistenza. Qualunque consumatore sia presente al momento dell'arrivo del messaggio, riceve il messaggio e il messaggio viene eliminato. Se non sono disponibili consumatori, il messaggio viene perso.

Tipo di consumatore

• SQS: Tutti i consumatori dovrebbero essere identici e quindi elaborare i messaggi esattamente allo stesso modo
• SNS: i consumatori potrebbero elaborare i messaggi in diversi modi

Esempi di applicazioni

• SQS: Framework dei lavori: i lavori vengono inviati a SQS e i consumatori all'altra estremità possono elaborare i lavori in modo asincrono. Se la frequenza del lavoro aumenta, il numero di consumatori può essere semplicemente aumentato per ottenere una migliore produttività.
• SNS: elaborazione delle immagini. Se qualcuno carica un'immagine su S3 quindi filigrana quell'immagine, crea una miniatura e invia anche un'email di ringraziamento. In tal caso S3 può pubblicare notifiche su un argomento SNS con 3 utenti che lo ascoltano. Il primo filigrana l'immagine, il secondo crea una miniatura e il terzo invia un'e-mail di ringraziamento. Tutti ricevono lo stesso messaggio (URL dell'immagine) ed eseguono l'elaborazione in parallelo.

Da aws doc:

Amazon SNS consente alle applicazioni di inviare messaggi critici a più abbonati attraverso un meccanismo "push", eliminando la necessità di controllare periodicamente o "sondare" per gli aggiornamenti.

Amazon SQS è un servizio di coda messaggi utilizzato dalle applicazioni distribuite per scambiare messaggi attraverso un modello di polling e può essere utilizzato per disaccoppiare i componenti di invio e ricezione, senza che sia necessario che ciascun componente sia disponibile contemporaneamente.

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

Le risposte su questo thread sono un po 'datate, quindi ho deciso di aggiungere i miei due centesimi:

Puoi vedere SNS come argomento tradizionale che puoi avere più abbonati. Puoi avere abbonati eterogenei per un determinato argomento SNS, inclusi Lambda e SQS, ad esempio. Puoi anche inviare SMS o persino e-mail fuori dalla scatola usando SNS. Una cosa da considerare in SNS è la ricezione di un solo messaggio (notifica) alla volta, quindi non è possibile trarre vantaggio dal batch.

SQS , d'altra parte, non è altro che una coda, in cui si memorizzano i messaggi e si iscrive un consumatore (sì, è possibile avere N consumatori in una coda SQS, ma diventerebbe molto disordinato e molto più difficile da gestire considerando che tutti i consumatori è necessario leggere il messaggio almeno una volta, quindi è meglio con SNS combinato con SQS per questo caso d'uso, in cui SNS invierà le notifiche a N code SQS e ogni coda avrebbe un solo abbonato, per elaborare questi messaggi. A partire dal 28 giugno 2018, AWS supporta i trigger Lambda per SQS , il che significa che non è necessario pollingper più messaggi. Inoltre, è possibile configurare un DLQ sulla coda SQS di origine per l'invio di messaggi in caso di errore. In caso di successo, i messaggi vengono eliminati automaticamente (questo è un altro grande miglioramento), quindi non devi preoccuparti che i messaggi già elaborati vengano letti di nuovo nel caso in cui ti dimentichi di eliminarli manualmente. Suggerisco di dare un'occhiata a Lambda Retry Behaviourper capire meglio come funziona. Un grande vantaggio dell'utilizzo di SQS è che consente l'elaborazione in batch. Ogni batch può contenere fino a 10 messaggi, quindi se arrivano 100 messaggi contemporaneamente nella coda SQS, verranno visualizzate 10 funzioni Lambda (considerando il comportamento di ridimensionamento automatico predefinito per Lambda) ed elaboreranno questi 100 messaggi (continua a attenzione questo è il percorso felice come in pratica, alcune altre funzioni Lambda potrebbero girare leggendo meno dei 10 messaggi nel batch, ma si ottiene l'idea). Se hai inviato questi stessi 100 messaggi a SNS, tuttavia, verrebbero visualizzate 100 funzioni Lambda, aumentando inutilmente i costi e utilizzando la tua concorrenza Lambda. Tuttavia, se si stanno ancora eseguendo server tradizionali (come istanze EC2), sarà comunque necessario eseguire il polling per i messaggi e gestirli manualmente.

Hai anche le code FQS SQS , che garantiscono l'ordine di consegna dei messaggi. Questo non è un trigger supportato da Lambda, quindi quando si sceglie questo tipo di coda, tenere presente che il polling è ancora necessario e che è necessario eliminare i messaggi manualmente.

Anche se c'è qualche sovrapposizione nei loro casi d'uso, sia SQS che SNS hanno i loro riflettori.

Usa SNS se:

• più abbonati è un requisito
• l'invio di SMS / e-mail fuori dalla scatola è utile

Usa SQS se:

• è necessario un solo abbonato
• il dosaggio è importante

AWS SNS è una rete di abbonati dell'editore, in cui gli abbonati possono iscriversi agli argomenti e riceveranno messaggi ogni volta che un editore pubblica tali argomenti.

AWS SQS è un servizio di coda che archivia i messaggi in una coda. SQS non può recapitare alcun messaggio in cui è necessario un servizio esterno (lambda, EC2 ecc.) Per eseguire il polling di SQS e catturare messaggi da SQS.

SNS e SQS possono essere utilizzati insieme per diversi motivi.

1. Potrebbero esserci diversi tipi di abbonati in cui alcuni hanno bisogno della consegna immediata dei messaggi, dove alcuni richiedono che il messaggio persista, per un uso successivo tramite polling. Vedere questo collegamento .

2. Il " modello Fanout ". Questo è per l'elaborazione asincrona dei messaggi. Quando un messaggio viene pubblicato su SNS, può distribuirlo in parallelo a più code SQS. Questo può essere ottimo quando si caricano le anteprime in un'applicazione in parallelo, quando le immagini vengono pubblicate. Vedere questo collegamento .

3. Archiviazione persistente . Quando un servizio che sta per elaborare un messaggio non è affidabile. In un caso come questo, se SNS invia una notifica a un servizio e tale servizio non è disponibile, la notifica andrà persa. Pertanto possiamo utilizzare SQS come memoria persistente e quindi elaborarlo in seguito.

In termini semplici, SNS: invia messaggi all'abbonato utilizzando il meccanismo push e senza necessità di pull. SQS: è un servizio di coda messaggi utilizzato dalle applicazioni distribuite per scambiare messaggi attraverso un modello di polling e può essere utilizzato per disaccoppiare i componenti di invio e ricezione.

Un modello comune è utilizzare SNS per pubblicare messaggi nelle code di Amazon SQS per inviare messaggi in modo affidabile a uno o più componenti di sistema in modo asincrono. Riferimento da https://aws.amazon.com/sns/faqs/