Kolejki Rabbita znajdują się w pamięci i dlatego będą znacznie szybsze niż implementacja tego w bazie danych. (Dobra) dedykowana kolejka wiadomości powinna również zapewniać podstawowe funkcje związane z kolejkowaniem, takie jak ograniczanie/kontrola przepływu oraz możliwość wyboru różnych algorytmów routingu, aby wymienić parę (królik zapewnia te i więcej). W zależności od rozmiaru projektu, możesz również chcieć, aby komponent przekazujący wiadomości był oddzielony od bazy danych, tak aby w przypadku dużego obciążenia jednego komponentu nie przeszkadzał on w działaniu drugiego.
Jeśli chodzi o problemy, o których wspomniałeś:
-
odpytywanie, dzięki któremu baza danych jest zajęta i ma niską wydajność :Używając Rabbitmq, producenci mogą wypychać aktualizacje dla konsumentów, co jest znacznie bardziej wydajne niż ankiety. Dane są po prostu wysyłane do konsumenta, gdy jest to konieczne, eliminując potrzebę niepotrzebnych kontroli.
-
zablokowanie stołu -> znowu niska wydajność: Nie ma stołu do zablokowania :P
-
miliony wierszy zadań -> ponownie sondowanie jest mało wydajne: Jak wspomniano powyżej, Rabbitmq będzie działał szybciej, ponieważ znajduje się w pamięci RAM i zapewnia kontrolę przepływu. W razie potrzeby może również użyć dysku do tymczasowego przechowywania wiadomości, jeśli zabraknie mu pamięci RAM. Po wersji 2.0 Rabbit znacznie poprawił wykorzystanie pamięci RAM. Dostępne są również opcje klastrowania.
W odniesieniu do AMQP powiedziałbym, że naprawdę fajną funkcją jest „giełda” i możliwość jej przekierowania na inne giełdy. Zapewnia to większą elastyczność i umożliwia tworzenie szerokiej gamy skomplikowanych typologii routingu, które mogą być bardzo przydatne podczas skalowania. Aby zapoznać się z dobrym przykładem, zobacz:
(źródło:springsource.com)
oraz:http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/
Wreszcie, jeśli chodzi o Redis, tak, może być używany jako broker komunikatów i może dobrze sobie radzić. Jednak Rabbitmq ma więcej funkcji kolejkowania wiadomości niż Redis, ponieważ Rabbitmq został zbudowany od podstaw jako w pełni funkcjonalna dedykowana kolejka wiadomości na poziomie przedsiębiorstwa. Z drugiej strony Redis został stworzony przede wszystkim jako magazyn wartości klucza w pamięci (choć teraz robi znacznie więcej; jest nawet określany jako szwajcarski scyzoryk). Mimo to czytałem/słyszałem wiele osób osiągających dobre wyniki dzięki Redis w przypadku mniejszych projektów, ale niewiele o tym słyszałem w większych aplikacjach.
Oto przykład użycia Redisa w implementacji czatu z długim sondażem:http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/
