Kafka はどのようにして高可用性を確保するのでしょうか?写真は言葉よりも雄弁である

[[391488]]

高可用性とは何ですか?

「高可用性」とは、システムが中断することなく機能を実行する能力を指し、システムの可用性の度合いを表します。

Kafka はバージョン 0.8 以降、高可用性メカニズムを提供しており、1 つ以上のブローカーがダウンした後でも他のブローカーが引き続きサービスを提供できることを保証できます。

バックアップメカニズム

Kafka では、同じパーティション内に複数のメッセージのコピーが存在することができます。各パーティション コピーは通常、1 つのリーダーと 0 個以上のフォロワーで構成されます。プロデューサーは対応するパーティションのリーダーにメッセージを直接送信し、フォロワーはリーダーに定期的に同期要求を送信します。

同じパーティションのレプリカを同じブローカーに保存しないでください。ブローカーがダウンすると、対応するパーティションのすべてのレプリカが機能しなくなり、高可用性が実現されなくなります。

したがって、Kafka はすべてのパーティションとそのレプリカをクラスター全体のブローカーに均等に分散しようとします。

「次の写真を例に挙げます：」

ISRメカニズム

「ISRレプリカセット」

ISR 内のレプリカはすべてリーダーと同期されます。逆に、ISR にないフォロワー レプリカは、リーダーと同期していないと見なされます。

ここで同期を維持するということは、データをリーダーと完全に一致させるという意味ではなく、replica.lag.time.max.ms 時間内にリーダーとの有効な接続を維持することを意味します。

フォロワーは定期的にリーダーに FetchRequest リクエストを送信します。送信間隔は replica.fetch.wait.max.ms で設定されます。デフォルト値は 500 です。

パブリッククラスFetchRequest{
    プライベート最終ショートバージョンID;
    プライベート最終int相関ID;
    プライベート最終文字列クライアントID;
    プライベート最終intレプリカId;
    プライベート最終int maxWait; // フォロワーが許容する最大待機時間: リーダーはポイントに到達するとすぐに結果を返します。デフォルト値は 500 です。
    プライベート最終int minBytes; // フォロワーが許容する最小の戻りデータ サイズ: リーダーに十分なデータがある場合、リーダーはすぐに戻り、maxWait が戻るまで待機します。デフォルト値は1です
    プライベート最終マップ<TopicAndPartition、PartitionFetchInfo> requestInfo; // フォロワー内の各パーティションと獲得数に対応するLEO
 }

各パーティションのリーダーは、ISR リストを維持し、ISR の変更を ZooKeeper に同期する責任を負います。 ISR から削除されたフォロワーは、リーダーに追いついて ISR に再び入ろうと、FetchRequest リクエストをリーダーに送信し続けます。

ISR 内のすべてのレプリカがリーダーに追いつきました。通常、リーダーとして選出されるのは ISR のメンバーのみです。

「不潔なリーダー選挙」

Kafka の unclean.leader.election.enable が true (デフォルト値は false) に設定され、ISR 内のすべてのレプリカがダウンしている場合、ISR 外部のレプリカがリーダーとして選出されることが許可され、確認済みデータの一部が失われます。

アンクリーン リーダー選出を有効にすると、データが失われる可能性がありますが、パーティション リーダー レプリカが常に存在し、外部サービスの提供が停止されないため、高可用性が向上するという利点があります。逆に、アンクリーン リーダー選出を無効にすると、データの一貫性が維持され、メッセージの損失を回避できるという利点がありますが、高可用性が犠牲になります。

ACKメカニズム

プロデューサーによって送信されたメッセージには、リーダーがプロデューサーに応答する前にリーダーが受信した確認応答の数を表す acks フィールドが含まれます。

• 「ACK = 0」

プロデューサーはサーバーからの確認を待つ必要はありません。メッセージはプロデューサー ソケット バッファーに追加された後に送信されたとみなされるため、acks=0 はサーバーがメッセージを受信したことを保証するものではありません。

• 「acks=1」

パーティション リーダーがメッセージを受信して​​ローカル ディスクに書き込む限り、他のフォロワーがメッセージを同期したかどうかに関係なく、成功したと見なされます。

• 「acks=すべて」

リーダーは、応答する前に ISR 内のすべてのレプリカからの確認を待機します。したがって、ISR 内のレプリカがまだ生きている限り、応答されたメッセージは失われません。

acks=all は最も利用可能なオプションですが、フォロワーの応答を待つと、追加の応答時間が発生します。リーダーは、ISR 内のすべてのレプリカが応答するのを待つ必要があります。応答時間は、ISR 内の最も遅いマシンによって異なります。

パーティション リーダーがメッセージを受信したが、フォロワーがまだ受信しておらず、リーダーがダウンしている場合、クライアントはメッセージが正常に送信されなかったことを感知し、再度メッセージの送信を試行します。

ブローカーには、プロデューサー データを正常に書き込むために必要な ISR の最小数を表す構成項目 min.insync.replicas (デフォルト値は 1) があります。

ISR 内のレプリカの数が min.insync.replicas より少ない場合、リーダーはプロデューサーによって生成されたメッセージの書き込みを停止し、プロデューサーに NotEnoughReplicas 例外をスローして、より多くのフォロワーが追いついて ISR に再び入るのをブロックして待機します。

リーダーによって確認されたメッセージには少なくとも min.insync.replicas 個のコピーがあるため、同時に min.insync.replicas-1 個のコピーがダウンしても許容できます。

"結論は："

acks=1 および 0 で送信されたメッセージは失われる可能性があります。メッセージの損失を避けるには、プロデューサーをacks=all & min.insync.replicas >= 2に設定してください。

障害回復メカニズム

「Kafka はバージョン 0.8 以降、リーダー選出と障害回復のメカニズムを導入しました。」

まず、各パーティションのリーダー選出とレプリカの再配布を担当するコントローラーをクラスター内のすべてのブローカーから選択する必要があります。

• リーダーに障害が発生すると、コントローラーはリーダー/フォロワーの変更に対応する必要があるブローカーに通知します。

Kafka は、ブローカーやトピックなどの状態データを保存するために ZooKeeper を使用します。 Kafka クラスターのコントローラーとブローカーは、ZooKeeper の指定されたノードにウォッチャー (イベント リスナー) を登録します。これにより、特定のイベントがトリガーされると、ZooKeeper は対応するブローカーにイベントを通知します。

ブローカ

「ブローカーに障害が発生した場合、コントローラーは影響を受けるパーティションの新しいリーダーを選出し、関連するブローカーに通知する責任があります。」

• ブローカーに障害が発生し、ZooKeeper から切断されると、ZooKeeper 内のブローカーに対応する znode が自動的に削除され、ZooKeeper はノード上のコントローラーによって登録されたウォッチャーをトリガーします。
• コントローラーは、ZooKeeper の /brokers/ids ノードからダウンしたブローカー上のすべてのパーティションを取得します。
• 次に、コントローラは ZooKeeper の /brokers/topics からすべてのパーティションの現在の ISR を取得します。
• 障害が発生したブローカーがリーダーであるパー​​ティションの場合、コントローラは ISR から生き残っているブローカーを新しいリーダーとして選択します。
• 最後に、コントローラーは LeaderAndIsrRequest リクエストを通じてブローカーに LeaderAndISRRequest リクエストを送信します。
  

コントローラ

クラスター内のコントローラーにも障害が発生する可能性があるため、Kafka ではすべてのブローカーが ZooKeeper コントローラー ノードにウォッチャーを登録する必要があります。

コントローラーに障害が発生すると、対応する一時的なコントローラー ノードが自動的に削除されます。この時点で、そこに登録されているウォッチャーがトリガーされ、すべての生存ブローカーが新しいコントローラーになるために競争します（つまり、新しいコントローラーノードを作成し、ZooKeeper は 1 つだけが正常に作成されるようにします）。

選挙の勝者は新しい会計監査人となる