message queue - ¿Cómo garantizar la entrega de mensajes con apio?
message-queue redis (5)
Tengo una aplicación de Python en la que quiero comenzar a trabajar más en segundo plano para que se escale mejor a medida que se vuelve más activo. En el pasado, he usado Apio para realizar tareas de fondo normales, y esto ha funcionado bien.
La única diferencia entre esta aplicación y las otras que he hecho en el pasado es que necesito garantizar que estos mensajes se procesen, no se pueden perder.
Para esta aplicación no estoy demasiado preocupado por la velocidad de mi cola de mensajes, necesito fiabilidad y durabilidad en primer lugar. Para estar seguro, quiero tener dos servidores de cola, ambos en diferentes centros de datos, en caso de que algo salga mal, uno como respaldo del otro.
En cuanto a Aplery, parece que admite un conjunto de backends diferentes, algunos con más características que los demás. Los dos más populares se parecen a redis y RabbitMQ, así que me tomé un tiempo para examinarlos más a fondo.
RabbitMQ: admite colas duraderas y clústeres, pero el problema con la forma en que tienen clústeres hoy es que si pierde un nodo en el clúster, todos los mensajes en ese nodo no estarán disponibles hasta que vuelva a poner ese nodo en línea. No replica los mensajes entre los diferentes nodos en el clúster, solo replica los metadatos sobre el mensaje, y luego regresa al nodo de origen para obtener el mensaje, si el nodo no se está ejecutando, usted es SOL no ideal.
La forma en que recomiendan evitar esto es configurar un segundo servidor y replicar el sistema de archivos usando DRBD, y luego ejecutar algo como marcapasos para cambiar los clientes al servidor de respaldo cuando lo necesite también. Esto parece bastante complicado, no estoy seguro si hay una mejor manera. Alguien sabe de una mejor manera?
Redis: Admite un esclavo de lectura y esto me permitiría tener una copia de seguridad en caso de emergencias, pero no es compatible con la configuración del maestro maestro, y no estoy seguro de si maneja la conmutación por error activa entre el maestro y el esclavo. No tiene las mismas características que RabbitMQ, pero parece mucho más fácil de configurar y mantener.
Preguntas:
¿Cuál es la mejor manera de configurar el apio para que garantice el procesamiento del mensaje?
¿Alguien ha hecho esto antes? Si es así, ¿le importaría compartir lo que hizo?
¡Mucho ha cambiado desde OP! Ahora hay una opción para colas "duplicadas" de alta disponibilidad también conocidas como "espejadas". Esto va bastante lejos para resolver el problema que describió. Ver http://www.rabbitmq.com/ha.html .
¿Está utilizando un sistema de renderizado distribuido como opción? Normalmente reservado para HPC pero muchos conceptos son lo mismo. Echa un vistazo a Qube o Deadline Render. También hay otras soluciones de código abierto. Todos tienen en cuenta la conmutación por error dado el alto grado de complejidad y el riesgo de fallas en algunos renders que pueden tomar horas por cuadro de secuencia de imágenes.
Es posible que desee comprobar IronMQ , cubre sus necesidades (duraderas, altamente disponibles, etc.) y es una solución nativa de la nube por lo que no necesita mantenimiento. Y hay un corredor de Aplery para ello: https://github.com/iron-io/iron_celery para que pueda comenzar a usarlo simplemente cambiando su configuración de Aplery.
Sospecho que Celery ligado a backends existentes es la solución incorrecta para las garantías de confiabilidad que necesita.
Dado que usted quiere un sistema de colas distribuidas con una gran durabilidad y garantías de confiabilidad, comenzaría buscando un sistema así (existen) y luego averiguando la mejor manera de enlazarlo en Python. Eso puede ser a través de Aplery y un nuevo backend, o no.
Utilicé Amazon SQS para esta propuesta y obtuve buenos resultados. Recibirá un mensaje hasta que lo elimine de la cola y le permita hacer crecer su aplicación tan alto como lo necesite.