Apache Kafka 4.0.0 introduit les Share Groups comme un nouveau modèle de consommation aux côtés des groupes de consommateurs traditionnels. Les Share Groups distribuent des enregistrements individuels, et non des partitions entières, offrant une distribution au niveau de l'enregistrement pour une flexibilité accrue. Cela diffère des groupes de consommateurs traditionnels où les partitions sont assignées à des consommateurs spécifiques, garantissant l'ordre au sein de ces partitions. Les Share Groups sont idéaux pour les événements indépendants à volume élevé où le débit est prioritaire sur la séquence. Ils offrent également des avantages d'évolutivité dynamique pour les charges de travail à demande variable. Les groupes de consommateurs traditionnels restent essentiels lorsque le traitement de l'ordre est critique ou pour le traitement avec état nécessitant une affinité de partition. Dans les Share Groups, un Share Coordinator au niveau du broker gère la distribution des enregistrements. Les enregistrements sont acquis par les consommateurs avec un verrou basé sur le temps et retournés automatiquement au pool s'ils ne sont pas accusés de réception dans le délai imparti. Les consommateurs peuvent accuser réception des enregistrements comme ACCEPT, RELEASE pour réessayer, ou REJECT pour une défaillance permanente. Le broker suit les tentatives de livraison, archivant automatiquement les messages après une limite configurée pour se protéger contre les messages empoisonnés. Spring for Apache Kafka 4.0.0 prend entièrement en charge les Share Groups, offrant à la fois la création de conteneurs programmatique et les configurations @KafkaListener basées sur des annotations. La configuration d'un ShareConsumerFactory et d'un ShareKafkaListenerContainerFactory est nécessaire. Les deux modes d'accusé de réception implicites et explicites sont pris en charge. L'accusé de réception implicite accepte automatiquement en cas de réussite de la méthode et rejette en cas d'exceptions, tandis que l'accusé de réception explicite permet un contrôle précis à l'aide d'un paramètre ShareAcknowledgment. L'accusé de réception explicite, cependant, nécessite que tous les enregistrements soient accusés de réception avant que de nouveaux enregistrements puissent être interrogés. Les Share Groups permettent également une mise à l'échelle avec la concurrence au sein d'un seul conteneur, permettant à plusieurs threads de consommateurs de traiter les enregistrements en parallèle.