フロントエンドサービスがKafkaのリクエストのトピックにメッセージをプッシュし、ダウンストリームのバックエンドコンシューマの別の「応答」トピックをリッスンするシステムを作成しています。最終的にKafkaにプッシュバックして) 'request'メッセージの処理を行い、最終的に 'response'トピックにプッシュします。Kafkaコンシューマとプロデューサパーティションの一致
消費者が適切なパーティションでリッスンして応答を受信し、フロントエンドコンシューマがリッスンしているパーティションにバックエンドがプッシュすることを確認する最も洗練された方法を見つけようとしています。私たちは常に、応答が最初のメッセージを生成したのと同じ消費者に流れるようにする必要があります。
私は今のところ2つの解決策を持っていますが、どちらも特に満足できません。
- 各フロントエンドでどのリスンするかを決定し、メッセージとともにそのパーティションを「要求」トピックに渡すようにしてください。バックエンドの処理が終了すると、メッセージのパーティションメンバーを調べ、適切なパーティションに移動します。ここで直ちに問題になるのは、フロントエンドサービスを調整して各パーティションに均等に分散する方法です(ランダム割り当て?)。
- 各メッセージには相関ID、GUIDがあります。フロントエンドへのリクエストごとに、パーティションの総数に対するGUIDのハッシュに基づいてパーティションのリッスンを開始し、メッセージを「要求」トピックにプッシュします。バックエンドは相関IDを調べ、適切なパーティションを決定します。ここで問題となるのは、フロントエンドは新しい要求を受け取るたびに、新しいパーティションに新しいコンシューマーを設定する必要があります(オーバーヘッドがありますか?)同じパーティション上の複数のアクティブなコンシューマーと、多くのパーティション。
- 消費者とパーティションの数が等しい単一の消費者グループがある場合は、(1)と同様のアプローチを採用しますが、どの消費者がどのパーティションにあるのかをKafkaが処理できるようにします。しかし、リバランスが発生した場合、特にバックエンドで既に飛んでいるメッセージ(潜在的にすべてのパーティションが変更される可能性があるため)の場合、何が起きるかを把握する必要があります。
これは一般的なパターンである必要がありますので、他の人がこれをどのように解決したのか不思議です。
ありがとうございます - フロントエンドごとに1つのトピックが実行可能なソリューションであるようです。私たちはバックエンドのためにKafkaを大いに利用していますが、バックエンドの処理が完了したときにカフカを経由するよりも、フロントエンドと直接通信する方法があると思います。 – David