Плюси та мінуси використання селери проти RQ [закрито]

В даний час я працюю над проектом python, який потребує виконання деяких фонових завдань (переважно для надсилання електронної пошти та значних оновлень бази даних). Я використовую Redis для брокера завдань. Тож у цьому пункті у мене є два кандидати: селера та RQ . Я мав певний досвід роботи з цими чергами на роботу, але хочу попросити вас, хлопці, поділитися своїм досвідом використання цих інструментів. Так.

1. Які плюси та мінуси використовувати Celery vs. RQ.
2. Будь-які приклади проектів / завдань, придатних для використання Celery vs. RQ.

Селера виглядає досить складно, але це повноцінне рішення. Насправді я не думаю, що мені потрібні всі ці функції. З іншого боку RQ дуже простий (наприклад, конфігурація, інтеграція), але, здається, йому не вистачає корисних функцій (наприклад, скасування завдання, автоматичне перезавантаження коду)

Ось що я знайшов, намагаючись відповісти на це саме те питання. Це, мабуть, не є всеосяжним, а може бути навіть неточним у деяких питаннях.

Коротше кажучи, RQ розроблений для спрощення всього навколо. Селера покликана бути більш міцною. Вони обидва відмінні.

• Документація. Документація RQ є вичерпною, не є складною, і відображає загальну простоту проекту - ви ніколи не відчуваєте себе загубленим або заплутаним. Документація Селера також є всеосяжною, але очікуйте, що ви будете її повторно відвідувати, коли ви вперше налаштовуєте речі, оскільки є занадто багато варіантів для інтерналізації

• Моніторинг. Квітка селери та приладна панель RQ дуже прості в налаштуванні і дають вам принаймні 90% усієї інформації, яку ви хотіли б коли-небудь

• Брокерська підтримка. Селера - явний переможець, RQ підтримує лише Redis. Це означає менше документації про те, що таке брокер, але також означає, що ви не можете перемикати брокерів у майбутньому, якщо Redis більше не працює для вас. Наприклад, в Instagram розглядалися як Redis, так і RabbitMQ із селерою . Це важливо, оскільки різні брокери мають різні гарантії, наприклад Redis не може (на письмовій формі) гарантувати 100% доставку ваших повідомлень.

• Черги з пріоритетом. Модель черги пріоритетних RQ є простою та ефективною - працівники читають із черг по порядку . Селера вимагає розкручування кількох працівників, щоб споживати їх з різних черг. Обидва підходи працюють

• Підтримка ОС. Селера тут є явним переможцем, оскільки RQ працює лише в системах, які підтримують, forkнаприклад, системи Unix

• Мовна підтримка. RQ підтримує лише Python, тоді як селера дозволяє надсилати завдання з однієї мови на іншу

• API. Селера надзвичайно гнучка (безліч результатів, приємний формат конфігурації, підтримка полотна робочого процесу), але, природно, ця потужність може заплутати. Навпаки, RQ api простий.

• Підтримка підзадачі. Селера підтримує підзадачі (наприклад, створення нових завдань з існуючих завдань). Я не знаю, чи є RQ

• Спільнота та стабільність. Селера, напевно, більше встановлена, але вони обидва активні проекти. На момент написання, у селери на Github близько 3500 зірок, а в RQ - 2000, і обидва проекти демонструють активний розвиток

На мою думку, селера не така складна, як її репутація може призвести до того, що ви повірите, але вам доведеться використовувати RTFM.

Отже, чому б хто-небудь готовий торгувати (можливо, більш повнофункціональним) селерою для RQ? По-моєму, все зводиться до простоти. Обмежившись Redis + Unix, RQ забезпечує більш просту документацію, більш просту базу коду та більш простий API. Це означає, що ви (та потенційні учасники вашого проекту) можете зосередитись на коді, який вам важливий, замість того, щоб зберігати деталі про систему черги завдань у своїй робочій пам'яті. У всіх нас є обмеження щодо того, скільки деталей може бути в нашій голові одразу, і, усунувши необхідність зберігати там деталі черги завдань, RQ дозволяє повернутися до важливого вам коду. Ця простота пояснюється такими функціями, як міжмовні черги завдань, широка підтримка ОС, 100% надійні гарантії повідомлень та можливість легко перемикати посередників повідомлень.

Селера не така вже й складна. По суті, ви робите поетапну конфігурацію з tutorials, створюєте celeryекземпляр, прикрашаєте свою функцію, а @celery.taskпотім запускаєте завдання my_task.delay(*args, **kwargs).

Судячи з вашої власної оцінки, вам здається, що вам доведеться вибирати між недостатніми (ключовими) ознаками або маючими надлишки. Це не надто важкий вибір у моїй книзі.