Diseño de cola de tareas de compresión: procesamiento asíncrono con Celery+Redis

Conclusión primero: la solución estándar para la asíncronización de tareas de compresión es la cola de tareas Celery + Redis, con una arquitectura central de Producer (FastAPI entrega tareas) → Broker (Redis almacena temporalmente) → Worker (Celery consume y llama al motor de compresión Rust) → Backend (Redis almacena resultados). Para la compresión por lotes de 10000 archivos, con fragmentación de 100 archivos por lote y 12 Workers concurrentes, se pueden completar en unos 40 minutos. Los puntos clave de diseño son la fragmentación de tareas, las colas de prioridad, el reintento con retroceso exponencial y la cola de mensajes muertos como respaldo. A continuación se explica la arquitectura de la cola, se proporciona la tabla de parámetros de configuración de Celery y un plan práctico completo.

Si no está muy familiarizado con el despliegue general del servicio de compresión, le recomendamos leer primero la Guía completa de despliegue del servicio de compresión con Docker.

I. ¿Por qué las tareas de compresión necesitan colas asíncronas?

La compresión de archivos es una tarea típicamente intensiva en CPU + IO. La compresión de un PDF de 100 MB puede tardar 5–15 segundos; si se procesa con una interfaz síncrona, la conexión HTTP queda suspendida durante mucho tiempo y la capacidad de concurrencia de una sola máquina es muy pobre. La cola asíncrona desacopla "envío" y "ejecución": el cliente envía la tarea y obtiene inmediatamente un task_id, el Worker comprime lentamente en segundo plano y devuelve el resultado mediante callback o sondeo al completarse.

Método de procesamiento	Capacidad de concurrencia	Latencia de respuesta	Manejo de fallos	Escala aplicable
Procesamiento síncrono	Baja (bloquea conexión HTTP)	5–60 segundos	Sin reintento, error directo	<10 archivos
Pool de hilos	Media (limitada por número de hilos)	1–5 segundos	Implementación manual	10–100 archivos
Cola asíncrona Celery	Alta (escalado horizontal de Workers)	<200 ms	Reintento automático + cola de mensajes muertos	100–100000 archivos
Kubernetes + cola	Muy alta (HPA con escalado elástico)	<100 ms	Sistema completo de tolerancia a fallos	>100000 archivos

La versión de red de SmartSlim adopta la arquitectura FastAPI + Celery + Redis + MinIO, con 12 tareas concurrentes estables en una sola máquina; en el despliegue Kubernetes, HPA puede escalar automáticamente entre 3 y 10 réplicas. Esta arquitectura ya soporta las necesidades de compresión de nivel diario de decenas de miles de archivos para múltiples clientes empresariales.

II. Explicación detallada de la arquitectura de la cola de tareas Celery

La cola de tareas Celery consta de cuatro roles centrales: Producer (productor), Broker (agente de mensajes), Worker (proceso de trabajo) y Backend (almacenamiento de resultados). Comprender las responsabilidades de estas cuatro capas es necesario para configurar correctamente la cola de tareas de compresión.

Componente	Selección tecnológica	Responsabilidad	Configuración clave
Producer	FastAPI	Recibe solicitudes HTTP, construye tareas, las entrega al Broker	task.apply_async(queue=...)
Broker	Redis 7.x	Almacena temporalmente mensajes de tareas pendientes, soporta colas de prioridad	broker_url, visibility_timeout
Worker	Celery 5.x	Consume tareas, llama al motor de compresión Rust para ejecutar la compresión	concurrency, prefork pool
Backend	Redis	Almacena el estado de las tareas y los resultados	result_backend, result_expires
Capa de almacenamiento	MinIO	Almacena archivos originales y comprimidos	Protocolo compatible S3, subida por fragmentos

1. Tabla de parámetros de configuración central de Celery

La configuración de Celery determina directamente la capacidad de throughput y la estabilidad de la cola. La siguiente tabla muestra la configuración recomendada para escenarios de compresión, ya validada en el entorno de producción de SmartSlim.

Parámetro	Valor recomendado	Descripción
broker_url	redis://:password@redis:6379/0	Redis como agente de mensajes, DB independiente para evitar conflictos
result_backend	redis://:password@redis:6379/1	Almacenamiento de resultados en DB independiente, aislado del Broker
task_serializer	json	Serialización JSON, compatible entre lenguajes
result_serializer	json	Los resultados también usan JSON
accept_content	['json']	Solo acepta JSON, endurecimiento de seguridad
timezone	Asia/Shanghai	Zona horaria unificada
task_acks_late	True	ACK solo tras completar la tarea, no se pierden tareas al caer
worker_prefetch_multiplier	1	Cada Worker solo pre-obtiene 1 tarea, evita inanición de tareas largas
task_time_limit	600	Timeout duro de 600 segundos por tarea
task_soft_time_limit	540	Timeout suave de 540 segundos, dispara SoftTimeLimitExceeded
task_reject_on_worker_lost	True	Rechaza la tarea si el Worker termina anormalmente, reencola
result_expires	86400	Los resultados se limpian automáticamente tras 24 horas

2. Diseño de colas de prioridad

Las tareas de compresión tienen diferentes prioridades: las solicitudes de compresión enviadas en tiempo real por los usuarios necesitan una respuesta rápida, mientras que las tareas de archivo programadas pueden ejecutarse lentamente. Se usan colas de prioridad de Redis para implementar programación diferenciada, donde las tareas de alta prioridad son consumidas primero por los Workers.

Nombre de cola	Prioridad	Regla de enrutamiento	Tarea típica
compression_high	9 (máxima)	Solicitudes en tiempo real del usuario	Compresión instantánea de archivo único
compression_normal	5 (por defecto)	Tareas por lotes	Compresión por lotes de 100–500 archivos
compression_low	1 (mínima)	Archivo programado	Compresión de archivo completo nocturno
dlq_queue	— (mensajes muertos)	Tareas que fallaron tras reintentos	Investigación manual o procesamiento de compensación

III. Caso práctico: compresión asíncrona de 10000 archivos

Este es un escenario de archivo de datos empresariales: 10000 documentos históricos (mezcla de PDF/Word/imágenes, tamaño medio de 8 MB por archivo, total de aproximadamente 80 GB) necesitan compresión y archivo unificados. El requisito es completar en 1 hora, con una tasa de compresión no inferior al 60%.

Diseño de la solución: Se dividen 100 archivos por lote en 100 subtareas, se usa Celery group para la entrega masiva, con 12 Workers consumiendo en concurrencia. Cada subtarea llama al motor de compresión Rust para comprimir 100 archivos de forma serial.

Parámetros de ejecución y rendimiento de throughput:

Métrica	Parámetro	Valor medido	Descripción
Total de archivos	10000	—	Formatos mixtos, media 8 MB/archivo
Granularidad de fragmentación	100 archivos/lote	100 subtareas	Equilibra sobrecarga de programación y coste de reintento
Concurrencia de Workers	12	Modo prefork	CPU de 12 núcleos en una sola máquina
Tiempo de compresión por archivo	—	Media 3,2 segundos	Motor Rust nivel medium
Tiempo por lote	—	Aprox. 5,3 minutos	100 archivos en serie
Tiempo total	—	Aprox. 44 minutos	100 lotes / 12 concurrencias
Tasa de compresión	—	67,3%	80 GB → 26,2 GB
Número de fallos	—	17	Archivos dañados, tras reintento entran en cola de mensajes muertos

Resultado: 44 minutos para completar la compresión de 10000 archivos, tasa de compresión del 67,3%, 17 archivos dañados entraron automáticamente en la cola de mensajes muertos para procesamiento manual. La arquitectura general es estable, con un pico de uso de CPU del 89% y un pico de uso de memoria de 4,2 GB, sin OOM ni pérdida de tareas.

3. Estrategia de reintento y cola de mensajes muertos

Las causas de fallo de las tareas de compresión se dividen en dos categorías: errores temporales (timeout de IO, memoria insuficiente, concurrencia excesiva) y errores deterministas (archivo dañado, formato no soportado). Los errores temporales tienen una alta probabilidad de éxito al reintentar, mientras que reintentar errores deterministas no tiene sentido. La siguiente tabla muestra la estrategia de decisión para reintentos y cola de mensajes muertos.

Tipo de error	Excepción típica	Estrategia de manejo	Número de reintentos	Destino final
Temporal-IO	ConnectionError, TimeoutError	Reintento con retroceso exponencial	3 veces	Éxito o cola de mensajes muertos
Temporal-recurso	MemoryError, OOMKilled	Retroceso prolongado + degradación	2 veces	Éxito o cola de mensajes muertos
Determinista-archivo	FileCorrupted, ParseError	Sin reintento, directo a mensajes muertos	0 veces	dlq_queue
Determinista-formato	UnsupportedFormat	Sin reintento, directo a mensajes muertos	0 veces	dlq_queue
Determinista-permiso	PermissionDenied	Sin reintento, alerta	0 veces	dlq_queue + alerta

La configuración de reintento usa autoretry_for y retry_backoff de Celery, con retroceso inicial de 60 segundos, máximo de 600 segundos, y jitter aleatorio para evitar avalanchas. Las tareas en la cola de mensajes muertos son escaneadas periódicamente por una tarea de monitorización independiente, que activa alertas de WeChat Work/DingTalk para notificar al equipo de operaciones.

Métrica de monitorización	Método de captura	Umbral de alerta	Acción
Acumulación en cola	Redis LLEN	>500	Activar escalado de Workers
Tasa de fallo de tareas	Celery events	>5%	Investigar registros + pausar envío
Longitud de cola de mensajes muertos	Redis LLEN dlq	>10	Alerta WeChat Work
Número de Workers activos	Celery inspect	<10	Reiniciar Workers automáticamente
Tiempo medio de tarea	Monitorización Flower	>30 segundos	Revisar archivos grandes + degradar
Uso de CPU	node_exporter	>95%	Limitar + escalar

Para conocer el método completo de llamada a la API de compresión, puede consultar la Guía de llamada a la API de compresión: diseño de interfaz REST.

IV. Recomendaciones de configuración de cola para diferentes escenarios

Diferentes escenarios empresariales tienen requisitos distintos de throughput, latencia y fiabilidad, por lo que la configuración de la cola debe ser diferenciada. La siguiente tabla muestra las configuraciones recomendadas para escenarios comunes.

Escenario	Número de Workers	Granularidad de fragmentación	Cola de prioridad	Estrategia de reintento
Compresión instantánea personal	2	Sin fragmentación	high	Reintento rápido 3 veces
Archivo por lotes empresarial	12	100 archivos/lote	normal/low	Retroceso exponencial 3 veces
Procesamiento gubernamental clasificado	4	50 archivos/lote	high	Reintento estricto + auditoría
Imágenes de plataforma de e-commerce	16	200 archivos/lote	normal	Reintento rápido 2 veces
Archivo programado nocturno	8	500 archivos/lote	low	Retroceso lento 5 veces
Transcodificación de vídeo en tiempo real	24	Archivo único	high	Sin reintento, alerta en fallo

Un principio general: los escenarios en tiempo real usan colas de alta prioridad + fragmentación pequeña + reintento rápido; los escenarios por lotes usan colas normales + fragmentación grande + retroceso exponencial; los escenarios clasificados usan auditoría estricta + fragmentación pequeña + reintento multinivel. Para el plan completo de compresión por lotes empresarial, puede consultar Plan de compresión por lotes empresarial: procesamiento de decenas de miles de archivos en la práctica.

V. Preguntas frecuentes (FAQ)

P1: ¿Cómo implementar el procesamiento asíncrono de tareas de compresión con Celery?

Construya una cola de tareas asíncrona con Celery + Redis: FastAPI recibe la solicitud y entrega la tarea al Broker de Redis, el Celery Worker consume la tarea del Broker y llama al motor de compresión Rust para ejecutar la compresión, y el resultado se escribe en el Backend y el almacenamiento MinIO. Con un task.apply_async se ejecuta de forma asíncrona, y se consulta el estado mediante task.id. Con 12 Workers concurrentes en una sola máquina, 10000 archivos divididos en 100 lotes se pueden completar en 40 minutos.

P2: ¿Cómo reintentar automáticamente las tareas de compresión fallidas?

Use el parámetro autoretry_for de Celery para configurar el reintento automático, estableciendo max_retries=3, retry_backoff=True (retroceso exponencial, inicial 60 segundos), retry_backoff_max=600 segundos, retry_jitter=True (jitter aleatorio para evitar avalanchas). Las tareas que fallan tras 3 reintentos se enrutan automáticamente a la cola de mensajes muertos dlq_queue, para ser procesadas manualmente o por tareas de compensación. Se recomienda reintentar errores temporales (timeout de IO/memoria insuficiente) y enviar directamente a la cola de mensajes muertos los errores deterministas (archivo dañado/formato no soportado).

P3: ¿Cómo fragmentar la compresión por lotes de 10000 archivos?

Se fragmenta en 100 archivos por lote, con un total de 100 subtareas. Se usa Celery group o chord para la entrega masiva, 12 Workers consumen en paralelo, y cada subtarea comprime 100 archivos de forma serial. El tiempo medio de compresión por archivo es de 3 segundos, cada lote tarda unos 5 minutos, y tras la paralelización de 100 lotes el total se completa en unos 40 minutos. Una granularidad de fragmentación demasiado pequeña (por ejemplo, 1 por lote) genera mucha sobrecarga de programación; demasiado grande (por ejemplo, 1000 por lote) aumenta el coste de reintento en caso de fallo; 100 es el valor óptimo empírico.

P4: ¿Cuál es más adecuado para la cola de tareas de compresión, Celery o RQ?

Para tareas de compresión se recomienda Celery. Celery soporta fragmentación de tareas (group/chord), colas de prioridad, tareas programadas, cadenas de tareas y cola de mensajes muertos, con funcionalidad completa; RQ es más ligero pero carece de fragmentación y prioridad. Los escenarios de compresión suelen requerir fragmentación por lotes, programación por prioridad y reintento de fallos, que Celery soporta de forma nativa. En rendimiento, ambos se basan en Redis con un throughput similar. La versión de red de SmartSlim adopta la arquitectura FastAPI + Celery + Redis + MinIO, con 12 concurrencias estables en una sola máquina.

Resumen

La solución estándar para la asíncronización de tareas de compresión es la cola de tareas Celery + Redis, cuyo núcleo es el desacoplamiento de las cuatro capas Producer/Broker/Worker/Backend. Para la compresión por lotes de decenas de miles de archivos, con fragmentación de 100 archivos, 12 Workers concurrentes, se puede completar en unos 40 minutos, con una tasa de compresión del 60%–70%. La estrategia de reintento debe distinguir entre errores temporales (reintento con retroceso exponencial) y errores deterministas (directo a cola de mensajes muertos), combinada con 6 métricas de monitorización para garantizar la estabilidad de la cola.

Recuerde tres puntos: primero, task_acks_late=True asegura que no se pierdan tareas al caer; segundo, worker_prefetch_multiplier=1 evita la inanición de tareas largas; tercero, la cola de mensajes muertos debe tener monitorización y alertas configuradas. Elegir la arquitectura de cola y la estrategia de fragmentación adecuadas permite mejorar significativamente el throughput y la estabilidad del servicio de compresión.