Prós e contras de usar o aipo vs. RQ [fechado]

Atualmente estou trabalhando em um projeto python que requer a implementação de alguns trabalhos em segundo plano (principalmente para envio de e-mail e muitas atualizações de banco de dados). Eu uso o Redis como agente de tarefas. Portanto, neste ponto, tenho dois candidatos: Aipo e RQ . Tive alguma experiência com essas filas de empregos, mas gostaria de pedir a vocês que compartilhem a experiência de usar essas ferramentas. Assim.

1. Quais prós e contras usar aipo vs. RQ.
2. Quaisquer exemplos de projetos / tarefas adequados para usar Celery vs. RQ.

O aipo parece muito complicado, mas é uma solução completa. Na verdade, não acho que preciso de todos esses recursos. Do outro lado, RQ é muito simples (por exemplo, configuração, integração), mas parece que faltam alguns recursos úteis (por exemplo, revogação de tarefas, recarregamento automático de código)

Aqui está o que eu encontrei ao tentar responder exatamente a mesma pergunta. Provavelmente não é abrangente e pode até ser impreciso em alguns pontos.

Resumindo, o RQ foi projetado para ser mais simples. O aipo é projetado para ser mais robusto. Ambos são excelentes.

• Documentação. A documentação do RQ é abrangente, sem ser complexa, e reflete a simplicidade geral do projeto - você nunca se sente perdido ou confuso. A documentação do Celery também é abrangente, mas espere revisitá-la muito quando estiver configurando as coisas pela primeira vez, pois há muitas opções para internalizar

• Monitoramento. A flor do aipo e o painel RQ são muito simples de configurar e fornecem pelo menos 90% de todas as informações que você deseja

• Suporte ao corretor. O aipo é o vencedor claro, RQ apenas suporta Redis. Isso significa menos documentação sobre "o que é um corretor", mas também significa que você não pode trocar de corretor no futuro se o Redis não funcionar mais para você. Por exemplo, o Instagram considerou Redis e RabbitMQ com Celery . Isso é importante porque corretores diferentes têm garantias diferentes, por exemplo, o Redis não pode (no momento da escrita) garantir 100% de que suas mensagens serão entregues.

• Filas prioritárias. O modelo de fila de prioridade de RQs é simples e eficaz - os funcionários leem as filas em ordem . O aipo requer a rotação de vários trabalhadores para consumir em diferentes filas. Ambas as abordagens funcionam

• Suporte ao sistema operacional. O aipo é o vencedor claro aqui, pois o RQ só funciona em sistemas que suportam, forkpor exemplo, sistemas Unix

• Suporte de linguas. RQ suporta apenas Python, enquanto Celery permite enviar tarefas de um idioma para outro idioma

• API. O Celery é extremamente flexível (back-ends de resultados múltiplos, formato de configuração agradável, suporte para tela de fluxo de trabalho), mas naturalmente esse poder pode ser confuso. Em contraste, a RQ api é simples.

• Suporte a subtarefas. O Celery suporta subtarefas (por exemplo, criação de novas tarefas a partir de tarefas existentes). Não sei se RQ faz

• Comunidade e estabilidade. O aipo é provavelmente mais estabelecido, mas os dois são projetos ativos. No momento da escrita, Celery tem ~ 3500 estrelas no Github enquanto RQ tem ~ 2000 e ambos os projetos mostram desenvolvimento ativo

Na minha opinião, o aipo não é tão complexo quanto sua reputação pode levar você a acreditar, mas você terá que RTFM.

Então, por que alguém estaria disposto a trocar o aipo (possivelmente mais completo) por RQ? Em minha mente, tudo se resume à simplicidade. Ao se restringir ao Redis + Unix, o RQ fornece documentação mais simples, base de código mais simples e uma API mais simples. Isso significa que você (e os contribuidores em potencial para seu projeto) podem se concentrar no código de seu interesse, em vez de ter que manter os detalhes sobre o sistema de fila de tarefas em sua memória de trabalho. Todos nós temos um limite de quantos detalhes podem estar em nossa cabeça de uma vez e, removendo a necessidade de manter os detalhes da fila de tarefas lá, o RQ permite voltar ao código que lhe interessa. Essa simplicidade vem às custas de recursos como filas de tarefas entre idiomas, amplo suporte ao sistema operacional, garantias de mensagens 100% confiáveis ​​e capacidade de alternar facilmente os agentes de mensagens.

O aipo não é tão complicado. Basicamente, você faz a configuração passo a passo do tutorials, cria uma celeryinstância, decora sua função com @celery.taske, em seguida, executa a tarefa com my_task.delay(*args, **kwargs).

Julgando por sua própria avaliação, parece que você tem que escolher entre não ter recursos (principais) ou ter algum excesso por aí. Essa não é uma escolha muito difícil em meu livro.