カフカプロセス/ブローカーを実行しているマシンで、3つの異なるトピックに属する3つのパーティションがあるシナリオを想像してみてください。このブローカは、3つのパーティションすべてのメッセージを受信します。それらを別のログサブディレクトリに格納します。私の質問は、カフカブローカーがこれらの書き込みをどのように予定しているかです。どのパーティション/トピックが次に書き込まれるかはどのように決定されますか？kafkaプロセスのスケジュールはどのようにして別のパーティションに書き込まれますか？
要求を超える注文については、下の画像は、ブローカが内部要求を生成処理する方法、概ね示し： 
ネットワーク層のバイトを引いて内部リクエストにこれらを変換するネットワーク・スレッドの数があります。これらの要求はFIFOリクエストキューにスタックされ、そこでIOスレッドはそれらを取り出して、含まれているメッセージを関連するパーティションに追加します。したがって、短いメッセージは受信された順に処理されます。
ここで競合状態の可能性があるかどうかはわかりませんが、小規模な要求は大きな要求を「追い越す」可能性があります。直前に送信されます。しかし、これが可能であったとしても、私は一人のプロデューサーにとってこれまでに見られることはありえない、非常に起こりそうな縁辺のケースです。おそらくコードの理解を深める人がここに詰め込むことができますか？
一度のリクエストでバッチメッセージを並べ替えると、要求はTopicPartitionをキーとして使用するHashMapに内部的にメッセージを格納します。スカラHashMapが挿入された要素の順序を保持しないので、 1つのリクエスト内の複数のパーティションが処理される順序の周りに何らかの保証があるとは思わないでください。順序はパーティション内でのみ保証されるので問題ありません。
各パーティション内で、メッセージは送信前にプロデューサに与えられた順序で処理されます。