Plusy i minusy stosowania selera vs. RQ [zamknięty]

Obecnie pracuję nad projektem Pythona, który wymaga zaimplementowania niektórych zadań w tle (głównie do wysyłania e-maili i dużych aktualizacji baz danych). Używam Redis jako brokera zadań. Więc w tym punkcie mam dwóch kandydatów: seler i RQ . Miałem pewne doświadczenie z tymi kolejkami pracy, ale chciałbym was poprosić o podzielenie się doświadczeniem z korzystania z tych narzędzi. Więc.

  1. jakie plusy i minusy stosować seler vs. RQ.
  2. wszelkie przykłady projektów / zadań nadających się do użycia vs. RQ.

Seler wygląda dość skomplikowanie, ale jest to w pełni funkcjonalne rozwiązanie. Właściwie nie sądzę, że potrzebuję tych wszystkich funkcji. Z drugiej strony RQ jest bardzo prosty (np. konfiguracja, integracja), ale wydaje się, że brakuje w nim kilku przydatnych funkcji (np.]}

Author: Maxim Kamenkov, 2012-11-18

2 answers

Oto, co znalazłem, próbując odpowiedzieć na to samo pytanie. To prawdopodobnie nie jest wyczerpujące, a nawet może być niedokładne w niektórych punktach.

Krótko mówiąc, RQ ma być prostsze. Seler ma być bardziej wytrzymały. Oba są doskonałe.

  • dokumentacja. dokumentacja RQ jest kompleksowa, bez złożoności i odzwierciedla ogólną prostotę projektu - nigdy nie czujesz się zagubiony lub zdezorientowany. dokumentacja selera jest również wszechstronny, ale spodziewaj się, że będziesz go ponownie odwiedzać, gdy po raz pierwszy konfigurujesz rzeczy, ponieważ istnieje zbyt wiele opcji do internalizacji
  • Monitoring. seler ' s Flower i deska rozdzielcza RQ są bardzo proste w konfiguracji i dają co najmniej 90% wszystkich informacji, które kiedykolwiek chcesz

  • Wsparcie brokera. Seler jest wyraźnym zwycięzcą, RQ obsługuje tylko Redis. Oznacza to mniej dokumentacji na temat "co to jest broker", ale również oznacza, że nie możesz przełączaj brokerów w przyszłości, jeśli Redis nie działa już dla Ciebie. Na przykład, Instagram rozważał zarówno Redis, jak i RabbitMQ z selerem . Jest to ważne, ponieważ różni brokerzy mają różne gwarancje, np. Redis nie może (w momencie pisania) zagwarantować 100% dostarczenia wiadomości.

  • Kolejki priorytetowe. Model kolejki priorytetów RQs jest prosty i efektywny- workers czyta z kolejek w kolejności . Seler wymaga wielu pracowników do spożywać z różnych kolejek. Oba podejścia działają

  • Obsługa systemu operacyjnego. Selery jest tutaj wyraźnym zwycięzcą, ponieważ RQ działa tylko na systemach, które obsługują fork np. systemy Unix

  • Wsparcie Językowe. RQ obsługuje tylko Python, podczas gdy seler pozwala wysyłać zadania z jednego języka do innego języka

  • API. Seler jest niezwykle elastyczny (wiele backendów wyników, ładny format konfiguracji, obsługa płótna przepływu pracy), ale oczywiście ta moc może być myląca. Przez natomiast interfejs RQ api jest prosty.

  • Obsługa podzakresów. Seler wspiera zadania podrzędne (np. tworzenie nowych zadań z istniejących zadań). Nie wiem czy RQ robi

  • Społeczność i stabilność. Selery są prawdopodobnie bardziej ugruntowane, ale oba są aktywnymi projektami. Obecnie seler ma około 3500 gwiazdek na Githubie, podczas gdy RQ ma ~2000 i oba projekty wykazują aktywny rozwój

Moim zdaniem seler nie jest tak skomplikowany, jak jego reputacja może cię poprowadzić wierzyć, ale trzeba będzie RTFM.

Więc dlaczego ktoś byłby skłonny wymienić (prawdopodobnie bardziej pełnowartościowy) seler na RQ? W mojej głowie wszystko sprowadza się do prostoty. Ograniczając się do Redis + Unix, RQ zapewnia prostszą dokumentację, prostszą bazę kodową i prostsze API. Oznacza to, że ty (i potencjalni współpracownicy twojego projektu) możesz skupić się na kodzie, na którym ci zależy, zamiast trzymać szczegóły dotyczące systemu kolejek zadań w pamięci roboczej. Wszyscy mamy ogranicz ilość szczegółów na raz w naszej głowie, a poprzez usunięcie konieczności utrzymywania tam szczegółów kolejki zadań, RQ pozwala wrócić do kodu, na którym ci zależy. Ta prostota jest kosztem takich funkcji, jak kolejki zadań między językami, szeroka Obsługa systemu operacyjnego, 100% niezawodne Gwarancje wiadomości i możliwość łatwego przełączania brokerów wiadomości.

 75
Author: Hamy,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-02-17 19:21:43

Seler nie jest aż tak skomplikowany. W swoim rdzeniu wykonujesz konfigurację krok po kroku z tutorials, Utwórz instancję celery, udekoruj swoją funkcję @celery.task, a następnie uruchom zadanie za pomocą my_task.delay(*args, **kwargs).

Sądząc po twojej własnej ocenie, wydaje się, że musisz wybrać pomiędzy brakiem (kluczowych) funkcji lub nadmiarem wiszącym wokół. To nie jest zbyt trudny wybór w mojej książce.

 1
Author: Jesse the Game,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-18 16:05:53