Jaka jest różnica między Amazon SNS a Amazon SQS?


438

Nie rozumiem, kiedy używałbym SNS kontra SQS i dlaczego zawsze są one połączone razem?


To, co rozumiem z twojego komentarza, zostało opisane w poniższym tekście. Czy to prawda? Wydawca -> SNS -> SQL (przechowywanie wiadomości w kolejce) -> Subskrybent (aktualnie offline)
friendyogi 28.10.2013


@friendyogi masz na myśli SQS, a nie SQL?
elena

Odpowiedzi:


624

SNS to rozproszony system publikowania i subskrybowania . Wiadomości są popychany do abonentów, jak i kiedy są one wysyłane przez wydawców do SNS.

SQS to rozproszony system kolejkowania . Wiadomości NIE są przekazywane do odbiorców. Odbiorcy muszą odpytywać lub pobierać wiadomości z SQS . Wiadomości nie mogą być odbierane przez wiele odbiorców jednocześnie. Każdy odbiorca może otrzymać wiadomość, przetworzyć ją i usunąć. Inne odbiorniki nie otrzymają później tej samej wiadomości. Odpytywanie nieodłącznie wprowadza pewne opóźnienia w dostarczaniu wiadomości w SQS, w przeciwieństwie do SNS, gdzie wiadomości są natychmiast przekazywane do subskrybentów. SNS obsługuje kilka punktów końcowych, takich jak e-mail, sms, punkt końcowy http i SQS. Jeśli chcesz otrzymać nieznaną liczbę i typ subskrybentów, potrzebujesz SNS.

Nie musisz zawsze łączyć SNS i SQS. SNS może wysyłać wiadomości na adres e-mail, SMS lub punkt końcowy HTTP oprócz SQS. Połączenie SNS z SQS ma zalety. Możesz nie chcieć, aby usługa zewnętrzna nawiązywała połączenia z Twoimi hostami (zapora może blokować wszystkie połączenia przychodzące do Twojego hosta z zewnątrz). Twój punkt końcowy może po prostu umrzeć z powodu dużej ilości wiadomości. E-mail i SMS mogą nie być szybkim sposobem przetwarzania wiadomości. Łącząc SNS z SQS, możesz odbierać wiadomości w swoim tempie. Pozwala klientom być w trybie offline, tolerować awarie sieci i hosta. Uzyskujesz również gwarancję dostawy. Jeśli skonfigurujesz SNS do wysyłania wiadomości do punktu końcowego http, wiadomości e-mail lub SMS, kilka niepowodzeń w wysyłaniu wiadomości może spowodować usunięcie wiadomości.

SQS służy głównie do oddzielania aplikacji lub integracji aplikacji. Wiadomości mogą być przechowywane w SQS przez krótki czas (maksymalnie 14 dni). SNS dystrybuuje kilka kopii wiadomości do kilku subskrybentów. Załóżmy na przykład, że chcesz zreplikować dane wygenerowane przez aplikację do kilku systemów pamięci masowej. Możesz użyć SNS i wysłać te dane do wielu subskrybentów, z których każdy replikuje otrzymane wiadomości do różnych systemów pamięci masowej (s3, dysk twardy na hoście, baza danych itp.).


3
więc w zasadzie, aby zaimplementować coś w rodzaju powiadomień wypychanych, zaleca się używanie SNS i SQS, aby wypychania za pomocą sns były kolejkowane, dopóki użytkownik nie będzie ich pobierał z kolejki? Czy możliwe jest utworzenie kolejki dla użytkownika?
Nick Ginanto,

2
Tak. Możesz mieć tyle subskrybentów, ile chcesz dla SNS. Możesz wysyłać powiadomienia do wielu kolejek.
Srikanth,

Cześć przepraszam, widzę, że to pytanie jest stare, ale zastanawiam się, czy SQS zna i przechowuje wiadomości offline? Ponieważ APNS nie przechowują wiadomości offline, tylko najnowsza wiadomość. Czy wiedziałby, kiedy urządzenia IOS są w trybie offline i od razu przechowuje wiadomości offline? I wyślesz go później, gdy urządzenia będą ponownie w trybie online?
John

2
@NickGinanto Kolejka na użytkownika prawdopodobnie nie jest tym, czego chcesz. Prawdopodobnie potrzebujesz jednej kolejki dla każdej usługi, która następnie obsługuje wiadomości specyficzne dla użytkownika. Ten schemat może pomóc: aws.amazon.com/blogs/aws/…
Trenton

2
Należy prawdopodobnie zauważyć, że od połowy 2018 r. SQS może wyzwalać lambdas i dlatego w tym przypadku jest bardziej podobny do pubu.
cyberwombat

238

Oto porównanie tych dwóch:

Typ encji

  • SQS: Kolejka (podobna do JMS)
  • SNS: Temat (system Pub / Sub)

Zużycie wiadomości

  • SQS: Pull Mechanism - konsumenci odpytują i pobierają wiadomości z SQS
  • SNS: Mechanizm push - SNS Przesyła wiadomości do konsumentów

Przypadek użycia

  • SQS: Oddzielenie 2 aplikacji i umożliwienie równoległego przetwarzania asynchronicznego
  • SNS: Fanout - Przetwarzanie tej samej wiadomości na wiele sposobów

Trwałość

  • SQS: Wiadomości są utrwalane przez pewien czas (konfigurowalny), jeśli żaden konsument nie jest dostępny
  • SNS: Brak wytrwałości. W zależności od tego, który konsument będzie obecny w momencie nadejścia wiadomości, wiadomość zostanie odebrana, a wiadomość zostanie usunięta. Jeśli nie ma dostępnych klientów, wiadomość zostaje utracona.

Rodzaj konsumenta

  • SQS: Wszyscy konsumenci powinni być identyczni i dlatego przetwarzają wiadomości dokładnie w ten sam sposób
  • SNS: Klienci mogą przetwarzać wiadomości na różne sposoby

Przykładowe aplikacje

  • SQS: Struktura zadań: zadania są przesyłane do SQS, a klienci na drugim końcu mogą przetwarzać zadania asynchronicznie. Jeśli częstotliwość zadań wzrośnie, liczbę odbiorców można po prostu zwiększyć, aby uzyskać lepszą przepustowość.
  • SNS: Przetwarzanie obrazu. Jeśli ktoś prześle zdjęcie do S3, a następnie znak wodny tego obrazu, utwórz miniaturę, a także wyślij wiadomość e-mail z podziękowaniami. W takim przypadku S3 może publikować powiadomienia w temacie SNS, przy czym 3 konsumentów go słucha. Pierwszy znak wodny na obrazie, drugi tworzy miniaturę, a trzeci wysyła wiadomość e-mail z podziękowaniami. Wszyscy otrzymują tę samą wiadomość (adres URL obrazu) i przetwarzają je równolegle.

1
jeśli nie ma dostępnych konsumentów, istnieje mechanizm ponownej próby, nawet domyślna wartość to 10 prób.
Arpit Solanki

Niezły szczegółowy post. Mamy różne komunikaty dla różnych konsumentów - Co powinniśmy zrobić - używać SNS i definiować różne tematy lub używać SQS i definiować różne kolejki? Temat / kolejka może jednak mieć jednego lub więcej konsumentów.
Andy Dufresne,

Jeśli twoim wymaganiem jest, aby twoja kolejka / klientka miała więcej niż jednego konsumenta, zakładam, że mówisz, że ta sama wiadomość powinna być nadawana do wielu konsumentów ... A jeśli moje założenie jest prawidłowe, to użycie SNS jest jedyną dostępną opcją dla ty
Arafat Nalkhande

Nie sądzę, że „SQS: wszyscy konsumenci powinni być identyczni i dlatego przetwarzają wiadomości dokładnie w ten sam sposób”, to prawda. Użyłem SQS, gdzie dwie różne usługi AWS pobierają z kolejki SQS i przetwarzają komunikat na swój własny sposób (inna logika aplikacji w tych różnych usługach). Czy coś brakuje?
nad

@ nad Będę musiał zrozumieć Twój przypadek użycia, ale dla mnie nie ma sensu, aby 2 konsumentów SQS przetwarzało wiadomości w nieidentyczny sposób. Jest to przypadek użycia dla SNS
Arafat Nalkhande

31

Z aws doc:

Usługa Amazon SNS umożliwia aplikacjom wysyłanie krytycznych czasowo wiadomości do wielu subskrybentów za pośrednictwem mechanizmu „push”, co eliminuje potrzebę okresowego sprawdzania lub „odpytywania” aktualizacji.

Amazon SQS to usługa kolejki wiadomości używana przez aplikacje rozproszone do wymiany wiadomości za pomocą modelu odpytywania i może być używana do oddzielania wysyłania i odbierania komponentów - bez konieczności jednoczesnego udostępniania każdego komponentu.

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


30

Odpowiedzi na ten wątek są trochę nieaktualne, więc postanowiłem dodać do niego moje dwa centy:

Możesz zobaczyć SNS jako tradycyjny temat, który może mieć wielu subskrybentów. Możesz mieć heterogenicznych subskrybentów dla jednego danego tematu SNS, w tym na przykład Lambda i SQS. Możesz również wysyłać wiadomości SMS, a nawet e-maile z pudełka za pomocą SNS. W SNS należy wziąć pod uwagę tylko jedną wiadomość (powiadomienie) otrzymywaną jednocześnie, więc nie można skorzystać z partii.

Z drugiej strony SQS to nic innego jak kolejka, w której przechowujesz wiadomości i subskrybujesz jednego konsumenta (tak, możesz mieć N konsumentów do jednej kolejki SQS, ale byłoby bardzo szybko bałagan i znacznie trudniej zarządzać, biorąc pod uwagę, że wszyscy konsumenci by to zrobili trzeba przeczytać wiadomość przynajmniej raz, więc lepiej jest skorzystać z SNS w połączeniu z SQS w tym przypadku użycia, w którym SNS wypychałby powiadomienia do N kolejek SQS, a każda kolejka miałaby tylko jednego subskrybenta, tylko w celu przetworzenia tych komunikatów. Od 28 czerwca 2018 r. AWS obsługuje wyzwalacze Lambda dla SQS , co oznacza, że ​​nie musisz sondowaćdla wiadomości już. Ponadto można skonfigurować DLQ w źródłowej kolejce SQS, aby wysyłać wiadomości w przypadku awarii. W przypadku powodzenia wiadomości są automatycznie usuwane (jest to kolejna wielka poprawa), więc nie musisz się martwić, że już przetworzone wiadomości zostaną ponownie odczytane, na wypadek gdybyś zapomniał je usunąć ręcznie. Proponuję rzucić okiem na zachowanie Lambda Retry Behavioraby lepiej zrozumieć, jak to działa. Jedną wielką zaletą korzystania z SQS jest to, że umożliwia przetwarzanie wsadowe. Każda partia może zawierać do 10 wiadomości, więc jeśli 100 wiadomości pojawi się jednocześnie w kolejce SQS, wówczas 10 funkcji Lambda zostanie uruchomionych (biorąc pod uwagę domyślne zachowanie automatycznego skalowania dla Lambda) i przetworzą te 100 wiadomości (pozostań w pamiętaj, że jest to szczęśliwa ścieżka, ponieważ w praktyce kilka innych funkcji Lambda może się zakłócać, czytając mniej niż 10 wiadomości w partii, ale masz pomysł). Jeśli jednak opublikujesz te same 100 wiadomości w SNS, uruchomi się 100 funkcji Lambda, niepotrzebnie zwiększając koszty i wykorzystując współbieżność Lambda. Jeśli jednak nadal używasz tradycyjnych serwerów (takich jak instancje EC2), nadal będziesz musiał sondować wiadomości i zarządzać nimi ręcznie.

Masz również kolejki FIFO SQS , które gwarantują kolejność dostarczania wiadomości. Nie jest to obsługiwane przez Lambda wyzwalacz, dlatego wybierając ten typ kolejki pamiętaj, że odpytywanie jest nadal konieczne, a także konieczność ręcznego usuwania wiadomości.

Chociaż w ich przypadkach użycia występuje pewne nakładanie się, zarówno SQS, jak i SNS mają swoje własne centrum uwagi.

Użyj SNS, jeśli:

  • wielu subskrybentów jest wymogiem
  • przydatne jest wysyłanie wiadomości SMS / e-mail z pudełka

Użyj SQS, jeśli:

  • potrzebny jest tylko jeden subskrybent
  • dozowanie jest ważne

29

AWS SNS to sieć subskrybentów wydawcy, w której subskrybenci mogą subskrybować tematy i będą otrzymywać wiadomości za każdym razem, gdy wydawca opublikuje ten temat.

AWS SQS to usługa kolejkowa, która przechowuje wiadomości w kolejce. SQS nie może dostarczyć żadnych komunikatów, w których potrzebna jest usługa zewnętrzna (lambda, EC2 itp.), Aby sondować SQS i pobierać wiadomości z SQS.

SNS i SQS mogą być używane razem z wielu powodów.

  1. Mogą istnieć różne rodzaje subskrybentów, w przypadku których niektórzy potrzebują natychmiastowego dostarczenia wiadomości, w przypadku których niektórzy będą wymagać trwałej wiadomości, do późniejszego wykorzystania przez odpytywanie. Zobacz ten link .

  2. Wzorzec fanouta ”. Służy to asynchronicznemu przetwarzaniu wiadomości. Gdy wiadomość jest publikowana w SNS, może ona równolegle dystrybuować ją do wielu kolejek SQS. Może to być świetne, gdy równolegle ładuje się miniatury w aplikacji, gdy obrazy są publikowane. Zobacz ten link .

  3. Trwałe przechowywanie . Gdy usługa, która ma przetworzyć komunikat, nie jest niezawodna. W takim przypadku, jeśli SNS przekaże powiadomienie do Usługi, a ta usługa będzie niedostępna, powiadomienie zostanie utracone. Dlatego możemy użyć SQS jako trwałego magazynu, a następnie przetworzyć go później.


4

Mówiąc najprościej, SNS - wysyła wiadomości do subskrybenta za pomocą mechanizmu push i nie wymaga ściągania. SQS - jest to usługa kolejki wiadomości używana przez aplikacje rozproszone do wymiany wiadomości za pomocą modelu odpytywania i może być używana do oddzielania wysyłania i odbierania komponentów.

Częstym wzorcem jest używanie SNS do publikowania komunikatów w kolejkach Amazon SQS w celu niezawodnego wysyłania komunikatów do jednego lub wielu komponentów systemu asynchronicznie. Odsyłacz z https://aws.amazon.com/sns/faqs/


SQS nie może wysłać wiadomości do wielu systemów, ponieważ nie rozkłada wiadomości. Tak, wielu ankieterów może pobrać z niego wiadomości, ale jeśli jeden z nich usunie wiadomość, inni subskrybenci nie będą mogli ponownie użyć tej samej wiadomości. SNS jest preferowany w stosunku do SQS, jeśli chcesz osiągnąć wzorzec wentylatora. Ponadto, jeśli ta opcja visibilityTimeoutjest ustawiona, żaden inny system nie będzie w stanie odebrać wiadomości po przetworzeniu przez inny system.
Thales Minussi

Częstym wzorcem jest używanie SNS do publikowania komunikatów w kolejkach Amazon SQS w celu niezawodnego wysyłania komunikatów do jednego lub wielu komponentów systemu asynchronicznie. Referencje od aws.amazon.com/sns/faqs
Krunal Barot

Jeśli to właśnie miałeś na myśli (SNS -> wiele kolejek SQS), edytuj swoją odpowiedź, a ja z radością usunę moją opinię. Mówiąc tak, wygląda na to, że SQS może się rozprężyć.
Thales Minussi

1
Tak ... tam zamieszanie. Zredagowałem to .. Dzięki :)
Krunal Barot
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.