Rsqueue bundle 06.2013

The redis queue for Symfony2 by @mmoreram

RSQueue

• Flipencio necesita mandar, urgentemente, una carta a su querida prima Primencia, en Albacete

• Flipencio es de Barcelona, así que como siempre, se sube a su burro Burr'oh y tras 30 dias de viaje entre praderas y bosques, llega a su destino.

• 60 dias mas tarde, su mujer sentada en la cocina, esperando, enfadada. ¿Porque has tardado tanto? Le pregunta...

• Hoy duermo en el sofá... #fail

• El camino es largo, piensa él. Tiene que alimentar un burro solo para mandar cartas y su mujer está siempre enfadada con él porque pasa poco tiempo con ella.

• ¡Ideaca!

• Monto una empresa de burros que solo mande correos, los alimente con el mejor manjar y me permita estar con mi querida mujer.

• La empresa Burreos S.L. se funda y actualmente tiene una flota nacional de 200 burros de la mejor raza, grandes, resistentes y fuertes, operando en todos los pueblos nacionales. ¡Tiene 30000 usuarios!

• Permite a nuestro entrañable personaje estar en casa mucho mas tiempo leyendo "50 sombras de grey", y sus cartas llegan de todas formas.

• Permite a Burreos autogestionarse y desarrollarse de forma independiente.

¡Flipencio somos todos!Como hacienda!

Cuantos de nuestros proyectos...

• ¿Manda correos a usuarios?

• ¿Hace logs en producción? No deberían ser muchos logs...

• ¿Escribe estadísticas para estrategias de negocio?

• ¿Actualiza un índice como ElasticS o SolR?

Cuantos de nuestros proyectos...

• ¿Hacemos esperar a nuestros usuarios para tales tareas? P.e. Un mail de confirmación.

• Tengamos en cuenta que existe una relación directa entre tiempo de carga de página y porcentaje de rebote de usuarios.

• ¿Que hacemos al respecto?

• Montemos una empresa que mande mails, una que escriba estadísticas y una que nos escriba en logs de forma asíncrona.

• Desde nuestros proyectos solo informamos qué queremos hacer, y que estas empresas se encarguen de ello.

• Nosotros nos encargamos de lo que realmente nos tenemos que encargar, de lo que al usuario le interesa.

Bienvenidas seáis, colas.

• Comunicación entre sistemas de forma asíncrona.

• A comunica a B que tiene que hacer un trabajo, y sigue con su ejecución aunque B no esté levantado. Lo añade a una lista de TODOs.

• B recoge los elementos de la lista cuando puede y ordenadamente, ejecuta los trabajos.

• Solo hay una condición. A y B deben entender ambos un sistema de escritura. Por ejemplo, JSON.

• Hay algunos sistemas de colas bastante elaborados.

• Beanstalkd.

• Kafka.

• Gearman.

• RabbitMQ.

• JMS.

• OpenMQ.

• ZeroMQ.

• ActiveMQ.

Y si trabajo con symfony2?

• ¡Pues molas!

• Aparte de molar, también tienes opciones para trabajar con colas.

• RabbitMQBundle for Symfony2.

• GearmanBundle for Symfony2.

• Pero... ¿Y hay algo que trabaje sobre Redis?

• Redis está concebido, en parte, como un sistema de colas. No hay ninguna implementación ( decente ) para symfony2 que resuelva esta carencia.

• ¡Rsqueue lo hace! O almenos pretende hacerlo.

RSQueueBundle• Redis Simple Queue bundle for Symfony2.

• Proporciona implementación de modelo Producer/Consumer y Publisher/Subscriber sobre sistema Redis.

• Trabaja con eventos propios y serializadores propios ( permite nuevos desarrollos ).

• Open source 110%.

Producer/Consumer• Muy simple. Producers escriben, consumers

leen.

• Los consumers, recogen el primer job de la cola y lo procesan. Capacidad para encolar de nuevo en caso de error de proceso.

• Un elemento solo es procesado por una cola, por ejemplo, un mail lo manda solo un consumidor.

Publisher/Subscriber• El concepto es practicamente igual, con la única

diferencia que un item es procesado por todos los subscribers de la cola a la cual pertenece.

• Por ejemplo, por cada visita añadimos un job en la cola A.

• Hay 5 procesos distintos que, con estos elementos, crean estadísticas.

• ¡Procesos desacoplados al 100%!

RSQueue in action!

• Toda la interacción con el sistema de colas funciona sobre la capa de servicio.

• Para los consumers y los subscribers, hay una forma muy sencilla de trabajar con commands de Symfony2.

• ¡Custom events para todos!

• Para empezar, debemos elegir que tipo de serialización queremos utilizar, por defecto json.

• Tenemos json, php y la posibilidad de implementar nuestro serializador propio.

• También tenemos que definir el conjunto de colas con los que vamos a trabajar. Una vez definidas, en nuestros proyecto trataremos solo con sus alias.

• Siguiendo el desarrollo del proyecto, se podrá configurar también distintas conexiones.

• Por el momento, solo localhost:6379

• ¡Seguimos! Una vez configurado, vamos a insertar un elemento en nuestra cola de nuevos usuarios.

• ¡Recordemos, debemos trabajar siempre con los alias de las colas!

• Una vez encolado nuestro mail, nos desentendemos completamente del resultado del envío ( el consumer deberá tratar los errores ).

• Nos ahorramos instalar sistemas de mailing como swiftmailer en nuestro proceso y también el tiempo que conlleva mandar un mail.

• ¡Vale! ¡Encolado! ¿Pero ahora que?

• RSQueue nos permite crear fácilmente comandos que se comporten como consumers.

• Simplemente tenemos que definir que colas queremos consumir, y como tratar los datos recibidos en función de la cola, especificando que método queremos ejecutar en cada caso.

php app/console test:consumer --timeout 5 --iterations 10 --sleep 1

• Timeout: cuando un proceso consume una cola, se puede especificar el número de segundos antes de morir si no hay elementos. 0, nunca muere, paciencia infinita, por defecto.

• Iterations: cuantos elementos debe consumir antes de morir. 0, infinitos, por defecto.

• Sleep: cuanto debe esperar entre elemento y elemento. Muy útil para parsing. 0, sin sleep, por defecto.

• ¿Has dicho morir?

• Si. Un proceso debería morir cada cierto número de iteraciones por cuestiones de memoria.

• Deberíamos tener instalado ( si o si ) un supervisord, que se encarga de levantar x instancias de un proceso, manteniendo siempre el número de instancias vivas. ¡Función alive ON!

• Igual funciona un comando del estilo subscriber o psubscriber ( la segunda defines las colas a las que suscribirse por expresión regular ).

• Por otro lado, el producer y el publisher funcionan de la misma forma de cara el usuario.

Rizando el rizo...

• Queremos añadir en la cola de eventos un objeto DateTime cada vez que un subscriber o un consumer recoge un dato de una cola.

• Creamos un servicio con dos métodos, y subscribimos los métodos a dos de los eventos propios de RSQueue.

Symfony2 profiler• Se añade en la toolbar del profiler una nueva

sección, donde te informa en cada ejecución todas las interacciones con los servicios ( producers y publishers ).

• También proporciona información sobre las colas afectadas y los payloads con los que se han tratado.

• Asi podemos saber si hemos mandado el mail.

Conclusión• Trabaja con colas... ¡Sin miedo!

• Si trabajas en symfony2, ya no tienes escusa.

• El proyecto irá creciendo, con nuevas funcionalidades, sobretodo de análisis y monitorización.

• Cualquier ayuda será agradecida.

¡Muchas gracias! ¿Preguntas?