Pause de la consommation de flux

Question

Je travaille sur une application qui traite très peu d'enregistrements en une minute. Le taux de demande serait d'environ 2 appels par minute. Ces demandes sont créées et mises à jour pour un ensemble de données. Les exigences étaient la garantie de livraison, la livraison fiable, la garantie de commande et empêchant toute perte de messages.

1. Notre équipe a décidé d'utiliser Kafka et je pense qu'il ne correspond pas au cas d'utilisation puisque Kafka est le mieux adapté pour la diffusion des données. Au lieu de cela, nous aurions pu être mieux avec le modèle de message traditionnel aussi bien. Bien que Kafka fournisse des commandes par partition, la même chose peut être réalisée sur un système de messagerie traditionnel si le nombre de messages est faible et que les sources de données sont également faibles. Serait-ce une déclaration juste?

2. Nous utilisons des flux Kafka pour traiter les données et le traitement nécessite que nous effectuions des recherches sur des systèmes externes. Si les systèmes externes ne sont pas disponibles, nous arrêtons le traitement et transmettons automatiquement les messages aux systèmes cibles lorsque les systèmes de recherche externes sont disponibles. Actuellement, nous arrêtons le traitement en bouclant continuellement au milieu d'un traitement et en vérifiant si les systèmes sont disponibles. a) Est-ce la meilleure façon d'arrêter le flux à mi-chemin pendant le traitement afin qu'il ne capte plus de messages? b) Les cadres de flux de données sont-ils conçus pour être arrêtés ou mis en pause à mi-chemin afin qu'ils arrêtent complètement de consommer le flux pendant un certain temps?

Answer 1

En ce qui concerne votre point 2:

a) Est-ce la meilleure façon d'arrêter à mi-chemin de flux durant le traitement afin qu'il ne capte pas plus de messages? Si, comme dans votre cas, vous avez un très faible débit de données entrantes (quelques enregistrements par minute), alors vous pouvez suspendre le traitement d'un flux d'entrée lorsque les systèmes de dépendance requis ne sont pas disponibles actuellement.

Dans Kafka Streams, l'API préférée pour implémenter un tel comportement - qui, comme vous le faites vous-même, n'est pas vraiment un modèle recommandé - est l'API de processeur.

Même si il y a quelques questions importantes dont vous avez besoin pour vous répondre, comme:

• Quel est le choix/comportement requis de votre application de traitement de flux si les systèmes externes sont en baisse pendant des périodes prolongées temps?
• Le débit de données entrant pourrait-il augmenter à un moment donné, ce qui pourrait signifier que vous auriez besoin d'abandonner l'approche de pause ci-dessus?

Mais encore une fois, si la pause est ce que vous voulez ou devez faire, alors vous pouvez essayer.B) Les cadres de flux de données sont-ils conçus pour être arrêtés ou mis en pause à mi-chemin afin qu'ils cessent complètement de consommer le flux pendant un certain temps?

Certains outils de traitement de flux vous permettent de le faire. Que ce soit le meilleur modèle pour les utiliser est une question différente. Par exemple, vous pouvez également envisager l'alternative suivante: Vous pouvez également intégrer automatiquement les données des systèmes externes dans Kafka, par exemple via le framework Kafka Connect de Kafka. Ensuite, dans Kafka Streams, vous pouvez lire ces données exportées dans un KTable (pensez à ce KTable comme un cache continuellement mis à jour des dernières données de votre système externe), puis effectuez une jointure de table de flux entre votre original, bas débit flux d'entrée et ce KTable. Ces jointures de table de flux sont un modèle commun (et recommandé) à enrich an incoming data stream with side data (avertissement: j'ai écrit cet article); par exemple, pour enrichir un flux d'événements de clic d'utilisateur avec les dernières informations de profil utilisateur. L'un des avantages de cette approche - comparée à votre configuration actuelle d'interrogation de systèmes externes associée à un comportement de pause - est que votre application de traitement de flux serait découplée de la disponibilité (et de l'évolutivité) de vos systèmes externes.

Answer 2

1. est seulement une déclaration juste pour les courtiers de message traditionnels quand il y a un seul consommateur (à savoir une file d'attente exclusive). Dès que la file d'attente est partagée par plus d'un consommateur, il y a une possibilité de livraison de messages hors service. En effet, il est possible qu'un consommateur ne parvienne pas à traiter et à ACK un message résultant du retour du message en tête de la file d'attente partagée, puis remis (hors service) à un autre consommateur. Kafka garantit la consommation parallèle de plusieurs consommateurs utilisant des partitions de sujet (qui ne sont pas présentes dans les courtiers de messages traditionnels).