Donnez aux workers d'arrière-plan un budget borné

Définissez une unité de travail utile

Pour un export CSV interne, une requête crée un enregistrement d'export ; un worker lit un jeu de données borné, écrit un objet de sortie et marque l'enregistrement comme terminé. Définissez la portée utile maximale, la limite de temps et le comportement d'annulation. Utilisez une file d'attente isolée, une base de données de test et une destination qui ne peut pas notifier de vrais clients.

Séparez le temps de calcul de l'attente de base de données et de stockage. Un seul chiffre de durée de tâche masque ces distinctions. Construire le fichier entier en mémoire ne s'adapte pas de la même manière que diffuser des lots bornés. Gardez le message de file d'attente assez petit pour décrire le travail sans intégrer de données clients ni d'identifiant.

Rendez la livraison répétée sûre par conception

Utilisez un identifiant d'export durable pour relier les tentatives à un seul résultat logique. Imposez l'unicité et une transition atomique de propriété/achèvement dans un état durable. Vérifier si un export existe puis insérer dans une étape séparée non protégée permet à des tentatives concurrentes de faire la course. Publier un objet et acquitter le message de file d'attente forment aussi une frontière de défaillance.

# 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 associe l'acquittement tardif aux tâches idempotentes et documente des cas où l'acquittement se produit encore après la fin du processus enfant. Une option de file d'attente ne crée pas une exécution exactement-une-fois. Examinez la sémantique de redélivrance de votre système et concevez le résultat applicatif pour tolérer les réessais.

Référence technique : Comportement des tâches Celery.

Fixez le budget avant d'augmenter les processus

Pour un worker hypothétique utilisant 300 MiB par export actif, quatre exports simultanés impliquent déjà environ 1,200 MiB avant la surcharge d'exécution. Ce sont des entrées de planification, pas des benchmarks. Ajoutez les connexions à la base de données, la mémoire de requête, le disque temporaire et la bande passante de sortie ; un nombre de processus n'est qu'une limite.

Répétez avec un export actif et un arriéré réaliste. Passez à deux tout en répétant le même trafic API. Comparez les exports utiles terminés, l'âge de la tâche la plus ancienne, la latence, les échecs et la pression de l'hôte. Si le débit ne s'améliore guère alors que les attentes de base de données augmentent, arrêtez d'augmenter la concurrence. Un CPU supplémentaire peut ne pas supprimer ce goulot d'étranglement.

Empêchez l'échec de créer plus de charge

Classez les erreurs avant de réessayer. Une panne de stockage temporaire peut être transitoire ; un compte non autorisé ou un format d'export non pris en charge nécessite une erreur terminale ou une intervention. Utilisez un budget de tentatives fini et des réessais différés avec backoff et jitter lorsque pris en charge. Gardez les tâches échouées inspectables avec les champs sensibles supprimés.

Appliquez des délais d'attente aux appels externes et un budget global pour la tâche. Abandonner une tentative ne prouve pas que son effet secondaire distant n'a pas eu lieu. Une publication expirée peut déjà avoir écrit la sortie. Réconciliez par ID d'export au lieu de publier aveuglément un autre résultat.

Incluez les workers dans le déploiement et la reprise

Arrêtez les nouveaux travaux sur l'ancien worker en suivant son comportement d'arrêt documenté. Laissez les travaux en cours se terminer ou interrompez-les en sécurité sous une échéance connue. Testez un crash après l'écriture de la sortie mais avant l'enregistrement de l'achèvement ; la tentative de remplacement devrait trouver un résultat cohérent plutôt que de le dupliquer.

Gardez les formats de messages compatibles entre les versions qui se chevauchent. Une nouvelle API peut mettre en file d'attente une charge utile qu'un ancien worker ne peut pas lire. Versionnez le contrat ou séquencez le déploiement pour que les consommateurs pris en charge existent avant l'apparition des nouveaux messages. Incluez ces écritures de base de données dans la revue de compatibilité du schéma.

Choisissez la prochaine contrainte à modifier

Laissez un paramètre de concurrence, une politique de nouvelle tentative, un contrat de tâche et une règle d'arrêt mesurée. Si des exports coûteux retardent de petites tâches, envisagez des files d'attente séparées avec des budgets indépendants avant d'augmenter la limite globale. Si la latence de l'API souffre à toute charge d'export réaliste, séparer les workers peut être plus utile qu'agrandir un hôte partagé.

Répétez la même charge de travail après un changement et conservez la comparaison. Le scénario API et workers explique où App 2 et la mémoire supplémentaire entrent dans le choix. Ces procédures n'impliquent pas de file d'attente gérée, de tâches illimitées ni de mise à l'échelle automatique.