Celery: Propuesta para desaprobar Redis como soporte de intermediario. [Rechazado]

Hoy en día existen alternativas al apio, por ejemplo, huey y rq que se centran explícitamente en respaldar a Redis como intermediario. Cuando se soltó el apio, no había nada.

@pregunta ¿qué piensas acerca de
También tenemos Docker, lo que significa que la implementación de rabbitmq está literalmente a un comando de distancia. Ya no es tan difícil.

Acabo de eliminar el soporte para SQL como corredor, incluidos todos los demás corredores que no sean RabbitMQ / Redis / SQS / Qpid :)

(duplicar)

No estoy tan atado a la comunidad del apio; independientemente de mis $ 0.02:

• Redis es realmente popular, casi tan popular como todos los demás corredores admitidos _combined_ , si cree que Google Trends es representativo
• Es capaz de ser un corredor _y_ backend realmente bueno (aunque RabbitMQ también)
• Los grandes proveedores de la nube lo ofrecen de forma exclusiva como un servicio totalmente gestionado.
• ¡Usamos mucho Redis!

Puedo empatizar con sus sentimientos en torno a los problemas de mantenimiento, y este tipo de acción es un paso hacia la sostenibilidad. Pero, ¿hay otras 'amputaciones' que puedas hacer?

En el lado de la 'oferta' de la ecuación, ¿tiene alguna idea de por qué no hay más contribución al apio de la comunidad?
Una mirada superficial a las confirmaciones y relaciones públicas sugiere que el apio es principalmente el trabajo de una persona, en comparación con un par de bibliotecas de código abierto a las que contribuyo

@MaximilianR Hablando solo por mí:

1. Esta es una base de código considerable para entrar
2. Especialmente si no eres un experto en kombu y ayncio
3. Y no tienes intuiciones sobre la profundidad de los problemas informados

Dicho esto, uso apio, así que si hay alguna forma en que pueda ser útil, estaré feliz de ayudar.

@MaximilianR , ha habido numerosos colaboradores, pero definitivamente he hecho mucho del trabajo. El proyecto creció demasiado rápido, y en algún momento tuve la opción entre corregir errores o apoyar a los usuarios en IRC / email / StackOverflow etc. tutoría de personas. En ese momento éramos casi del tamaño de RabbitMQ en descargas, pero donde tenían 8 personas trabajando a tiempo completo, yo era el único.

Probablemente haya otras cosas que amputar, pero no creo que nada consuma tanto tiempo como Redis.

El trabajo de portar amqp / kombu a asyncio completo también fue un gran desperdicio de tiempo, pero necesario para resolver una serie de problemas. Sin embargo, nunca se completó.

@ask ¿Su mensaje anterior significa que todavía está interesado en poner esfuerzo en SQS? Me di cuenta de que solo hay un ticket SQS abierto aquí, pero todavía veo la advertencia "Experimental" en los documentos. ¿Puede asesorar sobre el estado actual y las necesidades futuras de SQS?

Usaríamos Celery + SQS en producción, por lo que es posible que pueda contribuir con un esfuerzo, pero realmente no quiero entrar en esa situación si SQS no es parte de su plan a largo plazo para el proyecto.

@Pedir gracias por compartir eso arriba. Puedo apreciar de dónde vienes. Espero que a través de este / otros enfoques, el apio pueda ser más fácil de mantener y continuar con su éxito ...

Definitivamente haga lo que sea mejor para su proyecto, pero ciertamente presionaré para deshacerme de Celery, internamente, si se elimina el soporte de Redis. Explicaré en privado si realmente quieres saber por qué no usaremos RabbitMQ, pero realmente no quiero criticar otros proyectos en público.

Relacionado: sugerir que es un comando porque así es como se desarrolla, en Docker, podría funcionar para usted, pero no es necesariamente así como el resto de nosotros lo implementamos.

@nicksloan SQS ahora aparece como un transporte admitido en los documentos maestros: http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

El trabajo para reescribir el transporte SQS en el uso de E / S asíncronas fue patrocinado por un poco más de $ 1000.

@scoates El transporte de Redis está en una situación peor, ya que en realidad se ha pirateado para usar E / S asíncronas para leer mensajes, pero la publicación sigue siendo sincrónica. La biblioteca Python redis es sincrónica, por lo que aún existen múltiples desafíos incluso para leer mensajes, y mucha incertidumbre sobre cómo funciona. Los errores pueden esconderse fácilmente allí, y cualquier cambio en la biblioteca redis-py podría tener efectos drásticos cuando la estamos usando de formas no ortodoxas.

Quiero apoyar a Redis, de verdad. Estaba luchando por ello cuando trabajé en RabbitMQ / Pivotal porque sentí que necesitamos una solución común en Python para los patrones que implementa Celery. Pero si la comunidad y las empresas que lo utilizan no invierten en mantenerlo funcionando, entonces me quedaré en la lucha contra incendios y, en el peor de los casos, como ahora, no podré solucionar problemas serios con el transporte que llevan a la gente a criticar el proyecto. Esto hace que mi vida sea más miserable y disminuye la moral.

Esto podría ser demasiado radical dada la historia del apio, pero ¿has pensado en mantener solo Redis sobre RabbitMQ?

@MaximilianR Lo he considerado, pero mi pasión es la transmisión de mensajes y la construcción de sistemas distribuidos correctos. Redis aún tiene que proporcionarnos una implementación de BRPOPLPUSH que funcione para implementar reconocimientos de mensajes, y con la revelación de la incapacidad de aceptar que es imposible confiar en el tiempo del reloj de pared en sistemas distribuidos, un hecho básico, soy más cauteloso. RabbitMQ al menos está atacando seriamente el espacio problemático, y hay otros jugadores como Kafka y NSQ. Muchas bibliotecas tratan las colas de tareas como una simple operación de lista, pero me niego a que Celery se convierta en una de ellas :)

@scoates : No estaba hablando de cómo me estoy desarrollando o algo así. Decía que decir que "rabbitmq es difícil de implementar" en 2016 es una tontería. Incluso si no sabe nada sobre la implementación de algo en algún lugar, existe una ventana acoplable que realmente ayuda. Por favor, no hagas suposiciones incorrectas.

Gracias @ask por registrarse con nosotros. El apio es un gran producto y, dados los recursos limitados que usted (y la comunidad) tiene, creo que centrarse en el producto principal es la mejor decisión. Me imagino lo difícil que debe ser intentar ofrecer las mismas funciones geniales utilizando muchos sistemas incompatibles diferentes. Desde el punto de vista del consumidor, creo que se suma a la complejidad del producto tener tantas opciones. Estoy seguro de que esto probablemente molestará a algunos de sus usuarios, pero creo que limitarse a menos corredores es lo correcto para el producto. Me gustaría ver el enfoque en AMQP como su protocolo estándar y bien aceptado y creo que rabbitmq es una muy buena implementación.

Es triste que realmente no haya mucho trabajo por hacer, pero cuando lo sumas en todos los transportes y funciones no es sostenible con solo unas pocas horas a la semana.

Dado que el protocolo Redis es tan simple, reescribir el transporte para que sea completamente asíncrono no tiene por qué ser tan difícil. He creado una capa que permite que Celery admita cualquier biblioteca de Tornado, lo mismo se podría hacer para asyncio y Twisted, por lo que es posible que incluso tengamos clientes que podamos reutilizar.

Python está cambiando drásticamente con asyncio en stdlib. Necesitamos nuevos marcos web, nuevas bibliotecas de red y prácticamente todo el ecosistema debe adaptarse. Hace nuestro trabajo un poco más fácil ya que ya no tenemos que seguir manteniendo nuestro propio ciclo de eventos, pero la transición requerirá algo de trabajo.

También quiero escribir un nuevo trabajador en Go o similar ahora que tenemos un nuevo protocolo de mensajes con soporte para múltiples idiomas. Redis no es la mejor opción para la interoperabilidad de mensajería, ya que no implementa encabezados de mensajes, propiedades, etc. El protocolo AMQP definitivamente tiene la ventaja, ya que fue uno de los casos de uso originales.

@ask Mi enfoque fue tratar de que las empresas mantuvieran a sus corredores. Así que intentemos hablar con alguien de los laboratorios de Redis y veamos si conseguimos algo de tracción.
Lo mismo para MongoDB y otros servicios.
En cuanto a los corredores de SQL, creo que no son una muy buena idea y no deberíamos apoyarlos.
Podemos extraer el código en lugar de eliminarlo, y buscar a alguien que lo mantenga. Si no hay suficiente interés, no es necesario.
La única base de datos SQL que puede ser un intermediario es Postgres porque tiene capacidades de Pub / Sub, pero de todos modos no está implementada actualmente.

Creo que podemos desaprobarlo y ver qué pasa. Tal vez alguien se encargue del mantenimiento o del patrocinio. Si no, tenemos un producto que la gente necesita, pero nadie quiere apoyar, que probablemente tenga 18 votos en total en este momento. No creo que eso influya solo en Redis Labs :)

Pero si la comunidad y las empresas que lo utilizan no invierten en mantenerlo funcionando, entonces me quedaré en la lucha contra incendios y, en el peor de los casos, como ahora, no podré solucionar problemas serios con el transporte que llevan a la gente a criticar el proyecto. Esto hace que mi vida sea más miserable y disminuye la moral.

Estamos usando apio con el corredor de Redis en múltiples proyectos y dependemos de él, pero estoy totalmente de acuerdo con ese sentimiento. Si no puede mantenerlo en un alto nivel de calidad, solo le dará al apio una mala reputación y hará que todos se sientan infelices, usted y los usuarios.

Hola. Trabajo para Redis Labs y hasta hace poco era un usuario de apio. @thedrow me llamó la atención sobre esto y lo hemos discutido internamente. Estamos dispuestos a ayudarlos, creemos que mantener los redis como parte del apio es importante. Todavía no estoy seguro de si lo haré personalmente o con otra persona, pero comencemos la discusión sobre lo que se debe hacer.

Al igual que @dvirsky, mi trabajo para Redis está completamente patrocinado por Redis Labs, y si podemos ayudar con este backend (con suerte sí), estaré involucrado para ayudar a encontrar las mejores soluciones en el lado de Redis, y potencialmente incluso extender el soporte de mensajería de Redis para facilitar ciertas cosas en la implementación. También podríamos enfatizar la capacidad del backend para usar Sentinel / Redis Cluster en algún momento para tener una experiencia lista para HA. Espero tener buenas noticias lo antes posible, evaluando actualmente el esfuerzo necesario.

¡Estas son realmente buenas noticias! Entiendo completamente que le gustaría saber el trabajo involucrado antes de comprometerse con él :)

Son las 3 de la madrugada en este momento y no he recopilado una lista de problemas, pero aquí hay algunas notas breves:

El apio no define un conjunto de características que se implementan con una interfaz para Redis, en su lugar
utiliza la API de AMQP para utilizar la mensajería de forma genérica. Mensajería de nombre a cola, pub / sub y enrutamiento de tema. El enrutamiento de temas no es un requisito estricto, pero el resto es fundamental para las características principales de Celery de 1) manejo de mensajes de tareas, 2) envío / recepción de eventos de monitoreo y 3) transmisión de mensajes a los trabajadores para administrarlos (por ejemplo, apagado / aumento de concurrencia / etc.) ).

1) Debe ser asíncrono para que no bloquee al trabajador para ninguna operación.

La versión actual usa la biblioteca redis-py, que es sincrónica. He pirateado esto para hacer
consume mensajes de manera asincrónica, pero sospecho que todavía hay errores allí, ya que no sabemos exactamente qué sucede en el cliente. Puede que ya haya clientes async redis disponibles para
Tornado / asyncio que podríamos usar, o en el peor de los casos, ya que no necesitamos mucho hacerlo sin procesar puede que no
ser tan engañoso.

2) Gestión de conexiones

Tenemos una conexión que consume tareas y una conexión que hace pubsub, luego un grupo
de conexiones para realizar operaciones fuera de banda, como reconocer mensajes o restaurar mensajes no reconocidos. Existe cierta confusión en torno al manejo de errores aquí, y es posible que no estemos cerrando todas las conexiones después de su uso.

3) Acuse de recibo del mensaje

Los mensajes solo se eliminan del servidor después de recibir una confirmación y tenemos un tiempo de espera de visibilidad en el que todos los consumidores de mensajes intentan restaurar los mensajes. Bueno, es un desastre
Puedo describir esto con más detalle más adelante.

Gracias @ask , sobre el punto "1" puede tener sentido implementar directamente el soporte asíncrono mínimo de Redis que necesitamos para los pocos comandos que enviamos directamente dentro del corredor en lugar de depender de una biblioteca externa.

Tenga en cuenta que solo 2, y posiblemente otros pequeños problemas, requieren una solución pronto. Está funcionando en gran medida, pero hay casos en los que los mensajes se pueden perder debido al reconocimiento del mensaje, pero ese es un elemento de la lista de deseos, ya que la situación era mucho peor antes de la emulación de ack. El cliente sincrónico de Redis puede bloquear al trabajador, lo que provoca un rendimiento deficiente y, en algunos casos, bloquea a los trabajadores.

1) Debe ser asíncrono para que no bloquee al trabajador para ninguna operación.

La última vez que verifiqué, los clientes async redis no eran perfectos (hay un par para tornado). Lo que hice en estas situaciones muchas veces fue usar un ejecutor de grupo de subprocesos y futuros para hacer que redis-py se comporte como un cliente asíncrono. Siempre que no tenga demasiadas tareas simultáneas y algunos subprocesos funcionarán, funciona mejor que los clientes asíncronos.

EDITAR: Todavía no he trabajado con el asyncio de Python directamente, pero por lo que he visto es bastante similar a tornado, por lo que este patrón probablemente será fácil de hacer.

@dvirsky No se nos permite usar hilos, ya que también estamos usando fork . Python no es compatible con este caso, e incluso si se produjo un parche para cpython, tendríamos que parchear cuidadosamente las bibliotecas de Python existentes, al menos las extensiones de C, para estar seguros de esta manera. Esto se realizó en el rastreador de errores de Python hace algún tiempo, y es por eso que hemos estado haciendo la migración a E / S asíncrona. También necesitamos movernos allí en general, ya que eso está en el futuro de Python ahora con soporte de E / S asíncrono central.

@antirez re:

sobre el punto "1" puede tener sentido implementar directamente el soporte asíncrono mínimo de Redis que necesitamos para los pocos comandos que enviamos directamente dentro del corredor en lugar de depender de una biblioteca externa.

Yo no haría eso. la mayor parte del código de redis-py gira en torno a la gestión de redes y conexiones, no a la implementación de comandos ...

@dvirsky Tenemos genéricos de administración de conexiones que funcionarían perfectamente para eso, por lo que no debería ser una pérdida de tiempo. No tenemos mucho de redes, pero creo que la mayoría está analizando el protocolo y ya lo hacemos de forma casi manual o enganchándonos a las clases de redis existentes.

@pregunte que sí, hay hiredis, que es una extensión C dedicada para analizar el protocolo redis, IIRC también puede funcionar con un cliente asíncrono. ¿Qué estrategia eligió hasta ahora para hacer redis async?

De todos modos, necesito echar un vistazo a lo que ha estado sucediendo con los clientes asíncronos recientemente, no he hecho mucho trabajo en Python en el último año y medio. Veo que https://github.com/leporo/tornado-redis no ha estado muy activo.

No hay mucha estrategia, agregamos el conector al bucle de eventos y enviamos, por ejemplo, BRPOP sincrónicamente, luego esperamos que el conector sea legible y leemos la respuesta sincrónicamente;)

Dado que no tenemos forma de reiniciar en medio del análisis de la respuesta

@dvirsky Si usamos hiredis para cualquier otra cosa que no sea el análisis del protocolo, tendremos problemas de compatibilidad con gevent / eventlet (cuando se usa en lugar de multiprocesamiento) y también hará que hiredis sea obligatorio, lo que tiene problemas de portabilidad si Celery se ejecuta en PyPy.

@dvirsky Además, py-hiredis no expone ninguna funcionalidad que no sea el análisis del protocolo en este momento.

Python necesitará un cliente async redis decente en algún momento, creo, por lo que comenzar algo adecuado no sería una mala idea. Por ejemplo, refactorizar parte del código de análisis del protocolo en redis-py.

estás usando gevent ahora mismo?

@dvirsky Admitimos gevent, eventlet y multiprocesamiento (prefork) con E / S asíncrona. Pero si apoyas a uno, normalmente tienes a los demás.

Sí, hay ocasiones en las que gevent es más apropiado para las tareas. por ejemplo, cuando las tareas simplemente escriben en la base de datos o realizan una solicitud HTTP.
Es bastante fácil exponer y registrar los FD en gevent, pero eso requiere más trabajo en py-hiredis.

@dvirsky Aquí hay un ejemplo de cómo se hace con PyCurl. https://gist.github.com/GuoJing/5875326
Necesita exponer el FD para poder colaborar con gevent.

Recientemente me presentaron el problema que rodea al soporte de apio para Redis y, aunque no he completado un análisis exhaustivo, puedo decir que escribir / actualizar un cliente de Python Redis con asyncio suena como una buena idea, pero de los puntos de referencia recientes, eso sería lo mejor. implementado sobre asyncio + libuv para exprimir tanto rendimiento como sea posible.

Para referencias ver

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

En contra de esta posición, o para complicar las cosas, señalaría que, según mi propia experiencia con los clientes de Redis, como desarrollador y usuario, confiar completamente en libuv evitará que el cliente logre el máximo rendimiento, y para eso, hiredis es imprescindible. Hay un montón de cosas sucediendo bajo el capó en libuv que en realidad ralentizan io en algunos casos, ioredis lo hace a través de Node y no es realmente eficaz.

Entonces, la solución que imagino tiene una implementación mixta hiredis-async. (Dicho de otra manera, es necesario probar un montón de alternativas con toneladas de selección y evaluación comparativa)

@ merl-dev El problema sigue siendo PyPy, donde hiredis + cffi es más lento al analizar el protocolo redis que la implementación del analizador del protocolo Python puro.
Al menos mi versión también tiene algunos fallos de prueba con redis-py. Ver https://github.com/redis/hiredis-py/pull/46

Es completamente posible escribir un cliente hiredis como una extensión CPython. Todavía no estoy 100% seguro acerca de CFFI.

consigámoslo

@thedrow esto me recuerda: ¿ha mirado la nueva función de transmisiones de redis? Se puede utilizar como un intermediario de mensajes mucho más robusto que el material actual. Va a ser GA muy pronto.

No lo hemos hecho. No tenemos la capacidad de refactorizar el corredor de redis en este momento.
Esperábamos que ustedes tuvieran algunas manos libres para hacerlo.

@thedrow es posible que ... no

@dvirsky te refieres a esta propuesta , ¿verdad? Por lo tanto, podría usar TAPPEND para poner en cola, TREAD + TACK para retirar, procesar y reconocer.

@georgepsarakis ya no es una propuesta, está funcionando y el prefijo es X, es decir, XADD. ver https://www.youtube.com/watch?v=ELDzy9lCFHQ

Entonces, ¿cuál es la llamada final para apoyar al corredor de redis? ¿Va a quedar obsoleto pronto?

No en este momento.

No podría decir en qué dirección se inclina la comunidad, pero estamos comenzando un nuevo proyecto y dudo en ir con Redis como corredor debido a la idea de desaprobarlo. ¿Pensamientos?

Es seguro asumir que el corredor de Redis permanecerá en el futuro previsible. Demasiada gente confía en ello.

Todo el tiempo # 301/601 se están volviendo obsoletos.

@ermik intenta ayudar a conseguirlo en un tema relacionado.