キーに強い順序が必要で、ステート マシンのようなものを開発している場合、キーはたいてい便利/必要です。同じキー (一意の ID など) を持つメッセージが常に正しい順序で表示されるようにする必要がある場合は、キーをメッセージに添付すると、同じキーを持つメッセージが常にトピック内の同じパーティションに送信されるようになります。Kafka はパーティション内の順序を保証しますが、トピック内のパーティション間では保証しません。そのため、代わりにキーを提供しないと (結果としてパーティション間でラウンドロビン分散が行われます)、そのような順序は維持されません。
ステート マシンの場合、log.cleaner.enableでキーを使用して、同じキーでエントリを重複排除できます。その場合、Kafka は、アプリケーションが特定のキーの最新のインスタンスのみを考慮し、ログ クリーナーが特定のキーの古い重複をキーが null でない場合にのみ削除すると想定します。この形式のログ圧縮はlog.cleaner.delete.retentionプロパティによって制御され、キーが必要です。
または、デフォルトで有効になっているより一般的なプロパティlog.retention.hoursは、古くなったログの完全なセグメントを削除することによって機能します。この場合、キーを提供する必要はありません。Kafka は、指定された保持期間よりも古いログのチャンクを単純に削除します。
つまり、ログの圧縮を有効にしている場合、または同じキーを持つメッセージに厳密な順序が必要な場合は、間違いなくキーを使用する必要があります。それ以外の場合は、null キーを使用すると、分散が向上し、一部のキーが他のキーよりも多く表示される可能性がある場合に、潜在的なホット スポットの問題を防ぐことができます。