1 points par hueypark 3 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp
  • Airbridge met en correspondance en temps réel des événements comme les clics publicitaires, les installations et les achats ; il est donc important non seulement de traiter les événements rapidement, mais aussi de les traiter dans l’ordre requis et d’éviter les pertes et les doublons.
  • Auparavant, les messages Kafka étaient récupérés en micro-batchs puis traités séquentiellement selon le type d’événement.
    • Il était facile de contrôler l’ordre, mais pendant l’attente du traitement des événements précédents, les autres workers restaient inactifs.
    • Lorsque les écarts de vitesse de traitement entre workers se combinaient à des hot partitions, le débit plafonnait même en augmentant le nombre de serveurs.
  • Pour résoudre ce problème, ils ont conçu Project Differential.
    • Les micro-batchs ont été supprimés, et des Consumer par type d’événement lisent indépendamment le même topic Kafka.
    • La garantie d’ordre n’est plus assurée à l’échelle de tout le topic, mais au niveau de chaque partition ; les événements d’un même parcours utilisateur, lorsque l’ordre est important, sont configurés pour entrer autant que possible dans la même partition.
    • Un Consumer en aval ne peut pas dépasser la position de traitement du Consumer qui le précède, et une distance de sécurité est maintenue sur la base des offsets ou de l’heure des événements.
    • Les messages non traités par le Consumer précédent sont transmis au suivant pour être réutilisés, et lorsque le buffer est plein, le système bascule en Polling Mode en lisant directement Kafka.
  • En interne, le système utilise des ConsumerSuite / PartitionedConsumerChain par partition, et LimitedEventProcessor contrôle qu’il ne dépasse pas le checkpoint du Consumer précédent.
    • CommitManager veille, même avec du buffering et des traitements asynchrones, à ne commit dans Kafka que les offsets continus réellement terminés.
  • Des tests en conditions réelles ont confirmé un fonctionnement sans perte ni doublon d’événements, avec une vitesse de traitement améliorée de plus de 10 fois par rapport à l’ancienne approche en micro-batchs.
  • Il s’agit d’un cas où, au lieu de créer un ordre global parfait, l’équipe préserve en best effort l’ordre réellement nécessaire au métier tout en assurant le débit.
  • À l’avenir, ils envisagent de simplifier la structure, d’introduire un adaptive flow control pour gérer l’arrêt des Spot Instances, ainsi que d’améliorer l’architecture afin de réduire le besoin même de traitement séquentiel.

Aucun commentaire pour le moment.

Aucun commentaire pour le moment.