¿Cuál es la diferencia entre Amazon SNS y Amazon SQS?
¿Cuándo debería utilizar SNS frente a SQS y por qué siempre están acoplados?
SNS es un sistema distribuido de publicación y suscripción . Los mensajes se envían a los suscriptores a medida que los editores los envían al SNS.
SQS es un sistema de colas distribuidas . Los mensajes no se envían a los destinatarios. Los receptores tienen que sondear o extraer mensajes de SQS . Los mensajes no pueden ser recibidos por varios destinatarios al mismo tiempo. Cualquier receptor puede recibir un mensaje, procesarlo y eliminarlo. Otros receptores no reciben el mismo mensaje más tarde. El sondeo introduce inherentemente cierta latencia en la entrega de mensajes en SQS, a diferencia de SNS, donde los mensajes se envían inmediatamente a los suscriptores. SNS admite varios puntos finales, como correo electrónico, SMS, punto final HTTP y SQS. Si desea que un número y tipo desconocido de suscriptores reciban mensajes, necesita SNS.
No es necesario que siempre combine SNS y SQS. Puede hacer que SNS envíe mensajes a correo electrónico, SMS o punto final HTTP aparte de SQS. Existen ventajas al acoplar SNS con SQS. Es posible que no desee que un servicio externo establezca conexiones con sus hosts (un firewall puede bloquear todas las conexiones entrantes a su host desde el exterior).
Es posible que su punto final simplemente muera debido al gran volumen de mensajes. El correo electrónico y los SMS tal vez no sean su opción para procesar mensajes rápidamente. Al combinar SNS con SQS, puede recibir mensajes a su ritmo. Permite a los clientes estar fuera de línea y ser tolerantes a fallas de red y host. También logras entrega garantizada. Si configura SNS para enviar mensajes a un punto final HTTP o correo electrónico o SMS, varias fallas al enviar mensajes pueden provocar que los mensajes se descarten.
SQS se utiliza principalmente para desacoplar aplicaciones o integrar aplicaciones. Los mensajes se pueden almacenar en SQS por un corto período de tiempo (máximo 14 días). SNS distribuye varias copias de mensajes a varios suscriptores. Por ejemplo, digamos que desea replicar los datos generados por una aplicación en varios sistemas de almacenamiento. Puede usar SNS y enviar estos datos a varios suscriptores, cada uno replicando los mensajes que recibe en diferentes sistemas de almacenamiento ( S3 , disco duro de su host, base de datos, etc.).
Aquí hay una comparación de los dos:
Tipo de entidad
- SQS: Cola (Similar a JMS)
- SNS: Tema (sistema Pub/Sub)
Consumo de mensajes
- SQS: Mecanismo de extracción: los consumidores encuestan y extraen mensajes de SQS
- SNS: mecanismo de inserción: SNS envía mensajes a los consumidores
Caso de uso
- SQS: desacoplar dos aplicaciones y permitir el procesamiento asíncrono paralelo
- SNS: Fanout: procesar el mismo mensaje de múltiples maneras
Persistencia
- SQS: los mensajes persisten durante un tiempo (configurable) si no hay ningún consumidor disponible (máximo dos semanas), por lo que el consumidor no tiene que estar despierto cuando se agregan mensajes a la cola.
- SNS: Sin persistencia. Cualquier consumidor que esté presente en el momento de la llegada del mensaje recibe el mensaje y se elimina. Si no hay ningún consumidor disponible, el mensaje se pierde después de algunos intentos.
Tipo de consumidor
- SQS: todos los consumidores suelen ser idénticos y, por lo tanto, procesan los mensajes exactamente de la misma manera (cada mensaje es procesado una vez por un consumidor, aunque en casos excepcionales los mensajes pueden reenviarse)
- SNS: los consumidores pueden procesar los mensajes de diferentes maneras.
Aplicaciones de muestra
- SQS: marco de trabajos: los trabajos se envían a SQS y los consumidores en el otro extremo pueden procesar los trabajos de forma asincrónica. Si aumenta la frecuencia del trabajo, simplemente se puede aumentar el número de consumidores para lograr un mejor rendimiento.
- SNS: Procesamiento de imágenes. Si alguien carga una imagen en S3 , coloque una marca de agua en esa imagen, cree una miniatura y también envíe un correo electrónico de agradecimiento . En ese caso, S3 puede publicar notificaciones sobre un tema de SNS con tres consumidores escuchándolo. El primero marca la imagen con una marca de agua, el segundo crea una miniatura y el tercero envía un correo electrónico de agradecimiento . Todos ellos reciben el mismo mensaje (URL de la imagen) y realizan su procesamiento en paralelo.
Puede ver las redes sociales como un tema tradicional en el que puede tener varios suscriptores. Puede tener suscriptores heterogéneos para un tema de SNS determinado, incluidos Lambda y SQS , por ejemplo. También puede enviar mensajes SMS o incluso correos electrónicos de forma inmediata mediante SNS. Una cosa a considerar en SNS es que solo se recibe un mensaje (notificación) a la vez, por lo que no se puede aprovechar el procesamiento por lotes.
SQS , por otro lado, no es más que una cola , donde almacena mensajes y suscribe a un consumidor (sí, puede tener N consumidores en una cola SQS, pero se complicaría muy rápidamente y sería mucho más difícil de administrar considerando que todos los consumidores lo harían). Es necesario leer el mensaje al menos una vez, por lo que es mejor usar SNS combinado con SQS para este caso de uso, donde SNS enviaría notificaciones a N colas SQS y cada cola tendría un suscriptor, solamente) para procesar estos mensajes. A partir del 28 de junio de 2018, AWS admite desencadenadores Lambda para SQS , lo que significa que ya no es necesario sondear los mensajes.
Además, puede configurar un DLQ en su cola SQS de origen para enviar mensajes en caso de falla. En caso de éxito, los mensajes se eliminan automáticamente (esta es otra gran mejora), por lo que no tienes que preocuparte de que los mensajes ya procesados se vuelvan a leer en caso de que hayas olvidado eliminarlos manualmente. Sugiero echar un vistazo a Lambda Retry Behavior para comprender mejor cómo funciona.
Una gran ventaja de utilizar SQS es que permite el procesamiento por lotes. Cada lote puede contener hasta 10 mensajes, por lo que si llegan 100 mensajes a la vez a su cola SQS, se activarán 10 funciones Lambda (teniendo en cuenta el comportamiento de escalado automático predeterminado para Lambda) y procesarán estos 100 mensajes (mantenga en Tenga en cuenta que este es el camino feliz, ya que en la práctica, algunas funciones Lambda más podrían funcionar leyendo menos de los 10 mensajes del lote, pero se entiende la idea). Sin embargo, si publicara estos mismos 100 mensajes en SNS, se activarían 100 funciones Lambda, lo que aumentaría innecesariamente los costos y consumiría su concurrencia Lambda.
Sin embargo, si todavía está ejecutando servidores tradicionales (como instancias EC2 ), aún necesitará sondear los mensajes y administrarlos manualmente.
También dispones de colas FIFO SQS , que garantizan el orden de entrega de los mensajes. SQS FIFO también es compatible como fuente de eventos para Lambda a partir de noviembre de 2019
Aunque existe cierta superposición en sus casos de uso, tanto SQS como SNS tienen su propio foco de atención.
Utilice SNS si:
- múltiples suscriptores es un requisito
- enviar SMS/correo electrónico de forma inmediata es útil
Utilice SQS si:
- solo se necesita un suscriptor
- el procesamiento por lotes es importante
AWS SNS es una red de suscriptores de editores, donde los suscriptores pueden suscribirse a temas y recibirán mensajes cada vez que un editor publique sobre ese tema.
AWS SQS es un servicio de cola que almacena mensajes en una cola. SQS no puede entregar ningún mensaje, donde se necesita un servicio externo (lambda, EC2, etc.) para sondear SQS y capturar mensajes de SQS.
SNS y SQS se pueden utilizar juntos por múltiples motivos.
Puede haber diferentes tipos de suscriptores donde algunos necesitan la entrega inmediata de mensajes, mientras que otros requerirían que el mensaje persista, para su uso posterior mediante sondeo. Vea este enlace .
El " patrón de distribución en abanico ". Esto es para el procesamiento asincrónico de mensajes. Cuando se publica un mensaje en SNS, se puede distribuir a varias colas SQS en paralelo. Esto puede resultar fantástico al cargar miniaturas en una aplicación en paralelo, cuando se publican imágenes. Vea este enlace .
Almacenamiento persistente . Cuando un servicio que va a procesar un mensaje no es confiable. En un caso como este, si SNS envía una notificación a un Servicio y ese servicio no está disponible, la notificación se perderá. Por lo tanto, podemos usar SQS como almacenamiento persistente y luego procesarlo.
