Un comercio electrónico Symfony envía la factura en PDF a través de Messenger tan pronto como se paga el pedido. El transporte AMQP está configurado, los trabajadores están en ejecución, excepto que el servicio de generación de PDF devuelve un error 503 durante veinte minutos. Los reintentos automáticos repiten el mismo mensaje cuarenta veces. Resultado: cuarenta correos electrónicos al cliente y una cola saturada que oculta las incidencias reales.
Messenger no es sólo un “autobús mágico”. Es un contrato entre el momento en que envías un mensaje y el momento en que un controlador lo ejecuta, con opciones de transporte, política de reintento, middleware y falla de transporte. Cada opción cambia la resiliencia y el riesgo de duplicación.
Transportes: sincronización, Doctrine, Redis, AMQP
Symfony enruta mensajes a través de transportes configurados en messenger.yaml. El enrutamiento (App\Message\* -> async) determina dónde va cada clase.
| Transporte | Casos de uso | Punto de vigilancia |
|---|---|---|
| sincronización | Desarrollo, manipuladores ultrarrápidos | Latencia de máscaras y tiempos de espera en producción |
| doctrina://predeterminado | Pequeño volumen, sin Redis | tabla messenger_messages, cerraduras de base |
| redis:// | Líneas ligeras, baja explotación | Persistencia de Redis, mensaje TTL |
| amqp:// (ConejoMQ) | Producción con múltiples trabajadores, DLX | Intercambios de topología y archivos que deben documentarse |
En un solo VPS, Doctrine puede ser suficiente para cientos de mensajes por hora. Tan pronto como los controladores llaman a API externas o duran más de unos pocos segundos, un intermediario dedicado evita el bloqueo de solicitudes web y simplifica el escalamiento horizontal de los trabajadores "messenger:consume".
Elegir el transporte significa elegir quién tiene la garantía de entrega, no solo dónde almacenar el JSON.
Reintentos, retrasos y errores transitorios versus permanentes
El componente RetryStrategy (max_retries, delay, multiplier) reintenta mensajes fallidos. Sin distinguir entre "API no disponible" y "carga útil no válida", está amplificando un error de código.
Aplique pocos reintentos (de tres a cinco) con retroceso exponencial en errores de red. Lanza UnrecoverableMessageHandlingException para errores comerciales definitivos. Establecer un tiempo de espera del controlador: un controlador que espera indefinidamente a un tercero bloquea a un trabajador completo.
Prueba en preparación: cierre intencionalmente el servicio de destino y observe el comportamiento de la cola, no solo el registro del controlador.
Transporte fallido y reproducción controlada.
Después de agotar los reintentos, Messenger puede enrutarse a un transporte fallido (fallido://, cola dedicada o tabla Doctrine). Esta es tu zona de cuarentena.
Alerta cuando el transporte de fallas no está vacío. Utilice messenger:failed:show y messenger:failed:retry para reproducir después de la corrección. Defina una política de retención: no guarde seis meses de mensajes muertos sin analizar.
Sin transporte de fallas, dependiendo de la configuración, los mensajes se pueden eliminar o bloquear a un trabajador en un bucle, dos formas diferentes de "perder" visibilidad.
Coherencia de trabajadores, supervisión y despliegue
Los trabajadores de messenger:consume async -vv --time-limit=3600 --memory-limit=128M deben ser supervisados como servicios de producción. Después de la implementación, reinicie los trabajadores (señale o --stop-when-empty y luego reinicie). Asegúrese de tener la misma versión de código y variables de entorno que PHP-FPM. Establezca límites de memoria y de tiempo para evitar fugas lentas.
En Kubernetes, una implementación separada para consumidores evita escalar pods web cuando solo está creciendo la cola. El ajuste de escala automático según la longitud del archivo (KEDA, Prometheus) escala el componente correcto, no el frente HTTP.
Middleware, enrutamiento y controladores síncronos olvidados
Verifique que cada mensaje comercial crítico pase por "async". Un controlador pesado que se deja sincronizado crea tiempos de espera de nginx y errores 502 intermitentes que son difíciles de reproducir.
El middleware DoctrinePingConnectionMiddleware y DoctrineCloseConnectionMiddleware evitan conexiones MySQL obsoletas en trabajadores de larga duración, un clásico en alojamiento compartido o una base de datos administrada con un tiempo de espera agresivo.
La cumbre: el transporte no garantiza la semántica empresarial
Entonces la pregunta no es "¿Redis o RabbitMQ?" " primero. Es: ¿qué sucede si este controlador se ejecuta dos veces? Mientras la respuesta sea confusa, el transporte es solo un detalle de infraestructura.
Decide y avanza sin puntos ciegos
Enumere sus mensajes con latencia, criticidad e idempotencia aceptables. Elija el transporte y el transporte de fallos en consecuencia. Configure reintentos con retroceso, supervise a los trabajadores y pruebe la falla del servicio posterior en la etapa de preparación antes de la producción.
Para dimensionar Redis, RabbitMQ o trabajadores en VPS y en la nube europeos, consulte el directorio y el comparador. Las guías completan el marco de infraestructura PHP. Ejercicio útil: simule una excepción permanente: el mensaje debe llegar al transporte fallido sin bloquear toda la cola.
Preguntas frecuentes
¿Cuál es la diferencia entre sincronización y asíncrono en Messenger?
El transporte de sincronización ejecuta el controlador inmediatamente en la solicitud HTTP: conveniente en desarrollo, peligroso en producción para tareas lentas. Async envía el mensaje a una cola consumida por trabajadores separados.
¿Doctrina de transporte o Redis/AMQP?
Doctrine es adecuado para proyectos pequeños sin un intermediario dedicado, pero la tabla de mensajes se convierte en un cuello de botella. Redis o AMQP escalan mejor a medida que aumenta el volumen, la latencia o el paralelismo.
¿Para qué se utiliza el transporte de fallas?
Aísla los mensajes fallidos después de agotar los reintentos, para su inspección y reproducción manual. Sin el transporte de fallos configurado, los mensajes pueden desaparecer o bloquear el consumo.
¿Cómo evitar duplicados en los reintentos?
Haga que los controladores sean idempotentes (bloqueo, estado base) y limite los reintentos en caso de errores no transitorios. Utilice claves comerciales únicas; no confíe en la entrega única de forma predeterminada.
Antes de optimizar el corredor, haga una pregunta simple: si este mensaje se procesa dos veces, ¿sobrevive su negocio?