Ir al contenido 
Las tareas PHP asíncronas resuelven los cuellos de botella típicos cuando las tareas cron provocan picos de carga, tiempos de ejecución prolongados y falta de transparencia. Te muestro cómo hacerlo. PHP asíncrono con colas y trabajadores, alivia las solicitudes web, escala las cargas de trabajo y amortigua las caídas sin frustraciones.
Puntos centrales
Para empezar, resumiré las ideas principales en las que baso este artículo y que aplico a diario en la práctica. Conceptos básicos
- Desacoplamiento de Request y Job: Webrequest sigue siendo rápido, los trabajos se ejecutan en segundo plano.
- Escala Acerca de los grupos de trabajadores: más instancias, menos tiempo de espera.
- fiabilidad Mediante reintentos: volver a iniciar las tareas fallidas.
- Transparencia Mediante supervisión: longitud de la cola, tiempos de ejecución, tasas de error a la vista.
- Separación Según la carga de trabajo: corta, predeterminada, larga, con los límites correspondientes.
Por qué las tareas programadas ya no son suficientes
Una tarea programada se inicia estrictamente según la hora, no según una hora real. Evento. En cuanto los usuarios activan algo, quiero reaccionar inmediatamente, en lugar de esperar hasta el siguiente minuto completo. Cuando se ejecutan muchas tareas cron simultáneamente, se produce un pico de carga que sobrecarga temporalmente la base de datos, la CPU y la E/S. La paralelización sigue siendo limitada y me resulta difícil establecer prioridades detalladas. Con las colas, puedo enviar las tareas inmediatamente a una cola, dejar que varios trabajadores las ejecuten en paralelo y mantener la interfaz web en funcionamiento continuo. responsivo. Quienes utilizan WordPress se benefician además si Entender WP-Cron y desea configurarlo correctamente para que las planificaciones programadas se envíen de forma fiable a la cola.
Procesamiento asíncrono: explicación breve de Job–Queue–Worker
Incluyo las tareas costosas en un claro Trabajo, que describe lo que hay que hacer, incluyendo referencias de datos. Este trabajo va a parar a una cola que utilizo como amortiguador contra picos de carga y que da servicio a varios consumidores. Un trabajador es un proceso permanente que lee los trabajos de la cola, los ejecuta y confirma el resultado. Si un trabajador falla, el trabajo permanece en la cola y puede ser procesado más tarde por otra instancia. Este acoplamiento flexible hace que la aplicación en su conjunto sea tolerante a los errores y garantiza tiempos de respuesta consistentes en el frontend.
Así funcionan las colas y los trabajadores en el entorno PHP
En PHP, defino un trabajo como una clase simple o como un objeto serializable. carga útil con Handler. La cola puede ser una tabla de base de datos, Redis, RabbitMQ, SQS o Kafka, dependiendo del tamaño y los requisitos de latencia. Los procesos de trabajo se ejecutan de forma independiente, a menudo como servicios de supervisión, Systemd o contenedores, y recogen trabajos de forma continua. Utilizo mecanismos ACK/NACK para señalar claramente los procesos correctos y los erróneos. Lo importante es que yo Tasa de rendimiento el trabajador se adapte al volumen de trabajo previsto, de lo contrario la cola crecerá sin control.
Trabajadores PHP en entornos de alojamiento: equilibrio en lugar de cuellos de botella
Demasiado pocos trabajadores PHP generan atascos, demasiados consumen CPU y RAM y ralentizan todo, incluyendo Solicitudes web. Planifico el número de trabajadores y la concurrencia por cola por separado, para que las tareas cortas no se atasquen en informes largos. Además, establezco límites de memoria y reinicios periódicos para detectar fugas. Si no estás seguro acerca de los límites, los núcleos de CPU y la concurrencia, lee mi breve Guía sobre los trabajadores PHP con estrategias de equilibrio típicas. Este equilibrio crea, al final, la necesaria Planificabilidad para un crecimiento y tiempos de respuesta uniformes.
Tiempo de espera, reintentos e idempotencia: garantizar un procesamiento fiable
Le doy a cada trabajo una Tiempo de espera, para que ningún trabajador se quede atascado indefinidamente en tareas defectuosas. El bróker recibe un tiempo de espera de visibilidad ligeramente superior a la duración máxima del trabajo, para que una tarea no aparezca por error dos veces. Dado que muchos sistemas utilizan una entrega „al menos una vez“, implemento controladores idempotentes: las llamadas duplicadas no dan lugar a correos electrónicos o pagos duplicados. A las repeticiones les aplico un backoff para no sobrecargar las API externas. Así mantengo la Tasa de error bajo y puede diagnosticar problemas con precisión.
Separar cargas de trabajo: cortas, predeterminadas y largas
Creo colas separadas para trabajos cortos, medios y largos, de modo que una exportación no bloquee diez notificaciones y la Usuario hace esperar. Cada cola tiene sus propios grupos de trabajadores con límites adecuados para el tiempo de ejecución, la concurrencia y la memoria. Las tareas cortas se benefician de una mayor paralelidad y tiempos de espera estrictos, mientras que los procesos largos reciben más CPU y tiempos de ejecución más largos. Controlo las prioridades mediante la distribución de los trabajadores entre las colas. Esta clara separación garantiza una previsibilidad Latencias en todo el sistema.
Comparación de opciones de cola: cuándo es adecuado cada sistema
Elijo deliberadamente la cola en función de la latencia, la persistencia, el funcionamiento y la trayectoria de crecimiento, para no tener que realizar una costosa migración más adelante y que la Escala se mantiene bajo control.
| Sistema de cola | Utilice | Latencia | Características |
|---|---|---|---|
| Base de datos (MySQL/PostgreSQL) | Configuraciones pequeñas, inicio sencillo | Medio | Manejo sencillo, pero rápido cuello de botella con carga elevada |
| Redis | Carga pequeña a mediana | Bajo | Muy rápido en la RAM, necesita claro Configuración por su fiabilidad |
| RabbitMQ / Amazon SQS / Kafka | Sistemas grandes y distribuidos | Bajo a medio | Amplias funciones, buenas Escala, más gastos de explotación |
Usar Redis correctamente: evitar los obstáculos típicos
Redis parece increíblemente rápido, pero una configuración incorrecta o unas estructuras de datos inadecuadas provocan comportamientos extraños. Tiempos de espera. Presto atención a las estrategias AOF/RDB, la latencia de la red, las cargas útiles demasiado grandes y los comandos bloqueantes. Además, separo el almacenamiento en caché y las cargas de trabajo de la cola para que los picos de caché no ralenticen la recogida de trabajos. Para obtener una lista de verificación compacta de configuraciones incorrectas, consulte esta guía sobre Configuraciones incorrectas de Redis. Quien realiza un ajuste limpio, obtiene un resultado rápido y fiable. cola para muchos casos de aplicación.
Monitorización y escalabilidad en la práctica
Mido la longitud de la cola a lo largo del tiempo, ya que el aumento de atrasos indican la falta de recursos de trabajo. La duración media de los trabajos ayuda a establecer tiempos de espera realistas y a planificar las capacidades. Las tasas de error y el número de reintentos me indican cuándo hay dependencias externas o rutas de código inestables. En los contenedores, escalo automáticamente los trabajadores basándome en métricas de CPU y colas, mientras que las configuraciones más pequeñas funcionan con scripts sencillos. La visibilidad sigue siendo crucial, porque solo los números proporcionan una base sólida. Decisiones habilitar.
Cron plus Queue: clara distribución de funciones en lugar de competencia
Utilizo Cron como temporizador, que programa tareas temporizadas, mientras que los trabajadores realizan el trabajo real. Trabajo asumir. De este modo, no se producen picos de carga masivos cada minuto y los eventos espontáneos reaccionan inmediatamente con trabajos en cola. Planifico los informes recopilatorios recurrentes mediante Cron, pero cada detalle del informe lo procesa un trabajador. Para las configuraciones de WordPress, sigo las directrices que se indican en „Entender WP-Cron“, para que la planificación siga siendo coherente. De este modo, mantengo el orden en la sincronización y me aseguro Flexibilidad en la ejecución.
Entornos de ejecución PHP modernos: RoadRunner y FrankenPHP en combinación con colas
Los procesos de trabajo persistentes ahorran sobrecarga de inicio, mantienen abiertas las conexiones y reducen el Latencia. RoadRunner y FrankenPHP apuestan por procesos duraderos, grupos de trabajadores y memoria compartida, lo que aumenta considerablemente la eficiencia bajo carga. En combinación con las colas, mantengo una tasa de rendimiento uniforme y me beneficio de los recursos reutilizados. A menudo separo el manejo de HTTP y los consumidores de colas en grupos propios, para que el tráfico web y los trabajos en segundo plano no se interfieran mutuamente. Quien trabaja así, genera una tranquilidad Actuación incluso con una demanda muy variable.
Seguridad: tratar los datos con moderación y cifrados
Nunca incluyo datos personales directamente en la carga útil, solo identificadores que recargo más tarde para Protección de datos . Todas las conexiones con el bróker están encriptadas y utilizo el cifrado en reposo, siempre que el servicio lo ofrezca. El productor y el consumidor reciben autorizaciones separadas con derechos mínimos. Roto regularmente los datos de acceso y mantengo los secretos fuera de los registros y las métricas. Este enfoque reduce la superficie de ataque y protege la Confidencialidad información confidencial.
Escenarios de uso práctico para Async-PHP
Ya no envío correos electrónicos en Webrequest, sino que los clasifico como trabajos para que los usuarios no tengan que esperar en el Envío Esperar. Para el procesamiento de medios, subo imágenes, respondo inmediatamente y genero miniaturas más tarde, lo que hace que la experiencia de carga sea notablemente fluida. Inicio los informes con muchos registros de forma asíncrona y proporciono los resultados como descarga tan pronto como el trabajador termina. Para las integraciones con sistemas de pago, CRM o marketing, desacoplo las llamadas a la API para amortiguar con tranquilidad los tiempos de espera y las fallas esporádicas. Traslado el calentamiento de la caché y las actualizaciones del índice de búsqueda a un segundo plano para que el INTERFAZ DE USUARIO sigue siendo rápido.
Diseño de tareas y flujo de datos: cargas útiles, control de versiones y claves idempotentes
Mantengo las cargas útiles lo más ligeras posible y solo guardo referencias: una ID, un tipo, una versión y una clave de correlación o idempotencia. Con una versión, identifico el esquema de carga útil y puedo seguir desarrollando los controladores con tranquilidad, mientras que los trabajos antiguos se siguen procesando correctamente. Una clave de idempotencia evita efectos secundarios duplicados: se registra en la memoria de datos al inicio y se compara en caso de repeticiones, para que no se genere un segundo correo electrónico o una segunda reserva. Para tareas complejas, desgloso los trabajos en pasos pequeños y claramente definidos (comandos), en lugar de agrupar flujos de trabajo completos en una sola tarea, para que los reintentos y el tratamiento de errores objetivo agarrar.
Para las actualizaciones utilizo el Modelo de bandeja de salida: Los cambios se escriben en una tabla de salida dentro de una transacción de base de datos y, a continuación, un trabajador los publica en la cola real. De este modo, evito inconsistencias entre los datos de la aplicación y los trabajos enviados y obtengo un „al menos una vez“Entrega con efectos secundarios claramente definidos.
Imágenes de error, DLQ y „mensajes venenosos“
No todos los errores son transitorios. Distingo claramente entre problemas que se resuelven mediante Reintentos resolver (red, límites de velocidad) y errores definitivos (datos faltantes, validaciones). Para estos últimos, configuro un Cola de mensajes no entregados (DLQ): tras un número limitado de reintentos, el trabajo acaba allí. En la DLQ guardo el motivo, el extracto del seguimiento de la pila, el número de reintentos y un enlace a las entidades relevantes. Así puedo decidir de forma específica: reiniciar manualmente, corregir los datos o arreglar el controlador. Reconozco los „mensajes venenosos“ (trabajos que se bloquean de forma reproducible) por su fallo inmediato y los bloqueo a tiempo para que no ralenticen todo el grupo.
Apagado elegante, implementaciones y reinicios progresivos
Durante la implementación, me ciño a Apagado elegante: El proceso finaliza los trabajos en curso, pero no acepta nuevos. Para ello, intercepto SIGTERM, establezco un estado de „drenaje“ y, si es necesario, prolongo el tiempo de visibilidad (Visibility Timeout) para que el broker no asigne el trabajo a otro trabajador. En configuraciones de contenedores, planifico el periodo de gracia de terminación de forma generosa, en función de la duración máxima del trabajo. Reduzco los reinicios continuos a pequeños lotes para que el Capacidad no se bloquee. Además, configuro Heartbeats/Healthchecks, que garantizan que solo los trabajadores sanos realicen tareas.
Batching, límites de velocidad y contrapresión
Cuando es conveniente, agrupo muchas operaciones pequeñas. lotes Juntos: un trabajador carga 100 ID, los procesa de una sola vez y reduce así la sobrecarga debida a la latencia de la red y al establecimiento de la conexión. En el caso de las API externas, respeto los límites de velocidad y controlo los mecanismos de token bucket o leaky bucket. tasa de consulta. Si aumenta la tasa de errores o crecen las latencias, el trabajador reduce automáticamente la paralelidad (concurrencia adaptativa), hasta que la situación se estabilice. La contrapresión significa que los productores reducen su producción de trabajos cuando la longitud de la cola supera determinados valores umbral, lo que me permite evitar avalanchas que desborden el sistema.
Prioridades, equidad y separación de clientes
No solo establezco prioridades mediante colas de prioridad individuales, sino también mediante ponderado Asignación de trabajadores: un grupo trabaja con 70% „short“, 20% „default“ y 10% „long“, para que ninguna categoría se quede completamente sin recursos. En configuraciones multitenant, aíslo los clientes críticos con colas propias o grupos de trabajadores dedicados para Vecinos ruidosos . Para los informes, evito las prioridades rígidas que retrasan indefinidamente los trabajos de larga duración; en su lugar, planifico franjas horarias (por ejemplo, por la noche) y limito el número de trabajos pesados paralelos para que la plataforma pueda funcionar durante el día. vivaz restos.
Observabilidad: registros estructurados, correlación y SLO
Registro de forma estructurada: ID del trabajo, ID de correlación, duración, estado, recuento de reintentos y parámetros importantes. Con ello correlaciono la solicitud del frontend, el trabajo en cola y el historial del trabajador. A partir de estos datos defino SLOs: aproximadamente 95% de todos los trabajos „cortos“ en 2 segundos, „por defecto“ en 30 segundos, „largos“ en 10 minutos. Las alertas se activan cuando aumenta el backlog, las tasas de error, los tiempos de ejecución inusuales o cuando crecen los DLQ. Los runbooks describen pasos concretos: escalar, reducir, reiniciar, analizar DLQ. Solo con métricas claras puedo tomar buenas decisiones. Decisiones sobre capacidad.
Desarrollo y pruebas: locales, reproducibles, resistentes
Para el desarrollo local utilizo una Cola falsa o una instancia real en modo Dev e inicio Worker en primer plano para que los registros sean visibles de inmediato. Escribo pruebas de integración que ponen en cola un trabajo, ejecutan Worker y comprueban el resultado esperado de la página (por ejemplo, un cambio en la base de datos). Simulo pruebas de carga con trabajos generados y mido el rendimiento, los percentiles 95/99 y las tasas de error. Es importante la siembra reproducible de datos y los controladores deterministas para que las pruebas se mantengan estables. Las fugas de memoria se detectan en pruebas de resistencia; planifico reinicios periódicos y superviso la curva de almacenamiento.
Gestión de recursos: CPU frente a E/S, memoria y paralelismo
Distingo entre tareas que requieren mucho uso de la CPU y tareas que requieren mucho uso de E/S. Limito claramente la paralelización de las tareas que requieren mucho uso de la CPU (por ejemplo, transformaciones de imágenes) y reservo núcleos. Las tareas que requieren mucho uso de E/S (red, base de datos) se benefician de una mayor concurrencia, siempre que la latencia y los errores se mantengan estables. Para PHP, apuesto por opcache, presto atención a las conexiones reutilizables (conexiones persistentes) en trabajadores persistentes y libero objetos explícitamente al final de un trabajo para Fragmentación . Un límite estricto por trabajo (memoria/tiempo de ejecución) evita que los valores atípicos afecten a todo el grupo.
Migración gradual: del cronjob al enfoque «queue-first»
Realizo la migración de forma incremental: primero traslado las tareas no críticas de correo electrónico y notificaciones a la cola. A continuación, sigo con el procesamiento de medios y las llamadas de integración, que suelen provocar tiempos de espera. Las tareas cron existentes siguen siendo el reloj, pero trasladan su trabajo a la cola. En el siguiente paso, separo las cargas de trabajo en cortas/predeterminadas/largas y las mido de forma sistemática. Por último, elimino la lógica cron pesada tan pronto como los trabajadores funcionan de forma estable y paso a En función de los acontecimientos Puntos de en cola (por ejemplo, „usuario registrado“ → „enviar correo electrónico de bienvenida“). De este modo se reduce el riesgo y el equipo y la infraestructura crecen de forma controlada según el nuevo patrón.
Gobernanza y funcionamiento: políticas, cuotas y control de costes
Defino políticas claras: tamaño máximo de carga útil, tiempo de ejecución permitido, destinos externos permitidos, cuotas por cliente y franjas horarias diarias para trabajos costosos. Controlo los costes escalando los grupos de trabajadores por la noche, agrupando los trabajos por lotes en horas valle y estableciendo límites para los servicios en la nube que Valores atípicos Prevenir. Para los incidentes, tengo preparada una ruta de escalamiento: alarma DLQ → análisis → hotfix o corrección de datos → reprocesamiento controlado. Con esta disciplina, el sistema sigue siendo controlable, incluso cuando crece.
Reflexiones finales: del cronjob a la arquitectura asíncrona escalable
Resuelvo los problemas de rendimiento desacoplando las tareas lentas de la respuesta web y ejecutándolas a través de Trabajador Procesar. Las colas amortiguan la carga, priorizan las tareas y ponen orden en los reintentos y los patrones de error. Con cargas de trabajo separadas, tiempos de espera claros y controladores idempotentes, el sistema sigue siendo predecible. Decido el alojamiento, los límites de los trabajadores y la elección del bróker basándome en métricas reales, no en corazonadas. Quienes apuestan pronto por esta arquitectura obtienen respuestas más rápidas y mejores resultados. Escala y mucha más tranquilidad en el día a día.
