Muszę utworzyć kolejkę do przetwarzania. Sama kolejka jest stosunkowo niewielka. Może być około 1000 zapisów na godzinę. Wykonanie każdego zadania może zająć około minuty i jest przetwarzane niemal natychmiast po dodaniu elementu do kolejki.
Czy jest jakiś powód, dla którego mógłbym chcieć wdrożyć RabbitMQ zamiast czegoś gotowego, takiego jak Amazon SQS? Z jakich powodów aplikacja potrzebuje własnego systemu kolejkowania zamiast czegoś w rodzaju SQS?
Odpowiedzi:
Na początek Amazon SQS jest pseudo-kolejką, co oznacza, że dostarczenie każdej wiadomości (jeśli dotrze do kolejki) jest gwarantowane, ale nie w sposób FIFO, który zwykle ma miejsce w kolejce.
Jeśli kolejność wiadomości jest dla Ciebie ważna i chcesz, aby kolejka działała w sposób FIFO, dokumentacja Amazon SQS stwierdza, że należy to załatwić w logice aplikacji, ponieważ wiadomości z Amazon SQS będą docierać do Ciebie poza kolejnością.
W porównaniu z tym, o ile wiem, możesz zaimplementować kolejki robocze w RabbitMQ. Jeśli to pozbawia Cię implementacji sekwencjonowania komunikatów w kolejce na poziomie aplikacji, byłaby to bardziej preferowana opcja.
Oto kilka czynników, które pomogą Ci zdecydować, który z nich wybrać:
Kolejka wiadomości, jak wspomniano powyżej.
Możesz skonfigurować swój własny serwer z RabbitMQ, ale nie w przypadku Amazon SQS, więc koszty są tutaj zaangażowane.
Skonfigurowanie własnego serwera będzie wymagało dobrej znajomości tematu, aby nie pozostawić żadnego zakątka nietkniętego. Tak nie jest w przypadku Amazon SQS, ponieważ można zacząć z nim dość szybko.
Twój własny serwer RabbitMQ oznacza niższe koszty utrzymania, co nie ma miejsca w przypadku Amazon SQS.
Aktualizacje:
SQS byłby moim lepszym rozwiązaniem niż RabbitMQ, oto dlaczego.
Jednak RabbitMQ może zapewnić szybsze czasy odpowiedzi dla operacji typu put and get, zazwyczaj w ciągu 10 tysięcy TPS z moich testów. Aby SQS mógł zapewnić taką przepustowość, będziesz musiał skalować w górę w poziomie z wieloma instancjami. Więc jeśli szukasz opcji put poniżej 5 ms, RabbitMQ może być opcją do rozważenia, ponieważ widziałem czas spędzony w moich testach SQS na 1000 s TPS, który jest nieco wyższy niż RabbitMQ.
Właśnie przenieśliśmy naszą infrastrukturę obsługi wiadomości z ActiveMQ do SQS i nie możemy być szczęśliwsi. Okazało się, że jest to tańsze niż utrzymywanie własnego klastra ActiveMQ w chmurze.
Mam nadzieję że to pomoże! Daj nam znać, jak leci ...
Właściwie użyłem obu w środowisku komercyjnym z rozsądnym.
Krótka odpowiedź brzmi: jeśli nie ma konkretnych przypadków narożnych, lepiej wybrać AWS SQS. (Możesz przejść do dołu, aby uzyskać proste podsumowanie)
Kodowanie (Tie): RabbitMQ i AWS SQS mają ustanowione biblioteki i mnóstwo przykładów.
Limit czasu widoczności (SQS): Jedną z rzeczy, które SQS oferuje w porównaniu z RabbitMQ, jest szersze pojęcie limitu czasu widoczności. W RabbitMQ, jeśli konsument umiera przed zniszczeniem, komunikaty są umieszczane z powrotem w kolejce. Ale SQS ma szersze pojęcie limitu czasu widoczności, który nie jest powiązany z konkretnym dzwoniącym. Możesz więc rozpocząć jednostkę pracy, ustawić widoczność z dużym limitem czasu (do 12 godzin), rozłączyć się, zlecić innemu pracownikowi zakończenie i potwierdzenie. W moim projekcie wykorzystujemy to w dużym stopniu i wyeliminowaliśmy dodatkową usługę / pamięć masową, aby zarządzać potencjalnie dużymi ładunkami „w toku”.
Obsługa utraconych wiadomości (RabbitMQ - przez „zająca”) Usługa SQS zapewnia podstawowe przekazywanie utraconych wiadomości w ramach tego, co nazywają „polityką ponownego napędu”, która zrzuca wiadomości do kolejki utraconych wiadomości (po prostu kolejki). Jest podstawowy i ma tylko pojęcie liczby wiadomości. RabbitMQ ma możliwość wymiany utraconych wiadomości, która zapewnia komunikaty wypychane w DLE po ich wygaśnięciu. Ale jest to trochę dyskusyjne, ponieważ pomysł „Jeśli nie oglądasz, wygasają Twoje usługi i wiadomości, wylądują w DLE”. To niewielka wygrana dla RabbitMQ, ponieważ uważam, że ten argument jest sprzeczny z intuicją. Dlaczego miałbyś monitorować swoją kolejkę, a nie swoje usługi? (Jeśli już, to na odwrót)
Administracja (SQS): SQS nie podlega administracji. Po prostu płacisz za wywołania API. Wszystkie typowe bóle głowy, takie jak poprawki bezpieczeństwa systemu operacyjnego / aplikacji, skalowanie (dodawanie więcej węzłów), dysk są obsługiwane przez zespoły AWS. Jest również zgodny z FedRamp (do użytku rządowego). To naprawdę system typu „skonfiguruj i zapomnij”. Gdzie RabbitMQ wymaga zwykłych poprawek systemu operacyjnego / usług, AMI, klastrowania, wzmacniania zabezpieczeń itp. Chociaż jest to niezwykle rzadkie, AMI może ulec awarii lub czasami wymagać przeniesienia, więc klastrowanie jest potrzebne po wyjęciu z pudełka. SQS eliminuje wszystkie te bóle głowy.
KOSZT (SQS): pojedyncze wywołanie interfejsu API SQS może obejmować „pakiet do 10 wiadomości / rozmiar 256 KB”, a „długie odpytywanie” może drastycznie obniżyć koszty. Co więcej, istnieją strategie, takie jak kompresja wiadomości w celu umieszczenia dziesiątek (niektórzy twierdzą, że setki lub więcej) wiadomości mogą być wysyłane w jednym ładunku, aby jeszcze bardziej obniżyć koszty. I to zanim rozważymy czas, który ludzie spędzają na monitorowaniu / poprawianiu / naprawianiu problemów. SQS świetnie nadaje się również do „projektów poc”, jakby bezczynnie, bez żadnych kosztów.
FIFO (TIE): W 2016 roku AWS wprowadziło obsługę FIFO za dodatkowym kosztem ~ 0,01 USD / milion wywołań API (0,05 USD w porównaniu z 0,04 USD za milion wszystkich interfejsów API - bez rabatów). Możesz wybrać FIFO lub nie. W przypadku innych niż FIFO rzadko widzimy zduplikowane wiadomości.
Przechowywanie (SQS): AWS nie pobiera opłat za przechowywanie, ale masz limit 14 dni. W RabbitMQ będziesz musiał przydzielić, rozszerzyć i zarządzać przestrzenią dyskową, która wymaga szczytowej pojemności pamięci plus dodatkowe bufory. To tylko więcej bólów głowy.
Metryki (SQS): SQS zapewnia metryki gotowe. I chociaż możesz dodać je do AWS, to po prostu więcej pracy.
Lokalny deweloper (krawat): Większość nowoczesnych sklepów lubi mieć lokalne środowisko. Istnieje kilka opcji, które pozwalają teraz na dokowanie RabbitMQ i SQS.
Wysoka przepustowość / bardzo duża wiadomość (RabbitMQ - coś w rodzaju) Gdy przekażesz SQS> 1000 żądań / s, opóźnienie SQS wzrośnie. Istnieje kilka strategii obejścia tego problemu. Ale uważam, że te przypadki są niezwykle rzadkie, ponieważ większość pracy można podzielić na wiele kolejek. Ale dla tego typu przypadków, w których wymagane jest 100k / s, myślę, że Kafka jest lepszy. (W mojej pracy używamy również Kafki) Rzadko zdarza się, aby pojedyncza jednostka pracy wymagała ponad 1000 żądań / sekundę z małym opóźnieniem. * Więcej informacji znajdziesz poniżej
Podsumowanie: Jeśli zamierzasz być w AWS i chcesz poślubić SQS, to SQS jest nie do pomyślenia. Ale powinieneś czytać dalej, ponieważ należy wziąć pod uwagę ważne kwestie.
Klasyczna strategia RabbitMQ (i innych kolejek) polega na tworzeniu kilku typów kolejek zoptymalizowanych pod kątem określonych rodzajów pracy. Następnie dostrój każdą z tych kolejek i zgrupuj podobną pracę w niewielką liczbę tych (często bardzo dużych) kolejek. Ponieważ SQS nie ma narzutu administracyjnego, w rzeczywistości lepiej jest przydzielić dedykowaną kolejkę do każdej pracy. W ten sposób pozwala na skalowanie, ale także eliminuje nasycenie kolejki (obrażająca praca nasycająca kolejkę i zagłuszanie innych pracowników), lepszy wgląd w pracę (domyślne metryki) i tym podobne.
Nowa strategia umożliwiła moim zespołom lepszy wgląd w rozkład pracy. Dawno minęły czasy „ulepszania instancji w celu zwiększenia obciążenia”. W przeszłości widzielibyśmy duży niewyjaśniony wzrost, który powodowałby skutki uboczne w innych usługach lub po prostu przypuszczaliśmy, że skumulowane liczby wyglądają na prawidłowe ”. Teraz, gdy ruch jest oddzielony, w rzeczywistości odkryliśmy wiele problemów, które wcześniej pozostawały niezauważone i możemy jasno wyjaśnić, jaki ruch jest w jakim kierunku. I chociaż wdrożenie metryk i narzędzi jest bardzo możliwe, SQS zapewnia je wszystkie od razu.
Nadal istnieją duże przypadki, w których RabbitMQ należy poważnie rozważyć
- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.
Jeśli jesteś wrażliwy na koszty, Amazon SQS prawdopodobnie będzie droższy. Mówię, że prawdopodobnie dlatego, że nadal musisz gdzieś hostować swój serwer RabbitMQ. SQS bezpłatnie udostępnia pierwszy milion żądań, a następnie pobiera opłatę w wysokości 0,4 USD za milion żądań. Istnieje jednak sztuczka polegająca na zmniejszeniu kosztów za pomocą SQS poprzez włączenie długiego odpytywania, tj. Ustawienie czasu odbioru wiadomości na 20 sekund. Nie oznacza to, że Twoje wiadomości będą wysyłane tylko co 20 sekund, oznacza to raczej, że SQS nie obciąży Cię „żądaniem”, jeśli kolejka jest pusta (co 20 sekund).
Jeśli używasz 1000 żądań na godzinę, to 744000 miesięcznie. Bezpłatnie w ramach poziomu bezpłatnego i około 0,74 * 0,4 USD = 0,2976 USD poza poziomem. Który prawdopodobnie można by jeszcze bardziej skrócić, włączając czas oczekiwania. Więc w twoim przypadku SQS może faktycznie działać taniej, ponieważ większość hostingu zaczyna się od minimum 5 USD (chyba że masz darmowy poziom EC2 od AWS). Powinno być dobrze z najmniejszą opcją, ponieważ RMQ zaleca tylko około 128 MB pamięci RAM.
Uważam, że SQS jest dużo bardziej przyjazny dla użytkownika, a RabbitMQ bardziej techniczny, jeśli masz takie skłonności.
Aktualizacja:
Właściwie uważam, że AWS Simple Notification Service jest bardziej odpowiedni dla tego, czego potrzebowałem https://stackoverflow.com/a/13692720/5403449, głównie dlatego, że jest oparty na wypychaniu, czyli nie odpytywaniu