パーティション番号は、トピックの平行を決定します。たとえば、あるトピックに対して10のパーティションと、コンシューマ・グループに20のコンシューマしかない場合、10人のコンシューマはアイドル状態であり、メッセージを受信しません。その数は実際にあなたのアプリケーションに依存しますが、1-1000はすべて合理的です。
レプリカ数は耐久性の要件によって決まります。レプリケーションファクタNのトピックの場合、Kafkaは、ログにコミットされたメッセージを失うことなく、N-1までのサーバ障害を許容することができます。 3つのレプリカは共通の構成です。もちろん、レプリカ番号はあなたのブローカー番号よりも小さいか等しい必要があります。
auto.create.topics.enableプロパティは、Kafkaがサーバー上でトピックの自動作成を有効にするときに制御します。これがtrueに設定されている場合、アプリケーションが存在しないトピックのメタデータを生成、使用、またはフェッチしようとすると、Kafkaはデフォルトの複製係数とパーティション数でトピックを自動的に作成します。本番ではオフにしてトピックを作成することをお勧めします。
出典
2016-04-06 05:30:20
Lan
短くてきれいな情報をありがとう – Ratha
ノードの数と等しい数の複製を要求しても、クラスタは非常に壊れやすくなりませんか? 1つのノードが停止し、正しい数のレプリカを待たなければならないため、クラスタは突然応答しなくなります。 –
@SethPaulsonノードがダウンするため、待機しません。このシナリオでは、リーダーは「同期している」レプリカのリストからそのリーダーを削除し、戻ったらそれを回復しようとします。詳細な説明については、[Kafka Documentation on Replication](https://kafka.apache.org/documentation/#replication)を参照してください。 –