Ето какво открих, докато се опитвах да отговоря на същия въпрос. Вероятно не е изчерпателен и дори може да е неточен в някои точки.
Накратко, RQ е проектиран да бъде по-прост навсякъде. Целината е проектирана да бъде по-здрава. И двамата са отлични.
- Документация. Документацията на RQ е изчерпателна, без да е сложна, и отразява цялостната простота на проекта - никога не се чувствате изгубени или объркани. Документацията на Celery също е изчерпателна, но очаквайте да я преглеждате много, когато за първи път настройвате нещата, тъй като има твърде много опции за интернализиране
-
Мониторинг. Celery's Flower и таблото за управление на RQ са много лесни за настройка и ви дават поне 90% от цялата информация, която някога бихте искали
-
Брокерска поддръжка. Целина е безспорният победител, RQ поддържа само Redis. Това означава по-малко документация за това „какво е брокер“, но също така означава, че не можете да сменяте брокери в бъдеще, ако Redis вече не работи за вас. Например, Instagram разглежда както Redis, така и RabbitMQ с Celery. Това е важно, защото различните брокери имат различни гаранции, напр. Redis не може (към момента на писане) гарантира 100% че вашите съобщения са доставени.
-
Приоритетни опашки. Моделът на опашката с приоритет на RQ е прост и ефективен - работниците четат от опашките в ред. Целината изисква завъртане на множество работници, които да консумират от различни опашки. И двата подхода работят
-
Поддръжка на ОС. Celery е безспорният победител тук, тъй като RQ работи само на системи, които поддържат
forkнапр. Unix системи -
Езикова поддръжка. RQ поддържа само Python, докато Celery ви позволява да изпращате задачи от един език на различен език
-
API. Целината е изключително гъвкава (множество бекенда на резултата, хубав формат на конфигурацията, поддръжка на платно на работния процес), но естествено тази сила може да бъде объркваща. За разлика от тях, RQ api е прост.
-
Поддръжка на подзадачи. Celery поддържа подзадачи (например създаване на нови задачи от съществуващи задачи). Не знам дали RQ го прави
-
Общност и стабилност. Целината вероятно е по-утвърдена, но и двете са активни проекти. Към момента на писането, Celery има ~3500 звезди в Github, докато RQ има ~2000 и двата проекта показват активно развитие
Според мен Celery не е толкова сложен, колкото репутацията му може да ви накара да повярвате, но ще трябва да RTFM.
И така, защо някой би искал да разменя (вероятно по-пълнофункционалната) Celery за RQ? Според мен всичко се свежда до простотата. Като се ограничава до Redis+Unix, RQ предоставя по-проста документация, по-проста кодова база и по-опростен API. Това означава, че вие (и потенциалните сътрудници във вашия проект) можете да се съсредоточите върху кода, който ви интересува, вместо да се налага да съхранявате подробности за системата на опашката от задачи в работната си памет. Всички имаме ограничение за това колко подробности могат да бъдат в главата ни наведнъж и като премахнем необходимостта да съхраняваме подробности за опашката от задачи там, RQ позволява да се върнем към кода, който ви интересува. Тази простота идва за сметка на функции като междуезични опашки от задачи, широка поддръжка на ОС, 100% надеждни гаранции за съобщения и възможност за лесно превключване на посредници на съобщения.
