記事ディレクトリ
Kafka クラスターの目標
- 高い同時実行性
- 高可用性
- 動的なスケーリング
Kafka クラスターのサイズを見積もる方法
スループット：
クラスタリングにより、リクエストの処理能力が向上します。単一のブローカーのパフォーマンス不足は、ブローカーを拡張することで解決できます。
ディスクスペース：
クラスターに保持するデータが 10 TB あり、各ブローカーが 2 TB を保存できる場合、少なくとも 5 つのブローカーが必要です。データ レプリケーションが有効な場合は 2 倍のスペースが必要となるため、このクラスターには 10 個のブローカーが必要です。
Kafka クラスター構築の実践
2 つの Linux サーバー (1 つは 192.68.10.7、もう 1 つは 192.168.10.8) を使用します。
192.68.10.7の構成情報変更
192.168.10.8の設定情報変更
Kafka クラスターの原理
メンバーシップと管理者
コントローラーは実際にはブローカーですが、一般的なブローカーの機能に加えて、パーティション リーダーの選出も担当します。
コントローラーは、ブローカーがクラスターに参加したことを検出すると、ブローカー ID を使用して、新しく参加したブローカーに既存のパーティションのコピーが含まれているかどうかを確認します。存在する場合、コントローラーは新しく追加されたブローカーと他のブローカーに変更通知を送信し、新しいブローカー上のレプリカはリーダーからのメッセージの複製を開始します。
要するに。Kafka は、Zookeeper の一時ノードを使用してコントローラーを選出し、ノードがクラスターに参加またはクラスターから離脱するときにコントローラーに通知します。コントローラーは、ノードがクラスターに参加またはクラスターから離脱する際のパーティション リーダーの選択を担当します。
以下の 2 つの起動ログから、サーバー 192.168.10.7 がコントローラーであることは明らかです。
クラスターの動作メカニズム
レプリケーション機能は、Kafka のアーキテクチャの中心です。Kafka のドキュメントでは、Kafka は自身を「分散型、分割可能、複製可能なコミット ログ サービス」と説明しています。
レプリケーションは、個々のノードに障害が発生した場合でも Kafka の可用性と耐久性を保証するため、非常に重要です。
Kafka はトピックを使用してデータを整理し、各トピックは複数のパーティションに分割され、各パーティションには複数のコピーがあります。これらのレプリカはブローカーに保存され、各ブローカーはさまざまなトピックやパーティションに属する数百または数千のレプリカを保存できます。
レプリケーション係数パラメータ
erdan トピックを作成します。レプリケーション係数は 2、パーティション数は 2 です。
./kafka-topics.sh --bootstrap-server 192.168.10.7:9092 --create --topic erdan --replication-factor 2 --partitions 2
replication-factor は、トピックのレプリカの数を設定するために使用されます。各トピックは複数のレプリカを持つことができ、レプリカはクラスター内の異なるブローカーに配置されます。つまり、レプリカの数がブローカーの数を超えることはできません。
Partition0 では、broker1 (broker.id =0) がリーダーであり、broker2 (broker.id =1) がフォロワー レプリカです。
Partition1 では、broker2 (broker.id =1) がリーダーで、broker1 (broker.id =0) がフォロワー レプリカです。
各パーティションにはリーダーのコピーがあります。一貫性を確保するために、すべてのプロデューサーとコンシューマーのリクエストはこのコピーを通過します。
リーダー以外のコピーはフォロワーのコピーです。フォロワー レプリカはクライアントからのリクエストを処理しません。その唯一のタスクは、リーダーからのメッセージをコピーし、リーダーとの一貫した状態を維持することです。リーダーがクラッシュした場合、フォロワーの 1 人が新しいリーダーに昇格します。
auto.leader.rebalance.enable パラメータ
定期的なリーダー選挙を許可するかどうか。
その値を true に設定すると、Kafka が一部のトピック パーティションに対して定期的にリーダーの再選出を実行できることを意味します。もちろん、この再選出はむやみに実行されるわけではありません。再選出が行われる前に、特定の条件を満たす必要があります。
たとえば、リーダー A は非常に優れたパフォーマンスを示していますが、auto.leader.rebalance.enable=true の場合、リーダー A は強制的に辞任され、一定期間後にリーダー B に置き換えられる可能性があります。
リーダーの変更には非常にコストがかかることに注意してください。最初に A にリクエストを送信していたすべてのクライアントは、B へのリクエストの送信に切り替える必要があります。さらに、リーダーを変更しても基本的にパフォーマンス上の利点はありません。したがって、本番環境でこのパラメータを設定することをお勧めします。環境。 false。
クラスターメッセージの生成
信頼できるプロデューサー
確認応答メカニズムを送信するための 3 つの異なる確認応答モード。
acks=0 は、プロデューサーがネットワーク経由でメッセージを送信できる場合、メッセージは Kafka に正常に書き込まれたとみなされることを意味します。
acks=1 は、リーダーがメッセージを受信し、それをパーティション データ ファイル (ディスクに同期している必要はない) に書き込む場合、確認応答またはエラー応答を返すことを意味します。
acks=all は、リーダーが確認応答またはエラー応答を返す前に、同期されたすべてのレプリカがメッセージを受信するまで待機 (min.insync.replicas) することを意味します。
ISR（同期レプリカ）
Kafka のデータ レプリケーションはパーティションに基づいています。複数のバックアップ間のデータ レプリケーションは、フォロワーがリーダーからデータを取得することによって完了します。この観点から見ると、これはマスター/スレーブのソリューションに似ています。違いは、Kafka が完全な同期レプリケーションでも完全な非同期レプリケーションでもなく、ISR に基づく動的レプリケーション ソリューションであることです。
ISR。同期レプリカとも呼ばれます。各パーティションのリーダーは、そのパーティションと同期されたすべてのレプリカ (リーダー自体を含む) を含むリストを維持します。データが書き込まれるたびに、ISR 内のすべてのレプリカがコピーされた場合にのみ、リーダーはそれをコミットに設定し、コンシューマーがそれを使用できるようにします。
このソリューションは同期レプリケーションに非常に近いものです。ただし、違いは、この ISR がリーダーによって動的に維持されることです。フォロワーがリーダーに「追いつく」ことができない場合、リーダーによって ISR から削除され、再びリーダーに「追いつく」と、リーダーによって再び ISR に追加されます。ISR が変更されるたびに、リーダーは最新の ISR を Zookeeper に永続化します。
フォロワーがリーダーに「追いついている」かどうかを判断する方法に関しては、Kafka のバージョンごとに戦略が若干異なります。
バージョン 0.9.0.0 以降、replica.lag.max.messages が削除されたため、リーダーはフォロワーの背後にあるメッセージの数を考慮しなくなります。さらに、リーダーは、フォロワーが、replica.lag.time.max.ms 時間内にフェッチ リクエストを送信したかどうかを判断するだけでなく、その時間内にフォロワーがリーダーと同期しているかどうかも考慮します。
ISRスキームを使用する理由
リーダーは時間内に同期できないフォロワーを削除できるため、同期レプリケーションと比較して、最も遅いフォロワーによる全体の速度の低下を回避できます。つまり、ISR によりシステムの可用性が向上します。
ISR 内のすべてのフォロワーにはコミットされたすべてのメッセージが含まれており、コミットされたメッセージのみがコンシューマーによって消費されます。したがって、コンシューマーの観点から見ると、ISR 内のすべてのレプリカは常に同期状態にあり、非同期レプリケーション スキームと互換性がありません。 ～と比較した一貫性
ISR関連の設定手順
ブローカーの min.insync.replicas パラメーターは、ブローカーが必要とする ISR の最小長を指定します。デフォルト値は 1 です。つまり、極端な場合、ISR にはリーダーのみを含めることができます。ただし、この時点でリーダーがダウンした場合、パーティションは使用できなくなり、可用性は保証されません。min.insync.replicas は、kafka システムの可用性とデータの信頼性の間のバランスを保っています。
ISR 内のすべてのレプリカによって同期されたメッセージのみがコミットされますが、プロデューサーがデータをパブリッシュする場合、リーダーはデータの受信を確認する前に ISR 内のすべてのレプリカがデータを同期する必要はありません。プロデューサは、acks パラメータを使用して、メッセージが正常に送信されたとみなされる前にメッセージの受信を確認するために必要なレプリカの最小数を指定できます。acks のデフォルト値は 1、つまり、リーダーはメッセージを受信した後、すぐにプロデューサーにメッセージを受信するように指示しますが、このとき、ISR 内のメッセージがコピーされる前にリーダーがクラッシュすると、メッセージは失われます。この値が 0 に設定されている場合、プロデューサーはデータを送信した後、待機せずにデータが正常に送信されたとすぐに認識します。実際には、データの送信に失敗する可能性があり、プロデューサーの再試行メカニズムが有効になりません。 。
より推奨されるアプローチは、acks を all または -1 に設定することです。このとき、ISR 内のすべてのレプリカがデータを受信した場合 (つまり、メッセージがコミットされた場合) にのみ、リーダーはメッセージが正常に送信されたことをプロデューサーに伝えます。したがって、未知のデータ損失が発生しないことが保証されます。