Apache Kafka 4.0.0 は、従来のコンシューマーグループに加えて、新しい消費モデルとして Share Groups を導入しました。Share Groups は、パーティション全体ではなく個々のレコードを分散させ、柔軟性を高めるレコードレベルの分散を提供します。これは、パーティションが特定のコンシューマーに割り当てられ、それらのパーティション内での順序が保証される従来のコンシューマーグループとは異なります。Share Groups は、スループットがシーケンスよりも優先される、大量の独立したイベントに最適です。また、需要が変動するワークロードに対して、動的なスケーリングの利点も提供します。従来のコンシューマーグループは、順序処理が重要である場合や、パーティションアフィニティを必要とするステートフル処理には引き続き不可欠です。 Share Groups では、ブローカーレベルの Share Coordinator がレコードの分散を管理します。レコードは、時間ベースのロックを使用してコンシューマーによって取得され、タイムアウト内に確認応答がない場合は自動的にプールに戻されます。コンシューマーは、レコードを ACCEPT（承認）、RELEAS（再試行）、または REJECT（永続的な失敗）として確認応答できます。ブローカーは配信試行を追跡し、ポイズンメッセージから保護するために、設定された制限を超えるとメッセージを自動的にアーカイブします。 Spring for Apache Kafka 4.0.0 は Share Groups を完全にサポートしており、プログラムによるコンテナ作成とアノテーション駆動の @KafkaListener の両方の設定を提供します。ShareConsumerFactory と ShareKafkaListenerContainerFactory の設定が必要です。暗黙的な確認応答モードと明示的な確認応答モードの両方がサポートされています。暗黙的な確認応答は、メソッドが正常に完了すると自動的に承認し、例外が発生すると拒否します。一方、明示的な確認応答は、ShareAcknowledgment パラメータを使用してきめ細かい制御を可能にします。ただし、明示的な確認応答では、新しいレコードをポーリングする前に、すべてのレコードを確認応答する必要があります。Share Groups は、単一のコンテナ内での並行処理によるスケーリングも可能にし、複数のコンシューマー スレッドがレコードを並行して処理できます。