Rsqueue bundle 06.2013
1 recomendación629 vistas
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.
Rsqueue bundle 06.2013
- 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.
- 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%!
- 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.