Celery: Proposta para descontinuar o Redis como suporte do corretor. [Rejeitado]

Hoje em dia existem alternativas ao aipo, por exemplo, huey e rq que se concentram explicitamente no suporte da redis como corretora. Quando o aipo foi liberado, não havia nada.

@ask, o que você acha de também descartar o suporte ao corretor sql? Duvido que haja muitas pessoas que usam um banco de dados sql em produção. Mesmo se o fizerem, eles realmente não deveriam.
Também temos docker, o que significa que a implantação do rabbitmq está literalmente a um comando de distância. Não é mais _tão_ difícil.

Acabei de abandonar o suporte para SQL como um corretor, incluindo todos os outros corretores, exceto RabbitMQ / Redis / SQS / Qpid :)

(duplicado)

Não sou tão ligado à comunidade do aipo; independentemente dos meus $ 0,02:

• Redis é realmente popular - quase tão popular quanto todos os outros corretores compatíveis _combined_ , se você acha que o Google Trends é representativo
• É capaz de ser um bom corretor _e_ back-end (RabbitMQ também)
• É oferecido exclusivamente pelos grandes fornecedores de nuvem como um serviço totalmente gerenciado
• Usamos muito o Redis!

Posso ter empatia com seus sentimentos em relação às questões de manutenção, e esse tipo de ação é um passo em direção à sustentabilidade. Mas existem outras 'amputações' que você poderia fazer?

No lado da 'oferta' da equação, você tem alguma ideia de por que não há mais contribuições da comunidade para o aipo?
Uma rápida olhada nos commits e PRs sugere que o aipo é principalmente o trabalho de uma pessoa, em comparação com algumas bibliotecas de código aberto com as quais contribuo

@MaximilianR Falando apenas por mim:

1. Esta é uma base de código considerável para entrar
2. Principalmente se você não for um especialista em kombu e ayncio
3. E você não tem intuições sobre a profundidade dos problemas relatados

Dito isso, eu uso aipo, então, se houver uma maneira de ser útil, ficarei feliz em ajudar.

@MaximilianR , Houve vários contribuidores, mas definitivamente fiz muito do trabalho. O projeto cresceu muito rápido, e em algum ponto eu tive a escolha entre consertar bugs ou oferecer suporte a usuários no IRC / email / StackOverflow etc. mentor de pessoas. Estávamos naquele ponto quase do tamanho do RabbitMQ em downloads, mas onde eles tinham 8 pessoas trabalhando em tempo integral, eu era o único.

Provavelmente há outras coisas para amputar, mas não acho que nada seja tão demorado quanto Redis.

O trabalho de portar amqp / kombu para assíncio total também foi um grande desperdício de tempo, mas necessário para resolver uma série de questões. Mas nunca foi concluído.

@ask Sua mensagem acima significa que você ainda está interessado em se esforçar no SQS? Percebi que há apenas um tíquete SQS aberto aqui, mas ainda vejo o aviso "Experimental" nos documentos. Você pode aconselhar sobre o status atual e as necessidades futuras do SQS?

Estaríamos usando Celery + SQS na produção, então posso contribuir com algum esforço para isso, mas realmente não quero entrar nessa situação se o SQS não fizer parte do seu plano de longo prazo para o projeto.

@ask, obrigado por compartilhar isso acima. Eu posso entender de onde você está vindo. Espero que através desta / outras abordagens o aipo possa ser mais fácil de manter e continuar seu sucesso ...

Definitivamente, farei o que é melhor para o seu projeto, mas certamente pressionarei para me livrar do Celery, internamente, se o suporte do Redis for encerrado. Vou elaborar em particular se você realmente quiser saber por que não usaremos o RabbitMQ, mas eu realmente não quero criticar outros projetos em público.

Relacionado: sugerir que é um comando porque é assim que você desenvolve, no Docker, pode funcionar para você, mas não é necessariamente assim que o resto de nós implementa.

@nicksloan SQS agora está listado como um transporte compatível nos documentos principais: http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

O trabalho para reescrever o transporte SQS no uso de E / S assíncrona foi patrocinado por um pouco mais de US $ 1.000,00.

@scoates O transporte Redis está em uma situação pior, pois é realmente hackeado para usar E / S assíncrona para ler mensagens, mas a publicação ainda é síncrona. A biblioteca Python redis é síncrona, portanto, ainda existem vários desafios, mesmo para a leitura de mensagens, e muitas incertezas sobre como isso funciona. Os bugs podem estar facilmente escondidos lá, e qualquer alteração na biblioteca redis-py pode ter efeitos drásticos quando a usamos de maneiras não ortodoxas.

Eu quero apoiar o Redis, de verdade. Eu estava lutando por isso quando trabalhei no RabbitMQ / Pivotal, pois senti que precisamos de uma solução comum em Python para os padrões que o Celery implementa. Mas se a comunidade e as empresas que o utilizam não investirem em mantê-lo funcionando, ficarei lutando contra o incêndio e, na pior das hipóteses, não poderei consertar sérios problemas de transporte que levam as pessoas a criticarem o projeto. Isso torna minha vida mais miserável e diminui o moral.

Isso pode ser muito radical devido à história do aipo, mas você já pensou em manter apenas o Redis em vez do RabbitMQ?

@MaximilianR Já considerei isso, mas minha paixão é passar mensagens e construir sistemas distribuídos corretos. O Redis ainda não nos forneceu uma implementação de BRPOPLPUSH que funcione para a implementação de reconhecimentos de mensagens, e com a revelação da incapacidade de aceitar que é impossível contar com o relógio de parede em sistemas distribuídos, um fato básico, estou mais cauteloso. O RabbitMQ está pelo menos atacando o espaço problemático seriamente, e existem outros jogadores como Kafka e NSQ. Muitas bibliotecas estão tratando as filas de tarefas como uma operação de lista simples, mas eu me recuso a se tornar uma delas :)

@scoates : Eu não estava falando sobre como estou desenvolvendo ou algo assim. Eu estava dizendo que dizer "rabbitmq é difícil de implantar" em 2016 é um disparate. Mesmo que você não saiba nada sobre como implantar algo em algum lugar, existe o docker que realmente ajuda. Por favor, não faça suposições erradas.

Obrigado @ask por nos consultar. O aipo é um ótimo produto e, dados os recursos limitados que você (e a comunidade) têm, acho que focar no produto principal é a melhor decisão. Posso imaginar como deve ser difícil tentar oferecer os mesmos excelentes recursos usando muitos sistemas incompatíveis diferentes. Do ponto de vista do consumidor, acho que aumenta a complexidade do produto ter tantas opções. Tenho certeza de que isso provavelmente irá incomodar alguns de seus usuários, mas acho que preferir menos corretores é a coisa certa a fazer para o produto. Eu gostaria de ver o foco no AMQP como um protocolo padrão e bem aceito e acho que o rabbitmq é uma implementação muito boa dele.

É triste que não haja muito trabalho a ser feito, mas quando você adiciona tudo em todos os transportes e recursos, não é sustentável com apenas algumas horas por semana.

Como o protocolo Redis é tão simples, reescrever o transporte para ser totalmente assíncrono não precisa ser tão difícil. Fiz uma camada que permite ao Celery suportar qualquer biblioteca Tornado, o mesmo poderia ser feito para asyncio e Twisted, então podemos até ter clientes por aí que podemos reutilizar.

Python está mudando drasticamente com asyncio em stdlib. Precisamos de novas estruturas da web, novas bibliotecas de rede e praticamente todo o ecossistema precisa se adaptar. Isso torna nosso trabalho um pouco mais fácil, já que não precisamos mais manter nosso próprio loop de eventos, mas a transição exigirá algum trabalho.

Também quero escrever um novo trabalhador em Go ou semelhante, agora que temos um novo protocolo de mensagem com suporte para vários idiomas. O Redis não é a melhor opção para interoperabilidade de mensagens, pois não implementa cabeçalhos de mensagens, propriedades etc. O protocolo AMQP definitivamente tem a vantagem, já que foi um dos casos de uso originais.

@ask Minha abordagem foi tentar fazer com que as empresas mantenham seus corretores. Então, vamos tentar falar com alguém dos laboratórios Redis e ver se conseguimos alguma tração.
O mesmo para MongoDB e outros serviços.
Quanto aos corretores de SQL, acho que não são uma ideia muito boa e não devemos apoiá-los.
Podemos extrair o código em vez de removê-lo e, no entanto, procurar alguém para mantê-lo. Se não houver interesse suficiente, não haverá necessidade deles.
O único banco de dados SQL que pode ser meio que um broker é o Postgres, porque ele tem recursos do Pub / Sub, mas isso não está implementado no momento.

Acho que podemos simplesmente descontinuá-lo e ver o que acontece. Talvez alguém dê um passo à frente, assumindo a manutenção ou patrocinando. Do contrário, temos um produto que as pessoas precisam, mas ninguém quer apoiar, o que provavelmente está com 18 votos no total neste momento. Não acho que isso vá influenciar os Redis Labs sozinho :)

Mas se a comunidade e as empresas que o utilizam não investirem em mantê-lo funcionando, ficarei lutando contra o incêndio e, na pior das hipóteses, não poderei consertar sérios problemas de transporte que levam as pessoas a criticarem o projeto. Isso torna minha vida mais miserável e diminui o moral.

Estamos usando aipo com o corretor redis em vários projetos e dependendo disso, mas concordo totalmente com esse sentimento. Se você não puder mantê-lo em um alto nível de qualidade, ele apenas dará uma má fama ao aipo e deixará todos infelizes - você _e_ os usuários.

Oi. Trabalho para o Redis Labs e até recentemente era usuário de aipo. @thedrow chamou minha atenção para isso e discutimos isso internamente. Estamos dispostos a ajudar vocês, achamos que manter o redis como parte do aipo é importante. Ainda não tenho certeza se farei isso pessoalmente ou por outra pessoa, mas vamos começar a discussão sobre o que precisa ser feito.

Como @dvirsky, meu trabalho no Redis é totalmente patrocinado pelo Redis Labs e, se pudermos ajudar com esse back-end (espero que sim), estarei envolvido para ajudar a encontrar as melhores soluções no lado do Redis e, potencialmente, até estender o suporte de mensagens Redis para facilitar certas coisas na implementação. Também poderíamos enfatizar a capacidade do back-end de usar o Cluster do Sentinel / Redis em algum ponto para ter uma experiência pronta para HA. Espero ter boas notícias o mais rápido possível, atualmente avaliando o esforço necessário.

Esta é realmente uma boa notícia! Eu entendo perfeitamente que você gostaria de saber o trabalho envolvido antes de se comprometer com ele :)

São 3 da manhã aqui agora e eu não coletei uma lista de problemas, mas aqui estão algumas notas curtas:

O Celery não define um conjunto de recursos que são implementados com uma interface para Redis, em vez disso
ele usa a API AMQP para usar o sistema de mensagens de uma maneira genérica. Mensagens de nome para fila, pub / sub e roteamento de tópicos. O roteamento de tópicos não é um requisito estrito, mas o resto é crítico para os principais recursos do Celery de 1) manipulação de mensagens de tarefas, 2) envio / recebimento de eventos de monitoramento e 3) transmissão de mensagens aos trabalhadores para gerenciá-los (por exemplo, desligamento / aumento de simultaneidade / etc. )

1) Precisa ser assíncrono para não bloquear o trabalhador em nenhuma operação

A versão atual usa a biblioteca redis-py, que é síncrona. Eu hackeei isso para fazer
ele consome mensagens de maneira assíncrona, mas suspeito que ainda existam bugs, pois não sabemos exatamente o que acontece no cliente. Pode já haver clientes redis assíncronos disponíveis para
Tornado / asyncio que poderíamos usar, ou pior caso, uma vez que não precisamos de muito para fazê-lo cru, pode não
seja tão complicado.

2) Gerenciamento de conexão

Temos uma conexão que consome tarefas e uma conexão fazendo pubsub e, em seguida, um pool
de conexões para realizar operações fora da banda, como reconhecimento de mensagens ou restauração de mensagens não confirmadas. Existe alguma confusão em torno do tratamento de erros aqui, e podemos não fechar todas as conexões após o uso.

3) Confirmação da mensagem

As mensagens só são removidas do servidor depois de serem confirmadas e temos um tempo limite de visibilidade em que todos os consumidores de mensagens tentam restaurá-las. Bem, é uma bagunça,
Posso descrever isso com mais detalhes posteriormente.

Obrigado @ask , sobre o ponto "1" pode fazer sentido implementar diretamente o suporte Redis assíncrono mínimo de que precisamos para os poucos comandos que enviamos diretamente dentro do broker em vez de depender de uma biblioteca externa.

Observe que apenas 2 e, possivelmente, alguns outros pequenos problemas exigem uma solução em breve. Está funcionando amplamente, mas há casos em que as mensagens podem ser perdidas devido ao reconhecimento da mensagem, mas esse é um item da lista de desejos, pois a situação era muito pior antes da emulação do ack. O trabalhador pode ser bloqueado pelo cliente Redis síncrono, o que está causando mau desempenho e, em alguns casos raros, interrompendo os trabalhos.

1) Precisa ser assíncrono para não bloquear o trabalhador em nenhuma operação

A última vez que verifiquei, os clientes redis assíncronos não eram perfeitos (há alguns para tornado). O que eu fiz nessas situações muitas vezes foi usar um executor de pool de threads e futuros para fazer o redis-py se comportar como um cliente assíncrono. contanto que você não tenha muitas tarefas simultâneas e alguns threads servirão, funciona melhor do que clientes assíncronos.

EDIT: Eu não trabalhei com asyncio do python diretamente ainda, mas pelo que vi é muito semelhante ao tornado, então esse padrão provavelmente será fácil de fazer.

@dvirsky Não temos permissão para usar threads, pois também estamos usando fork . Python não suporta este caso, e mesmo se um patch fosse produzido para cpython, teríamos que corrigir cuidadosamente as bibliotecas Python existentes, pelo menos as extensões C, para ficarmos seguros dessa maneira. Isso foi percebido no rastreador de bug do Python há algum tempo, e é por isso que estamos fazendo a migração para E / S assíncrona. Também precisamos mudar para lá em geral, já que isso é no futuro do Python agora com suporte de E / S assíncrono central.

@antirez re:

sobre o ponto "1", pode fazer sentido implementar diretamente o suporte Redis assíncrono mínimo de que precisamos para os poucos comandos que enviamos diretamente dentro do broker em vez de depender de uma biblioteca externa.

Eu não faria isso. a maior parte do código do redis-py gira em torno de gerenciamento de rede e conexão, não em torno da implementação de comandos ...

@dvirsky Temos genéricos de gerenciamento de conexão que funcionam perfeitamente para isso, de modo que não deve haver

@ask, sim, há hiredis, que é uma extensão C dedicada para analisar o protocolo redis, IIRC também pode funcionar com um cliente assíncrono. qual estratégia você escolheu até agora para tornar o redis assíncrono?

de qualquer maneira, preciso dar uma olhada no que está acontecendo com os clientes assíncronos recentemente, não fiz muito trabalho com Python no último ano e meio. Vejo que https://github.com/leporo/tornado-redis não tem estado muito ativo.

Não há muita estratégia, adicionamos o soquete ao loop de eventos e enviamos, por exemplo, BRPOP de forma síncrona, então esperamos que o soquete seja legível e lemos a resposta de forma síncrona;)

Uma vez que não temos como reiniciar no meio da análise da resposta

@dvirsky Se usarmos o hiredis para qualquer coisa que não seja a análise de protocolo, teremos problemas de compatibilidade com gevent / eventlet (quando for usado em vez de multiprocessamento) e também tornará o hiredis obrigatório quanto aos problemas de portabilidade se o Celery for executado no PyPy.

@dvirsky Além disso, o py-hiredis não expõe nenhuma funcionalidade além da análise de protocolo no momento.

Acredito que o Python precisará de um cliente redis assíncrono decente em algum momento, portanto, iniciar algo adequado não seria uma má ideia. Por exemplo, refatorar parte do código de análise de protocolo no redis-py.

você está usando gevent agora?

@dvirsky Oferecemos suporte a gevent, eventlet e multiprocessamento (prefork) com E / S assíncrona. Mas se você apóia um, geralmente tem os outros.

Sim, há momentos em que o gevent é mais apropriado para as tarefas. por exemplo, quando as tarefas apenas gravam no banco de dados ou executam uma solicitação HTTP.
É fácil expor e registrar os FDs em gevent, mas isso requer mais trabalho em py-hiredis.

@dvirsky Aqui está um exemplo de como isso é feito com PyCurl. https://gist.github.com/GuoJing/5875326
Você precisa expor o FD para colaborar com o gevent.

Recentemente fui apresentado ao problema em torno do suporte a aipo para Redis e, embora não tenha concluído uma análise completa, posso dizer que escrever / atualizar um cliente python redis com asyncio parece uma boa ideia, mas a partir de benchmarks recentes, seria melhor implementado em cima de asyncio + libuv para obter o máximo de desempenho possível.

Para referências veja

• https://github.com/MagicStack/uvloop
• https://github.com/saghul/pyuv
• http://magic.io/blog/uvloop-blazing-fast-python-networking/

Contra essa posição - ou para complicar as coisas, eu observaria que, de acordo com minha própria experiência com clientes Redis, como desenvolvedor e usuário, confiar inteiramente no libuv na verdade impedirá que o cliente alcance o desempenho máximo, e para isso contratar é uma obrigação. Há uma tonelada de coisas acontecendo por baixo do capô em libuv que na verdade retarda io em alguns casos, ioredis faz isso por meio do Node e não tem um desempenho real.

Portanto, a solução que eu imagino tem uma implementação mista hiredis-async. (Em outras palavras, um monte de alternativas precisam ser tentadas com toneladas de seleção seletiva e benchmarking)

@ merl-dev O problema ainda é o PyPy, onde hiredis + cffi é mais lento na análise do protocolo redis do que na implementação do analisador do protocolo Python puro.
Pelo menos minha versão também tem algumas falhas de teste com redis-py. Veja https://github.com/redis/hiredis-py/pull/46

É inteiramente possível escrever um cliente hiredis como uma extensão CPython. Ainda não estou 100% certo sobre o CFFI.

vamos obtê-lo

@thedrow isso me lembra - você já olhou para o novo recurso de streams do redis? Ele pode ser usado como um intermediário de mensagem muito mais robusto do que as coisas atuais. Em breve será GA.

Não temos. Não temos capacidade para refatorar o corretor redis no momento.
Esperávamos que vocês tivessem algumas mãos sobressalentes para fazer isso.

@thedrow nós apenas podemos ... não prometer nada, mas podemos dedicar mais alguns recursos para apoiar o ecossistema redis de forma proativa.

@dvirsky você quer dizer esta proposta , certo? Portanto, você pode usar TAPPEND para enfileirar, TREAD + TACK para retirar da fila, processar e confirmar.

@georgepsarakis não é mais uma proposta, está funcionando e o prefixo é X, ou seja, XADD. consulte https://www.youtube.com/watch?v=ELDzy9lCFHQ

Então, qual é a chamada final para apoiar o corretor redis? O uso será suspenso em breve?

Não no momento.

Não pude dizer para que lado a comunidade está se inclinando, mas estamos iniciando um novo projeto e estou hesitante em ir com o Redis como corretor devido à ideia de descontinuá-lo. Pensamentos?

É seguro presumir que o corretor redis permanecerá no futuro próximo. Muitas pessoas contam com isso.

Todo o tempo # 301/601 estão ficando obsoletos.

@ermik tenta ajudar a