Я не понимаю, когда я буду использовать SNS против SQS и почему они всегда связаны вместе?
В чем разница между Amazon SNS и Amazon SQS?
Ответ 1
SNS - это распределенная система публикации-подписки. Сообщения выталкиваются абоненты, как и когда они отправляются издателями SNS.
SQS - распределенная система массового обслуживания. Сообщения НЕ отправляются получателям. Получатели должны опрашивать или извлекать сообщения из SQS. Сообщения не могут быть получены несколькими получателями одновременно. Любой получатель может получить сообщение, обработать и удалить его. Другие получатели не получают то же сообщение позже. Опрос по своей сути вводит некоторую задержку при доставке сообщений в SQS в отличие от SNS, где сообщения немедленно передаются подписчикам. SNS поддерживает несколько конечных точек, таких как электронная почта, смс, конечная точка http и SQS. Если вы хотите, чтобы неизвестный номер и тип подписчиков получали сообщения, вам нужен SNS.
Вам не нужно соединять SNS и SQS всегда. Вы можете сделать так, чтобы SNS отправлял сообщения на электронную почту, смс или в конечную точку http кроме SQS. Есть преимущества для соединения SNS с SQS. Возможно, вы не захотите, чтобы внешняя служба выполняла подключения к вашим хостам (брандмауэр может блокировать все входящие подключения к вашему хосту извне). Ваша конечная точка может просто умереть из-за большого объема сообщений. Электронная почта и SMS, возможно, не ваш выбор обработки сообщений быстро. Связав SNS с SQS, вы можете получать сообщения в своем темпе. Это позволяет клиентам быть автономными, терпимыми к сбоям сети и хоста. Вы также добиваетесь гарантированной доставки. Если вы настроите SNS на отправку сообщений в конечную точку http или на электронную почту или SMS, несколько сбоев при отправке сообщения могут привести к его удалению.
SQS в основном используется для ветки приложений или интеграции приложений. Сообщения могут храниться в SQS в течение короткого промежутка времени (максимум 14 дней). SNS раздает несколько копий сообщения нескольким подписчикам. Например, допустим, вы хотите реплицировать данные, сгенерированные приложением, в несколько систем хранения. Вы можете использовать SNS и отправлять эти данные нескольким подписчикам, каждый из которых реплицирует полученные сообщения в разные системы хранения (s3, жесткий диск на вашем хосте, база данных и т.д.).
Ответ 2
Вот сравнение двух:
Тип объекта
- SQS: очередь (аналогично JMS)
- SNS: Тема (Pub/Sub system)
Потребление сообщений
- SQS: механизм извлечения - потребители опрашивают и извлекают сообщения из SQS
- SNS: Push-механизм - SNS отправляет сообщения потребителям
Случай использования
- SQS: разделение 2 приложений и параллельная асинхронная обработка
- SNS: Fanout - обработка одного и того же сообщения несколькими способами
Упорство
- SQS: сообщения сохраняются в течение некоторой (настраиваемой) длительности, если нет доступных потребителей
- SNS: нет настойчивости. Какой бы потребитель ни присутствовал во время прибытия сообщения, он получает сообщение, и сообщение удаляется. Если нет доступных потребителей, то сообщение теряется.
Тип потребителя
- SQS: Все потребители должны быть идентичными и, следовательно, обрабатывать сообщения одинаково
- SNS: потребители могут обрабатывать сообщения по-разному
Примеры приложений
- SQS: структура заданий: задания передаются в SQS, а потребители на другом конце могут обрабатывать задания асинхронно. Если частота работы увеличивается, число потребителей может быть просто увеличено для достижения лучшей пропускной способности.
- SNS: обработка изображений. Если кто-то загрузит изображение на S3, отметьте его водяным знаком, создайте миниатюру и отправьте электронное письмо с благодарностью. В этом случае S3 может публиковать уведомления в теме SNS, которую слушают 3 потребителя. 1-й из них создает водяные знаки на изображении, 2-й создает миниатюру, а 3-й отправляет электронное письмо с благодарностью. Все они получают одно и то же сообщение (URL-адрес изображения) и выполняют их обработку параллельно.
Ответ 3
От aws doc:
Amazon SNS позволяет приложениям отправлять критически важные по времени сообщения несколько подписчиков через механизм "push", устраняя необходимость периодически проверять или "опросить" обновления.
Amazon SQS - это служба очереди сообщений, используемая распределенными приложениями для обмена сообщениями через модель опроса и может использоваться для развяжите отправляющие и принимающие компоненты, не требуя компонент, который будет одновременно доступен.
http://docs.aws.amazon.com/sns/latest/dg/SendMessageToSQS.html
Ответ 4
AWS SNS - это сеть подписчиков издателей, где подписчики могут подписываться на темы и будут получать сообщения всякий раз, когда издатель публикует эту тему.
AWS SQS - это служба очереди, которая хранит сообщения в очереди. SQS не может доставлять сообщения, если для опроса SQS и получения сообщений от SQS необходима внешняя служба (лямбда, EC2 и т.д.).
SNS и SQS могут использоваться вместе по нескольким причинам.
-
Могут быть подписчики разных типов, где некоторым требуется немедленная доставка сообщений, а некоторым требуется сохранение сообщения для последующего использования посредством опроса. Смотрите эту ссылку.
-
" Шаблон разветвления ". Это для асинхронной обработки сообщений. Когда сообщение публикуется в SNS, оно может распределить его по нескольким очередям SQS параллельно. Это может быть полезно при параллельной загрузке миниатюр в приложении, когда изображения публикуются. Смотрите эту ссылку.
-
Постоянное хранение. Когда служба, которая собирается обрабатывать сообщение, не является надежной. В таком случае, если SNS отправляет уведомление службе, и эта служба недоступна, уведомление будет потеряно. Поэтому мы можем использовать SQS в качестве постоянного хранилища, а затем обрабатывать его.
Ответ 5
Ответы в этой теме немного устарели, поэтому я решил добавить к ней два цента:
Вы можете видеть SNS как традиционную тему, которая может иметь несколько подписчиков. Вы можете иметь разнородных подписчиков для одной данной темы SNS, включая, например, Lambda и SQS. Вы также можете отправлять SMS-сообщения или даже электронные письма из коробки, используя SNS. В SNS необходимо учитывать только одно сообщение (уведомление), полученное за один раз, поэтому вы не сможете воспользоваться преимуществами пакетирования.
С другой стороны, SQS - это не что иное, как Очередь, в которой вы храните сообщения и подписываете одного потребителя (да, у вас может быть N потребителей на одну очередь SQS, но это очень быстро запутывается и управлять намного сложнее, учитывая, что все потребители будут необходимо прочитать сообщение хотя бы один раз, поэтому лучше использовать SNS в сочетании с SQS для этого случая использования, когда SNS будет отправлять уведомления в N очередей SQS, и в каждой очереди будет только один подписчик) для обработки этих сообщений. По состоянию на 28 июня 2018 года AWS поддерживает лямбда-триггеры для SQS, что означает, что вам больше не нужно запрашивать сообщения. Кроме того, вы можете настроить DLQ в исходной очереди SQS для отправки сообщений в случае сбоя. В случае успеха сообщения автоматически удаляются (это еще одно значительное улучшение), поэтому вам не нужно беспокоиться о том, что уже обработанные сообщения будут прочитаны снова, если вы забыли удалить их вручную. Я предлагаю взглянуть на Lambda Retry Behavior, чтобы лучше понять, как это работает. Одним из больших преимуществ использования SQS является возможность пакетной обработки. Каждый пакет может содержать до 10 сообщений, поэтому, если в вашу очередь SQS одновременно поступает 100 сообщений, то 10 функций Lambda будут раскручиваться (с учетом поведения автоматического масштабирования по умолчанию для Lambda) и обрабатывать эти 100 сообщений (сохранить в Имейте в виду, что это удачный путь, так как на практике несколько лямбда-функций могут ускорять чтение меньше, чем 10 сообщений в пакете, но вы понимаете). Однако, если вы отправите эти те же 100 сообщений в SNS, 100 функций Lambda раскрутятся, что излишне увеличит затраты и израсходует ваш Lambda-параллелизм. Однако, если вы по-прежнему используете традиционные серверы (например, экземпляры EC2), вам все равно придется опросить сообщения и управлять ими вручную.
У вас также есть очереди FIFO SQS, которые гарантируют порядок доставки сообщений. Это не поддерживается триггером Lambda, поэтому при выборе этого типа очереди следует учитывать, что опрос все равно необходим, а также необходимо удалить сообщения вручную.
Несмотря на то, что их варианты использования частично совпадают, у SQS и SNS есть свой собственный центр внимания.
Используйте SNS, если:
- Требуется несколько подписчиков
- отправка СМС/электронной почты из коробки - это удобно
Используйте SQS, если:
- нужен только один подписчик
- дозирование важно
Ответ 6
Хороший ответ от @Srikanth. К этому я бы добавил, что SQS может использоваться для пакетной обработки. Когда вы проводите опрос в очереди, вы можете получать сразу несколько сообщений и обрабатывать их в пакете. Возможно, вы захотите сделать это по соображениям производительности или стоимости. Вы не можете сделать это с помощью SNS.
Ответ 7
Говоря простым языком, SNS - отправляет сообщения абоненту с использованием механизма push и без необходимости извлечения. SQS - это служба очереди сообщений, используемая распределенными приложениями для обмена сообщениями по модели опроса, и может использоваться для разделения отправляющего и получающего компонентов.
Распространенным примером является использование SNS для публикации сообщений в очередях Amazon SQS для надежной асинхронной отправки сообщений одному или нескольким системным компонентам. Ссылка с https://aws.amazon.com/sns/faqs/