Cómo configurar Beanstalkd con PHP

Question

Recientemente he estado investigando el uso de Beanstalkd con PHP. He aprendido bastante, pero tienen algunas preguntas acerca de la configuración de un servidor, etc.

Así es como yo lo veo de trabajo:

1. instalo beanstalkd y las dependencias (como libevent) en mi servidor Ubuntu Luego inicio el daemon Beanstalkd (que básicamente debería ejecutarse en todo momento).
2. En algún lugar de mi sitio web (como cuando un usuario realiza algunas acciones, etc.) las tareas se agregan a varios tubos dentro de la cola de Beanstalkd.

3. Tengo un script bash (como el siguiente) que se ejecuta como un deamon que básicamente ejecuta un script PHP.

   #!/bin/sh 
   php worker.php 
   

4) El guión trabajador tendría algo como esto para ejecutar los en cola tareas:

while(1) { 
    $job = $this->pheanstalk->watch('test')->ignore('default')->reserve(); 
    $job_encoded = json_decode($job->getData(), false); 
    $done_jobs[] = $job_encoded; 
    $this->log('job:'.print_r($job_encoded, 1)); 
    $this->pheanstalk->delete($job); 
} 

Ahora aquí están mis preguntas en base a la configuración anterior (que me corrija si me me equivoco al respecto):

1. Supongamos que tengo la tarea de importar una fuente RSS en una base de datos o algo así. Si 10 usuarios hacen esto a la vez, todos estarán en cola en el tubo de "prueba". Sin embargo, solo se ejecutarían uno a la vez. ¿Sería mejor tener 10 tubos diferentes todos ejecutando al mismo tiempo?

2. Si necesito más tubos, ¿significa eso que necesitaría 10 scripts de trabajador? Uno para cada tubo que se ejecuta simultáneamente con básicamente el mismo código, excepto el literal de cadena en la función watch().

3. Si ejecuto ese script como daemon, ¿cómo funciona? ¿Ejecutará constantemente el script worker.php? Esa secuencia de comandos se repite hasta que la cola está vacía teóricamente, ¿por lo que no debería iniciarse solo una vez? ¿Cómo decide el daemon con qué frecuencia ejecutar worker.php? ¿Es solo un ajuste?

Gracias!

Answer 1

1. Si el trabajador no tarda demasiado en recuperar la alimentación, estará bien. Puede ejecutar varios trabajadores si es necesario para procesar más de uno a la vez. Tengo un sistema (actualmente usando Amazon SQS, pero he hecho algo similar con BeanstalkD anteriormente), con hasta 200 (o más) trabajadores sacando de la cola.
2. Una secuencia de comandos de un solo trabajador (la misma secuencia de comandos se ejecuta varias veces) debe estar bien: la secuencia de comandos puede ver múltiples tubos al mismo tiempo, y la primera disponible estará reservada. También puede usar el comando job-stat para ver de dónde vino un trabajo en particular (qué tubo), o poner alguna metainformación en el mensaje si necesita distinguir cada tipo de otro.
3. Un buen ejemplo de funcionamiento de un trabajador es described here. También he agregado supervisord (también, un useful post para comenzar) para iniciar fácilmente y seguir ejecutando una cantidad de trabajadores por máquina (ejecuto scripts de shell, como en el first link).Limitaría el número de veces que se repite y también incluiré un número en el reserve() para que espere unos segundos o más para que el siguiente trabajo esté disponible sin perder el control en un ciclo cerrado que no pausa en absoluto, incluso si no había nada que hacer.

Adición:

1. El script de shell seria manejado tantas veces como sea necesario. (el enlace muestra cómo volver a ejecutarlo según sea necesario con exec $@). Cada vez que el script php sale, vuelve a ejecutar el PHP.
2. Aparentemente hay una aplicación Djanjo para mostrar algunas estadísticas, pero es lo suficientemente trivial para conectarse con el daemon, obtener una lista de tubos y luego obtener las estadísticas de cada tubo, o simplemente cuenta.