Oto, co znalazłem, próbując odpowiedzieć na dokładnie to samo pytanie. Prawdopodobnie nie jest wyczerpujący, aw niektórych punktach może być nawet niedokładny.
Krótko mówiąc, RQ został zaprojektowany tak, aby był prostszy. Seler ma być bardziej wytrzymały. Obie są doskonałe.
- Dokumentacja. Dokumentacja RQ jest obszerna, ale nie jest złożona, i odzwierciedla ogólną prostotę projektu — nigdy nie czujesz się zagubiony ani zdezorientowany. Dokumentacja Celery jest również obszerna, ale spodziewaj się, że będziesz ją często odwiedzać, gdy po raz pierwszy ustawiasz, ponieważ jest zbyt wiele opcji do internalizacji
-
Monitorowanie. Celery's Flower i pulpit nawigacyjny RQ są bardzo proste w konfiguracji i zapewniają co najmniej 90% wszystkich informacji, jakich kiedykolwiek potrzebujesz
-
Wsparcie brokera. Seler jest wyraźnym zwycięzcą, RQ obsługuje tylko Redis. Oznacza to mniej dokumentacji na temat „czym jest broker”, ale także oznacza, że nie możesz zmienić brokera w przyszłości, jeśli Redis już dla Ciebie nie działa. Na przykład Instagram rozważał zarówno Redis, jak i RabbitMQ z Celery. Jest to ważne, ponieważ różni brokerzy mają różne gwarancje, m.in. Redis nie może (od momentu pisania) gwarantuje 100%, że Twoje wiadomości zostaną dostarczone.
-
Kolejki priorytetowe. Model kolejki priorytetowej RQs jest prosty i skuteczny - pracownicy czytają z kolejek w kolejności. Seler wymaga rozkręcenia wielu pracowników, aby konsumować z różnych kolejek. Oba podejścia działają
-
Wsparcie systemu operacyjnego. Seler jest tutaj wyraźnym zwycięzcą, ponieważ RQ działa tylko na systemach obsługujących
forknp. Systemy uniksowe -
Wsparcie językowe. RQ obsługuje tylko Pythona, podczas gdy Celery umożliwia wysyłanie zadań z jednego języka do innego
-
API. Celery jest niezwykle elastyczny (zaplecze z wieloma wynikami, ładny format konfiguracji, obsługa kanwy przepływu pracy), ale oczywiście ta moc może być myląca. Natomiast interfejs RQ jest prosty.
-
Obsługa podzadań. Celery obsługuje podzadania (np. tworzenie nowych zadań z istniejących zadań). Nie wiem, czy RQ ma
-
Społeczność i stabilność. Seler jest prawdopodobnie bardziej ugruntowany, ale oba są aktywnymi projektami. W chwili pisania, Celery ma około 3500 gwiazdek na Github, podczas gdy RQ ma około 2000, a oba projekty wykazują aktywny rozwój
Moim zdaniem Seler nie jest tak skomplikowany, jak jego reputacja może ci sugerować, ale będziesz musiał RTFM.
Dlaczego więc ktokolwiek miałby chcieć wymienić (prawdopodobnie bardziej w pełni funkcjonalnego) selera na RQ? Moim zdaniem wszystko sprowadza się do prostoty. Ograniczając się do Redis+Unix, RQ zapewnia prostszą dokumentację, prostszą bazę kodu i prostsze API. Oznacza to, że Ty (i potencjalni współtwórcy Twojego projektu) możesz skupić się na kodzie, na którym Ci zależy, zamiast przechowywać szczegóły dotyczące systemu kolejki zadań w swojej pamięci roboczej. Wszyscy mamy limit, ile szczegółów może znajdować się w naszej głowie naraz, a usuwając potrzebę przechowywania szczegółów kolejki zadań w RQ, możemy wrócić do kodu, na którym Ci zależy. Ta prostota odbywa się kosztem takich funkcji, jak kolejki zadań między językami, szerokie wsparcie systemu operacyjnego, w 100% niezawodne gwarancje wiadomości i możliwość łatwego przełączania brokerów wiadomości.
