Rq: ¿Qué tal si consideramos el uso de la estructura de flujo de Redis para implementar MQ?

Estoy de acuerdo contigo. Creo que la transmisión de Redis sería perfecta para RQ. Esto es algo que podemos considerar para el futuro, probablemente dentro de unos años, cuando se envíen más sistemas con Redis 5.

@selwin : ¿Tenemos un plan para implementarlo? Debido a que se publicó Redis 6 GA, estoy ansioso por tener la función Steam para hacer que RQ sea más confiable y flexible.

@ cw1427 Creo que todavía es un poco pronto para pasar a las transmisiones de Redis porque la mayoría de las distribuciones de servidor todavía se envían con Redis 4.X de forma predeterminada.

Mencionaste que la adopción de Streams hará que RQ sea más confiable y flexible. Solo tengo curiosidad por saber qué características desea ver en RQ y si podemos implementarlas sin cambiar a Redis Streams.

En cuanto a mí, el beneficio más destacado que veo al cambiar a Streams sería la capacidad de realizar trabajos XACK para que nunca se eliminen en los casos en que ocurren fallas graves después de sacar el trabajo de la cola.

@selwin Sí, el ack sería la característica más encantadora para hacerlo más confiable, y también la característica de grupo de consumidores que Redis Stream tiene para hacerla flexible para lidiar con la generación de mensajes de múltiples tipos mediante diferentes aplicaciones como "mis eventos de gancho de Gerrit, mi Los trabajos de Jenkins activan el evento, mis acciones de JIRA, etc. ".

Preferiría que RQ pudiera ser el bus de eventos tipo "tubería" general para mantener todos los mensajes llegando como vapor y ser consumidos por los grupos de clientes.

Aquí ya tengo un proyecto enviado a Redis Stream. https://github.com/robinjoseph08/redisqueue Pero es pila Go. No soy bueno para personalizarlo que RQ.