Dé a los workers en segundo plano un presupuesto acotado

Defina una unidad de trabajo útil

Para una exportación CSV interna, una solicitud crea un registro de exportación; un worker lee un conjunto de datos acotado, escribe un objeto de salida y marca el registro como completado. Defina el alcance máximo útil, el límite de tiempo y el comportamiento de cancelación. Use una cola aislada, una base de datos de prueba y un destino que no pueda notificar a clientes reales.

Separe el tiempo de cómputo de la espera de base de datos y almacenamiento. Un solo número de duración del trabajo oculta estas distinciones. Construir todo el archivo en memoria escala de forma diferente a transmitir lotes acotados. Mantenga el mensaje de cola lo suficientemente pequeño para describir el trabajo sin incrustar datos de clientes ni una credencial.

Haga que la entrega repetida sea segura por diseño

Use un identificador de exportación duradero para relacionar los intentos con un único resultado lógico. Imponga la unicidad y una transición atómica de propiedad/completado en estado duradero. Comprobar si existe una exportación e insertarla después en un paso separado sin protección permite que intentos concurrentes compitan. Publicar un objeto y confirmar el mensaje de cola también forman un límite de fallo.

# Illustrative contract, not queue implementation
job_type: export-account-report
logical_result: EXPORT_RECORD_ID
input_scope: AUTHORIZED_ACCOUNT_AND_DATE_RANGE
attempt_limit: REVIEWED_FINITE_LIMIT
completion: ONE_PUBLISHED_RESULT_FOR_THIS_EXPORT
retry: CLASSIFIED_TRANSIENT_FAILURES_ONLY
failed_result: INSPECTABLE_WITHOUT_CUSTOMER_SECRETS

Celery relaciona la confirmación tardía con tareas idempotentes y documenta casos en los que la confirmación aún ocurre tras la terminación del proceso hijo. Una opción de cola no crea ejecución exactamente una vez. Revise la semántica de reentrega de su sistema y diseñe el resultado de la aplicación para tolerar reintentos.

Referencia técnica: Comportamiento de tareas de Celery.

Establezca el presupuesto antes de aumentar los procesos

Para un worker hipotético que usa 300 MiB por exportación activa, cuatro exportaciones simultáneas ya implican aproximadamente 1,200 MiB antes de la sobrecarga en tiempo de ejecución. Estos son datos de planificación, no benchmarks. Añada conexiones de base de datos, memoria de consulta, disco temporal y ancho de banda de salida; el número de procesos es solo un límite.

Ensayé con una exportación activa y un backlog realista. Aumente a dos mientras repite el mismo tráfico de API. Compare exportaciones útiles completadas, antigüedad del trabajo más antiguo, latencia, fallos y presión del host. Si el rendimiento apenas mejora mientras crecen las esperas de base de datos, deje de aumentar la concurrencia. CPU adicional puede no eliminar ese cuello de botella.

Evite que el fallo genere más carga

Clasifique los errores antes de reintentar. Una interrupción temporal del almacenamiento puede ser transitoria; una cuenta no autorizada o un formato de exportación no compatible necesita un error terminal o intervención. Use un presupuesto de intentos finito y reintentos retrasados con retroceso y jitter donde sea compatible. Mantenga los trabajos fallidos inspeccionables con los campos sensibles eliminados.

Aplica tiempos de espera a las llamadas externas y un presupuesto total para la tarea. Abandonar un intento no demuestra que su efecto remoto no haya ocurrido. Una publicación que agotó el tiempo puede haber escrito ya la salida. Reconcilia por ID de exportación en lugar de publicar otro resultado a ciegas.

Incluya los workers en el despliegue y la recuperación

Detén el trabajo nuevo en el worker antiguo usando su comportamiento de apagado documentado. Deja que el trabajo en curso termine o interrúmpelo de forma segura bajo un plazo conocido. Prueba un fallo después de escribir la salida pero antes de registrar la finalización; el intento de reemplazo debería encontrar un resultado consistente en lugar de duplicarlo.

Mantén los formatos de mensaje compatibles entre versiones superpuestas. Una API nueva puede encolar un payload que un worker antiguo no puede leer. Versiona el contrato o secuencia el despliegue para que existan consumidores compatibles antes de que aparezcan mensajes nuevos. Incluye a estos escritores de base de datos en la revisión de compatibilidad del esquema.

Elija la siguiente restricción a cambiar

Deja una configuración de concurrencia, una política de reintentos, un contrato de tarea y una regla de parada medida. Si las exportaciones costosas retrasan los trabajos pequeños, considera colas separadas con presupuestos independientes antes de aumentar el límite global. Si la latencia de la API sufre con cualquier carga realista de exportación, separar los workers puede ser más útil que ampliar un único host compartido.

Repite la misma carga de trabajo después de un cambio y conserva la comparación. El escenario de API y workers explica dónde entran App 2 y la memoria adicional en la elección. Estos procedimientos no implican una cola gestionada, trabajos ilimitados ni escalado automático.