Conexión del modelo de solicitud/respuesta HTTP con la cola asíncrona

Question

¿Cuál es una buena manera de conectar el modelo de petición/respuesta http síncrona con un modelo asíncrono basado en cola?

Cuando llega la solicitud HTTP del usuario genera una solicitud de trabajo que va a una cola (beanstalkd en este caso). Uno de los trabajadores recoge la solicitud, hace el trabajo y prepara una respuesta.

El modelo de cola no es de solicitud/respuesta: solo hay solicitudes, no respuestas. Entonces, la pregunta es, ¿qué mejor podemos hacer para que la respuesta vuelva al mundo de HTTP y la devuelva al usuario?

Ideas:

1. beanstalkd es compatible con temas de peso ligero o colas (que ellos llaman tubos). Podríamos crear un tubo para cada solicitud, hacer que el trabajador cree un mensaje en ese tubo, y tener el proceso http sentado y esperar en el tubo la respuesta. No me gusta particularmente, ya que tiene procesos apache sentados alrededor de tomar memoria.

2. Solicite la respuesta del cliente http. La solicitud HTTP inicial del usuario inicia el trabajo en la cola y vuelve inmediatamente. El cliente (el navegador del usuario) sondea periódicamente para obtener una respuesta. En el back-end, el trabajador pone su respuesta en memcached, y conectamos nginx a memcached para que el sondeo sea liviano.

3. Utilice Comet. Similar a la segunda opción, pero con una comunicación http más elegante para evitar el sondeo.

Me inclino por 2 ya que es fácil y conocido (no he utilizado el cometa). Supongo que probablemente también haya un modelo obvio mucho mejor que no haya pensado. ¿Qué piensas?

Answer 1

Aquí está how to implement request-response efficiently on JMS que puede ser útil (aunque Java/JMS céntrico). La idea general es crear una cola temporal por cliente/hilo y luego usar correlationID para correlacionar las solicitudes con las respuestas, etc.

Answer 2

Estoy buscando implementar un sistema Beanstalkd y memcached para ejecutar un número de procesos después de una solicitud - en este caso, buscando información cuando un usuario inicia sesión (la cantidad de mensajes que un usuario espera, por ejemplo). La información se almacena en Memcached y luego vuelve a leerse en la carga de la página siguiente.

Sin saber un poco más acerca de las tareas que está haciendo, no es tan fácil decir lo que se debe hacer o cómo. Sin embargo, la opción n. ° 2 es la más simple, y eso puede ser todo lo que necesita, dependiendo de lo que esté presionando a los trabajadores.

Answer 3

El sondeo es la solución simple; cometa es la solución más eficiente. Usted lo tiene clavado :)

personalmente me encanta cometa (aunque soy parcial, ya que ayudó a escribir WebSync), que bien permite a sus clientes se suscriben a un canal y reciben el mensaje cuando el proceso de servidor está listo. Funciona como un campeón.