Activación de PHP desde ActiveMQ

Antecedentes: Nuestro sistema actual involucra dos servicios (uno escrito en Java, el otro en PHP) que se comunican entre sí utilizando devoluciones de llamada HTTP. Nos gustaría migrar de devoluciones de llamadas HTTP a una arquitectura basada en mensajes utilizando ActiveMQ (u otro, si es necesario). Probablemente usemos STOMP para comunicarnos entre ellos. Eventualmente, el servicio de PHP se reescribirá en Java, pero eso no es parte de este proyecto.Activación de PHP desde ActiveMQ

Pregunta: ¿Cómo puede el sistema ActiveMQ notificar a PHP que un nuevo mensaje ha sido enviado a la cola que el sistema de PHP está suscrito? En el sistema actual, la devolución de llamada invoca de forma inherente al PHP y lo desencadena. Esto se va con una arquitectura basada en mensajes.

soluciones posibles:

Cron llamadas regularmente un script PHP que comprueba si hay nuevos mensajes. puaj.
Un proceso de PHP de larga ejecución que se repite, duerme y busca nuevos mensajes. menos yuck?
ActiveMQ llama a un script PHP cuando se publica un nuevo mensaje. bien, ¿cómo?
??

Fuente

2010-05-27 scompt.com

Tuve que hacer esto exactamente no hace mucho tiempo. Ejecutamos un script PHP de bloqueo continuo (activado a través de CRON) que hablaba de forma nativa con la aplicación PHP y AMQ a través de STOMP. El bloqueo rotativo nos permitió superponer los procesos en ejecución para una buena red de seguridad sin la duplicidad. Buena suerte. – allnightgrocery

@Inkspeak: Gracias por la idea. ¿Puedes aclarar a qué te refieres con 'rolling lock'? Tengo la idea básica de lo que es, pero no puedo encontrar una referencia al término en cualquier lugar. –

Perdón por eso. No estoy seguro de dónde viene ese término tampoco. Lo usamos cuando nos referimos a un proceso PHP CRON bloqueado porque no se ejecutan como daemons y cada ejecución sucesiva gira sobre la última cuando se libera el bloqueo. Aquí hay un ejemplo de ejecución (http://stackoverflow.com/questions/1780823/php-loop-acting-as-cronjobensensure-only-one-instance-running) hecho con rebaño (http://php.net/manual) /en/function.flock.php). – allnightgrocery

Consulte Camel. Se puede ejecutar dentro de ActiveMQ o solo. Camel crea "rutas" para los mensajes. En este caso, le sugiero que deje la URL de devolución de llamada PHP tal como está, y configure una ruta en Camel que tome los mensajes de la cola y los envíe a la URL de devolución de llamada. Luego puede usar Stomp dentro de PHP para enviar mensajes a ActiveMQ. Su código Java solo puede usar JMS para mensajes entrantes y salientes.

Fuente

2010-05-28 19:42:29

Gracias, investigaré eso. Para la posteridad, el enlace correcto es http://camel.apache.org –

Camel definitivamente parece ser el camino a seguir. Gracias por el gran consejo. –

¿Puede hacer que ActiveMQ ejecute comandos de shell? Si es así, simplemente haga que ActiveMQ ejecute el script PHP a través de la línea de comando siempre que haya un nuevo mensaje para procesar. Esto le ahorra ejecutar trabajos cron y tener un bucle PHP de larga ejecución.

Fuente

2010-05-27 16:42:37

Pregunta: ¿Cómo puede el sistema ActiveMQ notificar a PHP que se ha publicado un nuevo mensaje en la cola al que está suscrito el sistema PHP? En el sistema actual, la devolución de llamada invoca de forma inherente al PHP y lo desencadena. Esto se va con una arquitectura basada en mensajes.

Creo que está trabajando en la dirección incorrecta. Los consumidores consultan periódicamente con la cola los mensajes nuevos, y no al revés. Si la cola necesita notificar al consumidor para que lea de ella, entonces realmente no ha desacoplado estas aplicaciones como cree que tiene.

Fuente

2010-05-27 17:03:05

Creo que el problema que están tratando de resolver es que una pila LAMP (de la cual PHP es parte) está intrínsecamente ligada al mecanismo de solicitud/respuesta que el protocolo HTTP impone sobre ella, teniendo un consumidor (que verifica la cola de ActiveMQ) escrita en PHP es realizable, pero la duración de los procesos está naturalmente limitada por cualquier tiempo de espera en el protocolo HTTP.la solución es una de:

1 - No ejecute el suscriptor de PHP dentro de apache/HTTP, y como resultado, puede hacer un set_time_limit (0) y hacer que el suscriptor php se ejecute para siempre (hasta que se bloquee de todos modos), O

2 - Date cuenta de que un suscriptor realmente solo hace verificaciones "periódicas", con muchas cosas en el medio, así que en lugar de while (1) {do_queue_stuff(); dormir(); } quita el sueño, elimina el ciclo while y lo llama repetidamente desde Cron o similar.

Cada uno tiene sus propios beneficios, pero ambos son igual de buenos, SI la frecuencia cron() es suficientemente sintonizable. My Cron está limitado a ejecutarse cada minuto, lo cual no es muy frecuente, así que tendría que hacer una combinación de los dos anteriores: llamado desde cron cada minuto:

time = what_minute_is_it(); while (what_minute_is_it() == time) { do_queue_stuff(); sueño (1); }

Creo que lo que la gente puede pedir es una forma de hacer que el sistema ActiveMQ "insinúe" al sistema PHP Consumer que puede haber cosas en la cola que necesiten procesamiento y, como resultado, guardar en toda esta cola procesando cosas de inicio/parada/reposo/etc si realmente no hay nada que hacer. Camel parece ser la manera de hacer esto.

Fuente

2010-07-07 07:46:53 Buzz

Respuesta

Cuestiones relacionadas