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

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

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.).

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.

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

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

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.

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/