Este documento presenta RSQueue, un bundle para Symfony2 que implementa una cola de mensajes basada en Redis. Proporciona funcionalidad de productor/consumidor y publicador/suscriptor para comunicación asíncrona entre sistemas. Explica cómo configurar y usar las colas, y agregar y procesar elementos de manera sencilla a través de comandos de consola. El objetivo es permitir tareas como envío de correo y registro de forma asíncrona para mejorar el rendimiento de las aplicaciones Symfony2.

1. The redis queue for Symfony2
by @mmoreram
RSQueue

2. • 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

3. • 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.

4. • 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.

5. ¡Flipencio somos
todos!
Como hacienda!

6. 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?

7. 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?

8. • 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.

9. 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.

10. • Hay algunos sistemas de colas bastante elaborados.
• Beanstalkd.
• Kafka.
• Gearman.
• RabbitMQ.
• JMS.
• OpenMQ.
• ZeroMQ.
• ActiveMQ.

11. Y si trabajo con
symfony2?
• ¡Pues molas!
• Aparte de molar, también tienes opciones
para trabajar con colas.
• RabbitMQBundle for Symfony2.
• GearmanBundle for Symfony2.

12. • 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.

13. 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%.

14. 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.

15. 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%!

16. RSQueue in action!

17. • 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!

18. • 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.

20. • 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!

22. • 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?

23. • 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.

25. 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.

26. • ¿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!

27. • 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.

29. 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.

32. 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.

33. 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.

34. ¡Muchas gracias!
¿Preguntas?