Яка різниця між Amazon SNS та Amazon SQS?

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

SNS - це розподілена система публікації та підписки . Повідомлення штовхнули абонент , як і коли вони відправляються видавцями SNS.

SQS - це розподілена система черги . Повідомлення НЕ підштовхуються до приймачів. Одержувачі повинні опитувати або витягувати повідомлення з SQS . Повідомлення не можуть прийматись декількома приймачами одночасно. Будь-який один одержувач може отримати повідомлення, обробити його та видалити. Інші приймачі не отримують те саме повідомлення пізніше. Опитування за своєю суттю вводить деяку затримку в доставці повідомлень у SQS на відміну від SNS, де повідомлення негайно надсилаються абонентам. SNS підтримує декілька кінцевих точок, таких як електронна пошта, sms, http кінцева точка та SQS. Якщо ви хочете, щоб невідома кількість та тип підписників отримували повідомлення, вам потрібен SNS.

Вам не доведеться завжди парувати SNS та SQS. Ви можете мати SNS надсилати повідомлення на електронну пошту, sms або http кінцеву точку крім SQS. Існують переваги в поєднанні SNS з SQS. Можливо, ви не хочете, щоб зовнішня служба встановлювала з'єднання з вашими хостами (брандмауер може блокувати всі вхідні з'єднання з вашим хостом ззовні). Ваша кінцева точка може просто загинути через велику кількість повідомлень. Електронна пошта та SMS можуть бути не вашим вибором швидко обробляти повідомлення. Поєднуючи SNS з SQS, ви можете отримувати повідомлення у своєму темпі. Це дозволяє клієнтам бути в автономному режимі, терпимими до відмов мережі та хоста. Ви також досягаєте гарантованої доставки. Якщо ви налаштуєте SNS для надсилання повідомлень на кінцеву точку http або електронну пошту чи SMS, кілька помилок надсилати повідомлення можуть призвести до відмови повідомлення.

SQS використовується в основному для деакуляції програм або інтеграції програм. Повідомлення можуть зберігатися в SQS протягом короткого часу (максимум 14 днів). SNS поширює кілька примірників повідомлення декільком підписникам. Наприклад, скажімо, що ви хочете копіювати дані, згенеровані програмою, в декілька систем зберігання. Ви можете використовувати SNS та надсилати ці дані декільком підписникам, кожен з яких повторює отримані повідомлення в різні системи зберігання даних (s3, жорсткий диск вашого хоста, база даних тощо).

Ось порівняння двох:

Тип особи

• SQS: Черга (аналогічно JMS)
• SNS: Тема (паб / підсистема)

Споживання повідомлення

• SQS: Механізм витягування - споживачі опитують і тягнуть повідомлення з SQS
• SNS: Механізм Push - SNS передає повідомлення споживачам

Використовуйте кейс

• SQS: Розв'язування 2 додатків і паралельна асинхронна обробка
• SNS: Fanout - обробка одного і того ж повідомлення декількома способами

Наполегливість

• SQS: Повідомлення зберігаються протягом певної (настроюваної) тривалості, якщо споживача немає
• SNS: Наполегливості немає. Незалежно від того, який споживач буде присутній під час надходження повідомлення, він отримує повідомлення та повідомлення видаляється. Якщо споживачів немає, повідомлення втрачається.

Тип споживача

• SQS: Усі споживачі повинні бути ідентичними, а отже, обробляти повідомлення точно таким же чином
• SNS: Споживачі можуть обробляти повідомлення різними способами

Зразки додатків

• SQS: Структура робочих місць: Вакансії надсилаються до SQS, а споживачі з іншого боку можуть обробляти завдання асинхронно. Якщо частота робочих місць збільшується, кількість споживачів може бути просто збільшена для досягнення кращої пропускної здатності.
• SNS: Обробка зображень. Якщо хтось завантажує зображення на S3, то нанесіть на нього водний знак, створіть мініатюру та також надішліть електронний лист з подякою. У такому випадку S3 може публікувати сповіщення на тему SNS з 3-ма споживачами, які слухають його. 1-ий зображує водяні знаки, другий створює мініатюру, а 3-й надсилає лист з подякою. Усі вони отримують одне і те ж повідомлення (URL-адреса зображення) і проводять їх обробку паралельно.

З aws doc:

Amazon SNS дозволяє програмам надсилати критичні за часом повідомлення численним абонентам через механізм "push", виключаючи необхідність періодично перевіряти або "опитувати" наявність оновлень.

Amazon SQS - це послуга черги повідомлень, яка використовується розподіленими програмами для обміну повідомленнями через модель опитування, і може використовуватися для деакуляції відправки та прийому компонентів, не вимагаючи одночасного доступу кожного компонента.

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

Відповіді на цю тему трохи застаріли, тому я вирішив додати до неї два центи:

Ви можете розглянути SNS як традиційну тему, яку ви можете мати декількох передплатників. Ви можете мати неоднорідних підписників на одну задану тему SNS, наприклад, Lambda та SQS, наприклад. Ви також можете надсилати SMS-повідомлення або навіть електронні листи з коробки за допомогою SNS. Одне, що слід враховувати в SNS - це лише одне повідомлення (повідомлення), яке отримується одразу, тож ви не можете скористатись перевагами в пакетній доставці.

SQS , з іншого боку, - це не що інше, як черга, де ви зберігаєте повідомлення та підписуєте одного споживача (так, ви можете мати N споживачів до однієї черги SQS, але це стане безладним дуже швидко і складніше керувати, враховуючи, що всі споживачі будуть Потрібно прочитати повідомлення хоча б один раз, щоб краще було користуватися SNS у поєднанні з SQS для цього випадку використання, коли SNS надсилатиме сповіщення до N SQS-черг, і кожна черга матиме лише одного підписника) для обробки цих повідомлень. Станом на 28 червня 2018 року AWS підтримує лямбда-тригери для SQS , тобто вам не доведеться опитуватидля повідомлень більше. Крім того, ви можете налаштувати DLQ у черзі джерела SQS для надсилання повідомлень у разі відмови. У разі успіху повідомлення автоматично видаляються (це ще одне велике поліпшення), тому вам не доведеться турбуватися про повторне читання вже оброблених повідомлень, якщо ви забули їх видалити вручну. Я пропоную поглянути на поведінку Ламбда Повторищоб краще зрозуміти, як це працює. Однією з найбільших переваг використання SQS є те, що вона дозволяє пакетну обробку. Кожна партія може містити до 10 повідомлень, тож якщо 100 повідомлень надійде одразу у вашу чергу SQS, то 10 функцій лямбда запуститься (враховуючи стандартну поведінку автоматичного масштабування для Lambda), і вони оброблять ці 100 повідомлень (тримати в Пам'ятайте, що це щасливий шлях, як на практиці, кілька інших функцій лямбда могли розкручувати читання менше, ніж 10 повідомлень у партії, але ви розумієте). Якщо ви опублікували ці 100 повідомлень в SNS, однак 100 функцій лямбда повернулися б, без необхідності збільшуючи витрати та використовуючи свою одночасність. Однак якщо ви все ще використовуєте традиційні сервери (наприклад, екземпляри EC2), вам все одно доведеться опитувати повідомлення та керувати ними вручну.

У вас також є черги на FIFO SQS , які гарантують порядок доставки повідомлень. Це не підтримується триггером Lambda, тому, вибираючи такий тип черги, майте на увазі, що опитування все ще необхідно, а також потрібно видаляти повідомлення вручну.

Незважаючи на те, що деякі випадки їх перекриття використовуються, і SQS, і SNS мають своє власне прожектор.

Використовуйте SNS, якщо:

• кілька абонентів - це вимога
• надсилання SMS / електронної пошти з коробки зручно

Використовуйте SQS, якщо:

• потрібен лише один абонент
• дозування важливо

AWS SNS - це мережа абонентів для видавців, де підписники можуть передплачувати теми та отримувати повідомлення, коли видавець публікує цю тему.

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

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

1. Можуть бути різні види передплатників, коли деяким потрібна негайна доставка повідомлень, де деякі вимагають збереження повідомлення для подальшого використання шляхом опитування. Дивіться це посилання .

2. " Шаблон фантазії ". Це для асинхронної обробки повідомлень. Коли повідомлення публікується в SNS, воно може паралельно розподіляти його на кілька черг SQS. Це може бути чудово, коли паралельно завантажувати ескізи в програму, коли зображення публікуються. Дивіться це посилання .

3. Стійке зберігання . Коли служба, яка збирається обробляти повідомлення, не є надійною. У такому випадку, якщо SNS надсилає сповіщення до Сервісу, а ця служба недоступна, повідомлення буде втрачено. Тому ми можемо використовувати SQS як постійне сховище, а потім обробляти його.

Простіше кажучи, SNS - відправляє повідомлення абоненту за допомогою механізму push і не потребує тягнення. SQS - це послуга черги повідомлень, яка використовується розподіленими програмами для обміну повідомленнями через модель опитування, і може використовуватися для деакуляції відправки та прийому компонентів.

Поширена схема - використання SNS для публікації повідомлень у черзі Amazon SQS для надійного надсилання повідомлень на один або багато системних компонентів асинхронно. Довідка з https://aws.amazon.com/sns/faqs/