Aperçu du problème

Un serveur DRF a envoyé une requête POST webhook au serveur d'application Django et,
Django a rencontré les problèmes suivants lors de la création d'une instance du modèle Post.

  1. Délai d'attente de la réponse du webhook
  2. Après la création de l'objet Post, le traitement des champs ManyToMany comme categories et tags prend du temps

  3. En conséquence, la réponse du webhook est retardée et DRF l'identifie comme un échec

  4. Intégrité des données non garantie

  5. Si une tâche Celery est appelée immédiatement après le traitement, les opérations tags.add(...) et categories.add(...) n'ont pas encore été complétées

  6. Ce qui entraîne un problème où Celery traite des données incomplètes

  7. Réception de données vides par Celery même après on_commit()

  8. Bien que l'intégrité des données ait été garantie avec on_commit() et que la tâche Celery ait été planifiée, les résultats des requêtes comme tags.all() apparaissent toujours comme une liste vide
  9. Cela est dû au fait que Celery envoyait des opérations de lecture à la base de données en réplique, et qu'il y avait un retard dans la synchronisation des données de la base de données principale vers la réplique

Stratégie de résolution

  1. Retourner la réponse immédiatement après la création du Post

  2. Créer uniquement l'instance Post et retourner immédiatement une réponse 202 Accepted à DRF afin d'éviter le problème de délai d'attente

  3. Traiter les travaux suivants dans un fil séparé

  4. Utiliser threading.Thread() pour séparer le traitement des relations et l'appel de Celery du flux principal

  5. Concevoir pour que la réponse du webhook ne ralentisse pas

  6. Assurer la transaction à l'intérieur de post_process

  7. Regrouper l'ensemble du traitement des champs ManyToMany dans une transaction avec transaction.atomic()
  8. Planifier la tâche Celery après l'achèvement des travaux avec transaction.on_commit()

  9. Ce qui garantit que Celery s'exécute après le traitement des relations

  10. Désigner directement la base de données principale dans Celery pour les requêtes

  11. Pour éviter les problèmes d'intégrité dus au retard de la réplique, utiliser explicitement using('default') dans la tâche Celery
post = Post.objects.using('default').get(id=post_id)
tags = post.tags.using('default').all()
categories = post.categories.using('default').all()

Ou il est possible d'utiliser un routeur de base de données pour s'assurer que les requêtes Celery interrogent toujours la base de données principale

Résumé de la structure finale

  1. Serveur DRF → Requête webhook Django
  2. Django:
    • Réponse retournée immédiatement après création de l'objet Post
    • Travaux suivants exécutés dans un fil séparé
  3. À l'intérieur du thread:
    • Organisation des relations avec atomic()
    • Planification de la tâche Celery avec on_commit()
  4. Celery:
    • Interroger les données de la base de données principale (default)

Conclusion

Tous les composants fonctionnent individuellement, mais pour résoudre les problèmes de latence et d'intégrité des données survenant dans un environnement d'architecture distribuée,
une conception système prenant en compte non seulement la structure du code mais aussi le flux de données, le timing et le retard de la base de données en réplique s'est avérée nécessaire.