Não entendo quando usaria o SNS versus o SQS e por que eles sempre estão acoplados?
Não entendo quando usaria o SNS versus o SQS e por que eles sempre estão acoplados?
Respostas:
O SNS é um sistema distribuído de publicação e assinatura . As mensagens são enviadas aos assinantes como e quando são enviadas pelos editores ao SNS.
O SQS é um sistema de enfileiramento distribuído . As mensagens NÃO são enviadas aos destinatários. Os receptores precisam pesquisar ou receber mensagens do SQS . As mensagens não podem ser recebidas por vários receptores ao mesmo tempo. Qualquer receptor pode receber uma mensagem, processar e excluí-la. Outros receptores não recebem a mesma mensagem posteriormente. A pesquisa introduz inerentemente alguma latência na entrega de mensagens no SQS, diferentemente do SNS, onde as mensagens são imediatamente enviadas aos assinantes. O SNS suporta vários pontos finais, como email, sms, ponto final http e SQS. Se você deseja que um número e tipo de assinantes desconhecidos recebam mensagens, precisará do SNS.
Você não precisa associar SNS e SQS sempre. Você pode fazer com que o SNS envie mensagens para email, sms ou ponto final http, além do SQS. Há vantagens em acoplar o SNS ao SQS. Você pode não querer que um serviço externo faça conexões com seus hosts (o firewall pode bloquear todas as conexões de entrada do seu host de fora). Seu ponto final pode simplesmente morrer devido ao grande volume de mensagens. E-mail e SMS talvez não sejam a sua escolha de processar mensagens rapidamente. Ao acoplar o SNS ao SQS, você pode receber mensagens no seu ritmo. Ele permite que os clientes estejam offline, tolerantes a falhas de rede e host. Você também consegue entrega garantida. Se você configurar o SNS para enviar mensagens para um ponto final http ou email ou SMS, várias falhas no envio da mensagem poderão resultar na queda da mensagem.
O SQS é usado principalmente para dissociar aplicativos ou integrar aplicativos. As mensagens podem ser armazenadas no SQS por um curto período de tempo (máximo de 14 dias). O SNS distribui várias cópias da mensagem para vários assinantes. Por exemplo, digamos que você deseja replicar os dados gerados por um aplicativo em vários sistemas de armazenamento. Você pode usar o SNS e enviar esses dados para vários assinantes, cada um replicando as mensagens que recebe para diferentes sistemas de armazenamento (s3, disco rígido no host, banco de dados etc.).
Aqui está uma comparação dos dois:
Tipo de entidade
Consumo de mensagem
Caso de Uso
Persistência
Tipo de Consumidor
Aplicativos de amostra
Do aws doc:
O Amazon SNS permite que os aplicativos enviem mensagens críticas para vários assinantes por meio de um mecanismo "push", eliminando a necessidade de verificar periodicamente ou "pesquisar" por atualizações.
O Amazon SQS é um serviço de fila de mensagens usado por aplicativos distribuídos para trocar mensagens por meio de um modelo de pesquisa e pode ser usado para dissociar componentes de envio e recebimento - sem exigir que cada componente esteja disponível simultaneamente.
http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html
O AWS SNS é uma rede de assinantes de publicadores, na qual os assinantes podem se inscrever em tópicos e receber mensagens sempre que um publicador publicar nesse tópico.
O AWS SQS é um serviço de fila, que armazena mensagens em uma fila. O SQS não pode entregar nenhuma mensagem, onde um serviço externo (lambda, EC2 etc.) é necessário para pesquisar o SQS e capturar mensagens do SQS.
O SNS e o SQS podem ser usados juntos por vários motivos.
Pode haver diferentes tipos de assinantes em que alguns precisam da entrega imediata de mensagens, enquanto alguns exigiriam que a mensagem persistisse, para uso posterior por meio de pesquisa. Veja este link .
O " Padrão Fanout ". Isto é para o processamento assíncrono de mensagens. Quando uma mensagem é publicada no SNS, ela pode distribuí-la para várias filas SQS em paralelo. Isso pode ser ótimo ao carregar miniaturas em um aplicativo em paralelo, quando as imagens estão sendo publicadas. Veja este link .
Armazenamento persistente . Quando um serviço que vai processar uma mensagem não é confiável. Em um caso como esse, se o SNS enviar uma notificação para um Serviço, e esse serviço estiver indisponível, a notificação será perdida. Portanto, podemos usar o SQS como um armazenamento persistente e depois processá-lo.
As respostas neste tópico estão um pouco desatualizadas, por isso decidi adicionar meus dois centavos a ele:
Você pode ver o SNS como um tópico tradicional, no qual você pode ter vários Assinantes. Você pode ter assinantes heterogêneos para um determinado tópico do SNS, incluindo Lambda e SQS, por exemplo. Você também pode enviar mensagens SMS ou até e-mails imediatamente usando o SNS. Uma coisa a considerar no SNS é que apenas uma mensagem (notificação) é recebida de uma só vez, para que você não possa tirar proveito do lote.
O SQS , por outro lado, nada mais é do que uma Fila, na qual você armazena mensagens e assina um consumidor (sim, você pode ter N consumidores em uma fila SQS, mas ficaria confuso muito rapidamente e muito mais difícil de gerenciar, considerando que todos os consumidores o fariam. é necessário ler a mensagem pelo menos uma vez, para que seja melhor o SNS combinado com o SQS para este caso de uso, em que o SNS enviaria notificações para N filas SQS e cada fila teria apenas um assinante) para processar essas mensagens. Em 28 de junho de 2018, a AWS oferece suporte a gatilhos Lambda para SQS , o que significa que você não precisa pesquisarpara mensagens mais. Além disso, você pode configurar um DLQ na fila SQS de origem para enviar mensagens em caso de falha. Em caso de sucesso, as mensagens são excluídas automaticamente (este é outro grande aprimoramento), para que você não precise se preocupar com as mensagens já processadas sendo lidas novamente, caso se esqueça de excluí-las manualmente. Sugiro dar uma olhada Lambda Retry Behaviorpara entender melhor como isso funciona. Um grande benefício do uso do SQS é que ele permite o processamento em lote. Cada lote pode conter até 10 mensagens; portanto, se 100 mensagens chegarem ao mesmo tempo na fila do SQS, as 10 funções do Lambda serão ativadas (considerando o comportamento padrão de dimensionamento automático do Lambda) e elas processarão essas 100 mensagens (mantenha-se em lembre-se de que este é o caminho feliz, como na prática, mais algumas funções do Lambda podem aparecer lendo menos do que as 10 mensagens do lote, mas você entendeu). Se você postasse essas mesmas 100 mensagens no SNS, no entanto, 100 funções do Lambda seriam ativadas, aumentando desnecessariamente os custos e esgotando a simultaneidade do Lambda. No entanto, se você ainda estiver executando servidores tradicionais (como instâncias do EC2), ainda precisará pesquisar mensagens e gerenciá-las manualmente.
Você também tem filas FIFO SQS , que garantem a ordem de entrega das mensagens. Esse não é um gatilho suportado pelo Lambda; portanto, ao escolher esse tipo de fila, lembre-se de que a pesquisa ainda é necessária, além de ter que excluir as mensagens manualmente.
Embora exista alguma sobreposição em seus casos de uso, o SQS e o SNS têm seus próprios holofotes.
Use o SNS se:
Use SQS se:
Em termos simples, o SNS - envia mensagens ao assinante usando o mecanismo de envio e sem necessidade de puxar. SQS - é um serviço de fila de mensagens usado por aplicativos distribuídos para trocar mensagens por meio de um modelo de pesquisa e pode ser usado para dissociar componentes de envio e recebimento.
Um padrão comum é usar o SNS para publicar mensagens nas filas do Amazon SQS para enviar mensagens de maneira confiável para um ou vários componentes do sistema de forma assíncrona. Referência de https://aws.amazon.com/sns/faqs/
visibilityTimeout
estiver definido, nenhum outro sistema poderá consumir a mensagem depois que ela estiver sendo processada por outro sistema.