Celery vs. RQ 사용의 장단점 [닫기]

현재 저는 일부 백그라운드 작업을 구현해야하는 파이썬 프로젝트에서 작업하고 있습니다 (주로 이메일 전송 및 많은 데이터베이스 업데이트). 태스크 브로커에 Redis를 사용합니다. 이 시점에서 저는 Celery 와 RQ의 두 가지 후보를 가지고 있습니다 . 이 작업 대기열에 대한 경험이 있었지만이 도구를 사용한 경험을 공유해달라고 요청하고 싶습니다. 그래서.

1. Celery와 RQ를 사용하는 장단점.
2. Celery와 RQ를 사용하기에 적합한 프로젝트 / 작업의 예.

셀러리는 매우 복잡해 보이지만 완전한 기능을 갖춘 솔루션입니다. 사실 저는 이러한 모든 기능이 필요하다고 생각하지 않습니다. 다른 쪽에서 RQ는 매우 간단하지만 (예 : 구성, 통합) 유용한 기능 (예 : 작업 취소, 코드 자동 다시로드)이 부족한 것 같습니다.

이 똑같은 질문에 답하려고 노력하면서 찾은 내용은 다음과 같습니다. 포괄적이지 않을 수 있으며 일부 요점에서는 부정확 할 수도 있습니다.

요컨대, RQ는 모든면에서 더 간단하게 설계되었습니다. 셀러리는 더 견고하게 설계되었습니다. 둘 다 훌륭합니다.

• 선적 서류 비치. RQ의 문서 는 복잡하지 않고 포괄적이며 프로젝트의 전반적인 단순성을 반영합니다. 길을 잃거나 혼란스러워하지 않습니다. Celery의 문서 도 포괄적이지만 내부화 할 옵션이 너무 많기 때문에 처음 설정을 할 때 꽤 많이 다시 방문 할 것으로 예상됩니다.

• 모니터링. Celery 's Flower 와 RQ 대시 보드 는 설정이 매우 간단하며 원하는 모든 정보의 90 % 이상을 제공합니다.

• 브로커 지원. Celery는 확실한 승자이며 RQ는 Redis 만 지원합니다. 이것은 "브로커 란 무엇인가"에 대한 문서가 적다는 것을 의미하지만, Redis가 더 이상 작동하지 않으면 앞으로 브로커를 전환 할 수 없음을 의미합니다. 예를 들어 Instagram은 Celery와 함께 Redis와 RabbitMQ를 모두 고려했습니다 . 이는 브로커마다 보장이 다르기 때문에 중요합니다. 예를 들어 Redis 는 메시지 전달을 100 % 보장 할 수 없습니다 .

• 우선 순위 대기열. RQ 우선 순위 대기열 모델은 간단하고 효과적입니다. 작업자는 대기열에서 순서대로 읽습니다 . 셀러리는 서로 다른 대기열에서 소비하기 위해 여러 작업자를 회전시켜야합니다. 두 가지 접근 방식 모두 작동

• OS 지원. RQ는 fork예를 들어 Unix 시스템 을 지원하는 시스템에서만 실행되기 때문에 Celery가 확실한 승자 입니다.

• 언어 지원. RQ는 Python 만 지원하지만 Celery에서는 한 언어에서 다른 언어로 작업을 보낼 수 있습니다.

• API. Celery는 매우 유연하지만 (다중 결과 백엔드, 멋진 구성 형식, 워크 플로 캔버스 지원) 당연히이 힘은 혼란 스러울 수 있습니다. 반대로 RQ API는 간단합니다.

• 하위 작업 지원. Celery는 하위 작업 (예 : 기존 작업 내에서 새 작업 생성)을 지원합니다. RQ가 있는지 모르겠습니다.

• 커뮤니티와 안정성. 셀러리는 아마도 더 잘 확립되어 있지만 둘 다 활발한 프로젝트입니다. 글을 쓰는 시점에서 Celery는 Github에서 ~ 3500 개의 별을 보유하고 있고 RQ는 ~ 2000이며 두 프로젝트 모두 활발한 개발을 보이고 있습니다.

제 생각에 Celery는 평판이 당신을 믿게 만드는 것만 큼 복잡하지는 않지만 RTFM을해야합니다.

그렇다면 왜 누군가가 (아마도 완전한 기능을 갖춘) 셀러리를 RQ와 교환 할 의향이 있습니까? 제 생각에는 모든 것이 단순함으로 귀결됩니다. 자신을 Redis + Unix로 제한함으로써 RQ는 더 간단한 문서, 더 간단한 코드베이스 및 더 간단한 API를 제공합니다. 즉, 작업 메모리에 작업 대기열 시스템에 대한 세부 정보를 유지하는 대신 사용자 (및 잠재적 인 프로젝트 기여자)가 관심있는 코드에 집중할 수 있습니다. 우리 모두는 한 번에 얼마나 많은 세부 정보를 머리에 넣을 수 있는지에 대한 제한이 있으며 작업 대기열 세부 정보를 거기에 보관할 필요성을 제거하여 RQ를 사용하면 관심있는 코드로 돌아갈 수 있습니다. 이러한 단순성은 언어 간 작업 대기열, 광범위한 OS 지원, 100 % 신뢰할 수있는 메시지 보장 및 메시지 브로커를 쉽게 전환 할 수있는 기능과 같은 기능을 희생시킵니다.

셀러리는 그렇게 복잡하지 않습니다. 핵심은에서 단계별 구성을 수행하고 tutorials, celery인스턴스를 만들고, 함수를 장식 @celery.task한 다음 my_task.delay(*args, **kwargs).

자신의 평가에 따르면, (주요) 기능이 부족하거나 과도한 기능이있는 것 중에서 선택해야하는 것 같습니다. 그것은 내 책에서 선택하기가 너무 어렵지 않습니다.