2010-03-02 17 views
6

Necesito configurar una cola de trabajo/mensaje con la opción de establecer un retraso para la tarea para que no sea recogido inmediatamente por un trabajador libre, pero después de un cierto tiempo (puede variar de una tarea a otra). Busqué en un par de soluciones de cola de Linux (rabbitmq, gearman, memcacheq), pero ninguno de ellos parece ofrecer esta característica de la caja.Cola escalable de trabajo/mensaje escalable con retraso

¿Alguna idea sobre cómo podría lograr esto?

Gracias!

Respuesta

11

He usado BeanstalkD con gran efecto, usando la opción de demora al insertar un nuevo trabajo para esperar varios segundos hasta que el artículo esté disponible para ser reservado.

Si está haciendo retrasos a largo plazo (más de 30 segundos), o los trabajos son algo importantes de realizar (más tarde), entonces también tiene un sistema de registro binario para que cualquier caída de daemon todavía tenga un registro del trabajo. Dicho esto, he puesto cientos de miles de trabajos en vivo a través de instancias de Beanstalkd y los trabajadores que escribí siempre fueron más problemáticos que el servidor.

+0

Gracias por sus comentarios, he estado buscando en beanstalkd en los últimos días y se ve muy bien. Y tienes razón, la lógica y la administración de los trabajadores es engañosa :) – idevelop

1

Puede utilizar un intermediario AMQP (como RabbitMQ) y tengo un "agente" (por ejemplo, un proceso python creado usando pyton-amqplib) que se encuentra en un intercambio intercepta mensajes específicos (routing_key); una vez que ha transcurrido un tiempo, envíe de vuelta el mensaje en el intercambio con un routing_key diferente.

Me doy cuenta de que esto significa "traducir/mapear" routing keys pero funciona. Trabajar con RabbitMQ y python-amqplib es muy sencillo.

+1

Pensé en esto, pero si el agente de espera muere mientras espera que transcurra el temporizador, el mensaje nunca se agrega a la cola. Tal vez podría solucionar esto teniendo una segunda fila permanente y un agente con múltiples temporizadores internos. Aún así, parece una solución fea. – idevelop

+0

Bueno, lidiar con este modo de falla es parte del juego. Me sorprendería si la funcionalidad que está solicitando se generaliza en AMQP Brokers, ya que va en contra del objetivo principal: minimizar la latencia. – jldupont

+0

Gracias por sus respuestas. Creo que voy a probar Beanstalkd, parece estar bien, y apoyo el "retraso" del que estaba hablando. – idevelop

Cuestiones relacionadas