В чем разница между Amazon SNS и Amazon SQS?

439

Я не понимаю, когда я буду использовать SNS против SQS, и почему они всегда связаны друг с другом?

Ник Джинанто
источник
Что я понимаю из вашего комментария описано в следующем потоке .. это правильно? Издатель -> SNS -> SQL (хранение сообщений в очереди) -> Подписчик (в настоящее время не в сети)
friendyogi
4
aws.amazon.com/blogs/aws/…
Маниш Джайн
@friendyogi Вы имеете в виду SQS, а не SQL?
елена

Ответы:

626

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, жесткий диск на вашем хосте, база данных и т. Д.).

Srikanth
источник
3
так что для реализации чего-то вроде push-уведомлений рекомендуется использовать SNS и SQS, чтобы push-сообщения с sns были поставлены в очередь до тех пор, пока пользователь не получит их только из очереди? Можно ли создать очередь для каждого пользователя?
Ник Джинанто
2
Да. Вы можете иметь столько подписчиков, сколько хотите для SNS. Вы можете получать уведомления в несколько очередей.
Срикант
Привет, извините, я вижу, что этот вопрос старый, но мне интересно, что SQS знает и хранит офлайн-сообщения? Поскольку APNS не хранит автономные сообщения, только самое новое сообщение. Будет ли он знать, когда устройства IOS находятся в автономном режиме и сразу же сохраняют автономные сообщения? И отправить его позже, когда устройства снова подключатся?
Джон
2
@NickGinanto Очередь на пользователя, вероятно, не то, что вы хотите. Возможно, вы захотите одну очередь для каждой службы, которая затем обрабатывает пользовательские сообщения. Эта диаграмма может помочь: aws.amazon.com/blogs/aws/…
Трентон,
2
Вероятно, следует отметить, что по состоянию на середину 2018 года SQS может запускать лямбды и поэтому в этом случае больше похож на pubsub.
Кибервомбат
239

Вот сравнение двух:

Тип объекта

  • 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-адрес изображения) и выполняют их обработку параллельно.
Арафат Налханде
источник
1
если нет доступных потребителей, то существует механизм повторных попыток, даже значение по умолчанию равно 10 повторным попыткам.
Арпит Соланки
Хороший подробный пост. У нас разные сообщения для разных потребителей - что нам делать - использовать SNS и определять разные темы или использовать SQS и определять разные очереди? Тем не менее, тема / очередь может иметь одного или нескольких потребителей.
Энди Дюфрен
Если вы требуете, чтобы в вашем томе / очереди было более одного потребителя, я предполагаю, что вы говорите, что одно и то же сообщение должно быть передано нескольким потребителям ... И если мое предположение верно, то использование SNS является единственным доступным Вы
Арафат Налханде
Я не думаю, что «SQS: все потребители должны быть идентичными и, следовательно, обрабатывать сообщения одинаково», это правильно. Я использовал SQS, где две разные службы AWS выбирают из очереди SQS и обрабатывают сообщение по-своему (разная логика приложения в этих разных службах). Я что-то пропустил?
над
@ nad Мне нужно понять ваш вариант использования, но для меня нет смысла, что 2 потребителя SQS обрабатывают сообщения неидентичным образом. Это пример использования SNS
Арафат Налханде
31

Из aws doc:

Amazon SNS позволяет приложениям отправлять срочные сообщения нескольким подписчикам с помощью «push-» механизма, что устраняет необходимость периодически проверять или «запрашивать» обновления.

Amazon SQS - это служба очереди сообщений, используемая распределенными приложениями для обмена сообщениями по модели опроса, и может использоваться для разделения отправляющих и принимающих компонентов, не требуя одновременного доступа к каждому компоненту.

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

Томми
источник
30

Ответы в этой теме немного устарели, поэтому я решил добавить к ней два цента:

Вы можете видеть 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, если:

  • нужен только один подписчик
  • дозирование важно
Фалес Минусси
источник
29

AWS SNS - это сеть подписчиков издателей, где подписчики могут подписываться на темы и будут получать сообщения всякий раз, когда издатель публикует эту тему.

AWS SQS - это служба очереди, которая хранит сообщения в очереди. SQS не может доставлять сообщения, если для опроса SQS и получения сообщений от SQS необходима внешняя служба (лямбда, EC2 и т. Д.).

SNS и SQS могут использоваться вместе по нескольким причинам.

  1. Могут быть подписчики разных типов, где некоторым требуется немедленная доставка сообщений, а некоторым потребуется сохранение сообщения для последующего использования посредством опроса. Смотрите эту ссылку .

  2. « Шаблон разветвления ». Это для асинхронной обработки сообщений. Когда сообщение публикуется в SNS, оно может распределить его по нескольким очередям SQS параллельно. Это может быть полезно при параллельной загрузке миниатюр в приложении, когда изображения публикуются. Смотрите эту ссылку .

  3. Постоянное хранение . Когда служба, которая собирается обрабатывать сообщение, не является надежной. В таком случае, если SNS отправляет уведомление в службу, и эта служба недоступна, уведомление будет потеряно. Поэтому мы можем использовать SQS в качестве постоянного хранилища, а затем обрабатывать его.

Кит Сугатхадаса
источник
4

Говоря простым языком, SNS - отправляет сообщения абоненту с использованием механизма push и без необходимости извлечения. SQS - это служба очереди сообщений, используемая распределенными приложениями для обмена сообщениями по модели опроса, и может использоваться для разделения отправляющего и получающего компонентов.

Распространенным примером является использование SNS для публикации сообщений в очередях Amazon SQS для надежной асинхронной отправки сообщений одному или нескольким системным компонентам. Ссылка с https://aws.amazon.com/sns/faqs/

Крунал Барот
источник
SQS не может отправлять сообщения многим системам, поскольку они не распределяют сообщения. Да, многие опрашивающие могут извлекать из него сообщения, но если один из потребителей удалит сообщение, другие подписчики не смогут снова использовать это сообщение. SNS предпочтительнее, чем SQS, если вы хотите добиться разветвления. Кроме того, если visibilityTimeoutустановлено, то никакие другие системы не смогут использовать сообщение после его обработки другой системой.
Фалес Минусси
Распространенным примером является использование SNS для публикации сообщений в очередях Amazon SQS для надежной асинхронной отправки сообщений одному или нескольким системным компонентам. Ссылка от aws.amazon.com/sns/faqs
Крунал Барот
Если это то, что вы имели в виду (SNS -> несколько очередей SQS), то, пожалуйста, отредактируйте свой ответ, и я с удовольствием удалю свое отрицательное голосование. Как вы говорите, SQS может развалиться.
Фалес Минусси
1
Да .. вот где путаница была. Я отредактировал это .. Спасибо :)
Крунал Барот