Rq: Que tal considerar o uso de estrutura de fluxo Redis para implementar MQ

Concordo com você. Acho que o stream Redis seria perfeito para RQ. Isso é algo que podemos considerar para o futuro, provavelmente dentro de alguns anos, quando mais sistemas forem enviados com o Redis 5.

@selwin : Temos planos para implementá-lo? Porque Redis 6 GA foi publicado, estou tão ansioso para ter o recurso Steam para tornar o RQ mais confiável e flexível.

@ cw1427 Acho que ainda é um pouco cedo para migrar para os streams do Redis porque a maioria das distribuições de servidores ainda vem com o Redis 4.X por padrão.

Você mencionou que a adoção do Streams tornará o RQ mais confiável e flexível. Estou apenas curioso para saber quais recursos você deseja ver no RQ e se podemos implementá-los sem alternar para o Redis Streams.

Quanto a mim, o benefício mais importante que vejo em mudar para Streams seria a capacidade de executar tarefas XACK para que nunca sejam descartadas em casos em que falhas graves acontecem depois de retirar a tarefa da fila.

@selwin Sim, o ack seria o recurso mais charmoso para torná-lo mais confiável, e também o recurso de grupo de consumidores que o Redis Stream tem para torná-lo flexível para lidar com a geração de mensagens de vários tipos por diferentes aplicativos como "my Gerrit hook events, my Jenkins jobs acionam evento, minhas ações JIRA e assim por diante ".

Eu preferiria que o RQ pudesse ser o "canal" geral, como o barramento de eventos, para manter todas as mensagens chegando como vapor e serem consumidas pelos clientes pelos grupos.

Aqui eu encontrei um projeto enviado para o fluxo Redis. https://github.com/robinjoseph08/redisqueue Mas é pilha Go. Não sou bom em personalizá-lo do que RQ.