Pourquoi est Kafka basé sur pull au lieu de Push-based?
Pourquoi est Kafka pull-based au lieu de Push-based? Je suis d'accord Kafka donne un débit élevé comme je l'ai vécu, mais je ne vois pas comment = Kafka diminuerait s'il était basé sur la transmission. Avez-vous des idées sur la façon dont la technologie Push peut dégrader les performances?
L'évolutivité a été le principal facteur déterminant lorsque nous concevons de tels systèmes (pull vs push). Kafka est très évolutif. L'un des principaux avantages de Kafka est qu'il est très facile d'ajouter un grand nombre de consommateurs sans affecter les performances et sans temps d'arrêt).
Kafka peut gérer des événements à un taux de 100k + par seconde provenant des producteurs. Parce que Kafka tirent des données du sujet, différents consommateurs peuvent consommer les messages à un rythme différent. Kafka prend également en charge différents modèles de consommation) Vous pouvez avoir un consommateur traitant les messages en temps réel et un autre consommateur traitant les messages en mode batch.
L'autre raison pourrait être que Kafka a été conçu non seulement pour des consommateurs uniques comme Hadoop. Différents consommateurs peuvent avoir des besoins et des capacités divers.
Les systèmes basés sur l'extraction présentent certaines lacunes telles que le gaspillage de ressources en raison des sondages réguliers. Kafka prend en charge un mode d'attente de "longue interrogation" jusqu'à ce que des données réelles parviennent pour pallier cet inconvénient.
Reportez-vous à la documentation Kafka qui détaille la décision de conception particulière: Push vs pull
Les principaux points favorables au pull sont:
- Pull est plus efficace pour traiter avec des consommateurs diversifiés (sans qu'un courtier ne détermine le taux de transfert de données pour tous);
- Les consommateurs peuvent contrôler plus efficacement le taux de leur consommation individuelle;
- Implémentation du traitement par lots plus simple et plus optimale.
L'inconvénient des systèmes basés sur l'extraction (les consommateurs interrogent les données alors qu'il n'y a pas de données disponibles pour eux) est quelque peu atténué par un mode d'attente de "longue interrogation" jusqu'à l'arrivée des données.
D'autres ont fourni des réponses basées sur la documentation de Kafka mais parfois la documentation du produit doit être prise avec un grain de sel comme référence technique absolue. Par exemple:
- De nombreux systèmes de messagerie basés sur Push prennent en charge la consommation à différents taux, généralement via leurs primitives de gestion de session. Vous établissez/reprenez une session de couche application active lorsque vous souhaitez consommer et suspendre la session (par exemple en ne répondant tout simplement pas moins que la fenêtre keepalive et plus que les fenêtres en vol ... ou avec un message explicite) quand vous le souhaitez pour arrêter/mettre en pause. MQTT et AMQP, par exemple, offrent tous deux cette capacité (dans le cas de MQTT, depuis la fin des années 90). Étant donné qu'aucune action n'est requise pour suspendre la consommation (par définition) et que moins de trafic est requis dans un état stable (aucune demande), il est difficile de voir comment le modèle basé sur le pull de Kafka est plus efficace.
- Un avantage essentiel de la messagerie Push par rapport à la messagerie Pull est qu'il n'y a pas de trafic de demande à l'échelle à mesure que le nombre de sujets potentiellement actifs augmente. Si vous avez un million de sujets potentiellement actifs, vous devez émettre des requêtes pour tous ces sujets. Cette préoccupation devient particulièrement pertinente à l'échelle.
- L'avantage critique de la messagerie pull par rapport à la messagerie push est la rejouabilité . Cela dépend beaucoup de la capacité des systèmes en aval à offrir des garanties de traitement (par exemple, ils peuvent échouer avant de le faire et doivent redémarrer ou, par exemple, ne pas écrire les messages de manière récupérable).
- Un autre avantage essentiel pour la messagerie Pull par rapport à la messagerie Push est l'allocation de tampon . Un processus consommateur peut demander explicitement autant de données qu'il peut en contenir dans un tampon pré-alloué, plutôt que d'avoir à allouer des tampons encore et encore. Cela permet de récupérer une partie des pertes de débit par rapport à la messagerie Push grâce à la mise à l'échelle des requêtes (mais pas beaucoup). L'impact ici est mesurable, cependant, si la taille de vos messages varie énormément (par exemple quelques Ko -> quelques centaines de Mo).
- Il est faux de suggérer que la messagerie Pull présente des avantages d'évolutivité structurelle par rapport à la messagerie Push. Le partitionnement est ce qui est généralement utilisé pour fournir une échelle dans les applications de messagerie, quel que soit le modèle de consommation. Il existe des systèmes de messagerie Push fonctionnant bien au-delà de 300M msgs/sec sur des clusters locaux câblés ... 125K msgs/sec n'achètent même pas l'admission au salon. En fait, la messagerie pull a un rendement inférieur par définition et des systèmes comme Kafka se retrouvent généralement avec plus matériel pour atteindre le même niveau de performance. Les avantages mentionnés ci-dessus peuvent souvent en valoir la peine. Je ne connais personne utilisant Kafka pour la messagerie dans le trading haute fréquence, par exemple, où les microsecondes comptent.
Il peut être intéressant de noter que divers systèmes de messagerie push-pull ont été développés à la fin des années 1990 afin d'optimiser le débit. Les résultats n'ont jamais été stupéfiants et la complexité du système et d'autres facteurs l'emportent souvent sur ce type d'optimisation. Je crois que c'est le point de vue de Jay dans l'ensemble sur les performances pratiques sur de vrais réseaux de centres de données, sans parler de choses comme l'Internet ouvert.