Kafka ソースコードシリーズ: Kafka を例に分散ストレージシステムを説明します

Kafka ソースコード シリーズ。Kafka 0.8.2.2 を例に説明します。目標は、Kafka ソース コード シリーズを読んだ後、誰もが Kafka を完全に理解し、独自のメッセージ キューまたはストレージ システムを設計できるようになることです。

1. 分散システムのCAP理論

1. この理論では、まず分散システムの 3 つの特徴を次のように要約しています。

一貫性 (C): 分散システム内のすべてのデータ コピーが同時に同じ値を持つかどうか。 (すべてのノードが同じデータのコピーにアクセスするのと同等)

可用性 (A): クラスター内の一部のノードに障害が発生した後も、クラスター全体がクライアントの読み取りおよび書き込み要求に応答できるかどうか。 （データ更新の高可用性）

パーティション トレランス (P): フォールト トレランスのために複数のコピーが使用されます。実際には、パーティショニングは通信の時間制限要件に相当します。システムが時間制限内にデータの一貫性を達成できない場合は、パーティションが発生しており、現在の操作に対して C と A のどちらかを選択する必要があることを意味します。

[[218250]]

2. CAP理論の実践における妥協

分散ストレージ システムにおける CAP 理論により、上記の 2 つのポイントのみが達成されます。しかし、実際の環境は、ネットワークのジッタや障害、ハードウェア障害などの問題など、非常に複雑であり、パーティションのフォールト トレランスを実現する必要があります。したがって、一貫性と可用性のバランスを取ることしかできません。

A) CPシステム一貫性優先原則

強力な一貫性の原則を実装する方法は多数あります。最も簡単な方法は、マスター ノードと、冗長バックアップを備えた任意の数のスレーブ ノードを用意することです。データは常にマスターから書き込まれ、読み取られます。ただし、これは単一障害点であり、マスターに障害が発生するとシステムが使用できなくなり、可用性が失われます。しかし、一般的には、スレーブノードがマスターになることを可能にするフォールトトレラントメカニズムがあり、エラー処理が完了した後にシステムを使用できます。

B) APシステムの可用性優先原則

可用性とパーティション耐性を優先して一貫性を犠牲にするシステムは、「最終的な一貫性」を備えていると言われます。特徴は、どのノードからでも書き込みが可能で、ノードが他のノードへのデータの同期を担当することです。読み取り時には、データが存在する 1 つのノードのみにアクセスすれば十分ですが、特定のノードから読み取られたデータは完全ではない可能性があり、つまり、システムの一貫性が失われます。

C) 柔軟な一貫性

3 つの特性間のトレードオフは白か黒かというものではありません。実際、スムーズな移行により、最高のシステム パフォーマンス要件を達成できます。

たとえば、AP システムでは、データに 3 つの冗長コピーがある場合、データを要求するノードの数を調整することで高い一貫性を実現できます。たとえば、3 つのコピーから同時にデータを要求すると、強力な一貫性を実現できますが、フォールト トレランスは失われます。通常、特定の数のノードまたは大多数のノードが使用可能であり、一貫した結果を返すことを要求できます。これは、一貫性とフォールト トレランスのバランスをとるのに適した方法です。

同様に、CP システムでは、一貫性をある程度犠牲にして、接続されたノードからデータの読み取りを実行できます。マスターにのみデータを書き込む場合でも、書き込み操作の一貫性は高いままですが、読み取り操作については最終的な一貫性が保たれます。

特定のユースケースに応じて、CAP のさまざまな機能の強度をユースケースのニーズに最適になるように調整できます。同じアプリケーションおよび同じデータベース内の異なるタイプのデータに対して、これらの戦略を混在させることもできます。

次に、独自の分散ストレージシステムを設計します

分散ストレージ システムの設計は難しくありませんが、システムの堅牢性をどのように確保するかが難しさです。理由については、Langjian がここで言いたいのはただ 1 つ、インターネットは信頼できないということだ。

現在の分散ストレージ システムの典型的な構造は次のとおりです。

メタデータ サーバー、データ ストレージ ノード、クライアント。

データアクセスプロセス:

クライアントはまずメタデータ情報を取得し、次に特定のノードに移動してメタデータ情報に基づいてデータを読み書きします。メタデータは、すべてのノード上のデータの保存状態、コピー状態などを維持します。データ ストレージ ノードはレプリカ データ同期プロセスを完了します。

同時に、分散データストレージシステムには次の 3 つの機能が必要です。

1. 特定のノードにアクセスできない状況をスムーズに処理するためのデータ バックアップ メカニズム。

2. バックアップ一貫性メカニズムを提供する - ユーザーがデータを要求すると、最新の更新データを取得できます (一貫性)。

3. 線形拡張メカニズム----- 20 ノードのスループットは 10 ノードの 2 倍です。

3. Kafka ストレージシステムの分析

Kafka はストレージ システムではなく、メッセージ キューであると主張しないでください。

1. Kafka システム全体の役割:

1）、動物園の飼育員

レコードには、Kafka のブローカー、Kafka のブローカー コントローラーの選択、トピックの公開、構成の更新、パーティションの追加などが含まれており、これらはすべてクライアントによって Zookeeper を介して Crontroller に公開されます。

2）、プロデューサー

Kafkaへのデータ送信を担当

3) 消費者

kafkaからデータを取得する役割を担う

4) ブローカー

データの受信、保管、管理等を担当します。

5) トピックとパーティション

トピックはデータの種類を表します。パーティションは、トピックを細分化し、スループットと処理の同時実行性を確保するための鍵であり、クラスター データのバックアップの単位です。

2. 共通分散ストレージシステムの役割の観点から：

クライアント: プロデューサー、コンシューマー、Zookeeper (トピック、パーティション、ブローカー、およびその他の関連する変更は、Zookeeper を通じてクラスター コントローラーに通知されます。これが無理があると思われる場合は、メタデータ クラスターに起因すると考えることができます)。

ストレージシステム: ブローカークラスタ

メタデータ クラスター: Zookeeper クラスター。実際、各ブローカーはメタデータ（クライアント--> Zookeeper-->

コントローラー --> 通常のブローカー)。

3. Kafka の分散ストレージ機能

1）、データバックアップ、障害回復

2つの部分があります:

A)、ブローカー障害回復。ブローカーは、Zookeeper、一時 zknode、/brokers/ids/[0...N] に登録します。一時ノードは、advertisedHost:advertisedPort を保存し、SessionExpireListener を初期化します。リスナーはブローカー自身の一時ノードをリッスンします (セッション タイムアウト後に再登録します)。 Crontroller はこのディレクトリ内の一時ノードを監視し、ブローカーがダウンしたかどうか、または新しいブローカーがノードに参加したかどうかを確認できます。

Brokers クラスターは、Zookeeper に一時ノード/コントローラーを登録することによって Crontroller を選択し、各 Broker は一時ノードをリッスンし、一時ノードの変更に基づいて Crontroller を選択するかどうかを決定します。 Crontroller がクラッシュし、他のブローカーが Crontroller を再選出するようになります。フォールトトレランスのため。

B) トピックはメッセージの種類を表します。トピックは複数のパーティションに分割され、各パーティションでデータの読み取りおよび書き込み操作が実行されます。パーティションには複数のレプリカがあり、レプリカによってリーダーが選出されます。その後、データの書き込みと読み取りはすべてリーダーを通じて行われるため、強力な一貫性 CP が実現されます。同時に、単一障害点の問題も発生します。障害回復メカニズムは、ISR リストからリーダーを再選出することです。フラワーのリーダーからのデータ同期に遅れが生じると、データ損失が発生します。この場合、フェイルオーバー後にデータが失われないようにするには、次の構成を使用します。

プロパティの詳細な説明:

Request.required.acks: 3 つの値があり、意味は次のとおりです。

0 - ブローカーの応答を待たずにすぐに戻ります。

1-データが正常に送信されたというリーダーの応答を待ちます。

-1 - 書き込みが成功したとみなされる前に、min.insync.replicas 個のレプリカがデータを受信するまで待機します。

このパラメータは min.insync.replicas と組み合わせて使用​​する必要があります。 request.required.acks が -1 に設定されている場合、isr リスト内の min.insync.replicas レプリカのデータが書き込まれた場合にのみ、メッセージが正常に生成されます。

min.insync.replicas の値はレプリカの合計数を超えることはできません。これらが等しい場合、1 つのレプリカが利用できなくなるとクラスターは麻痺します。一般的に、replication.factor = min.insync.replicas + 1 で十分です。

2) データバックアップ一貫性メカニズム

レプリカはリーダーを選出し、残りはフォロワーになります。データの書き込みと読み取りはすべてリーダーを通じて行われるため、データ バックアップの一貫性が確保されます。したがって、データ バックアップの一貫性は CP (強力な一貫性) です。リーダーには障害回復メカニズムがあります。リーダーに障害が発生した場合、isr リストから新しいリーダーが選出されます。

3) 直線膨張機構

このメカニズムも Kafka では 2 つの部分に分かれています。

A) ブローカーの線形展開

新しいブローカーがクラスターに参加すると、Crontroller はその変更を認識します。ただし、既存のパーティションまたはデータは新しいブローカーに再配布されません。新しいトピックが追加されないか、手動移行が実行されない場合、新しいブローカーにはデータが含まれません。クラスターが異種混合でない場合、クラスターのパフォーマンスは直線的に増加するはずです。

B) ディスクの数が適切であれば、トピックのパーティション数を増やすとトピックの同時実行性も向上します。この増加によりトピックのスループットも増加します。

4. クライアントとKafkaクラスタ間の通信メカニズム

この記事では一般的なプロセスについて説明し、後続の記事で詳細を説明します。

A)、コマンド ----> zookeeper ----> ブローカー コントローラー ----> ブローカー

これは、Zookeeper をベースにしたサブスクリプションおよび公開システムを作成することと同等です。トピックの作成、構成の更新などは、この方法ですべてのブローカー コントローラーに伝達され、その後、ブローカー コントローラーによってすべてのブローカーに渡されます。

B)、プロデューサー/サンプルコンシューマー ----> ブローカー パーティション リーダー -----> フォロワー

これについては、<Kafka ソース コード シリーズ: ソース コードによるプロデューサー パフォーマンスのボトルネックの分析> で説明されています。リクエストは 2 つのステップに分かれています。

1) 最初のステップでは、ブローカーがランダムに選択され、リーダーの場所など、トピックに関連するメタデータが取得されます。

2) データの読み取りと書き込みを行うために、すべてのリーダーのブローカーにリンクする接続プールを構築します。

それがプロダクション メッセージである場合、フォロワーはリーダーから遅延メッセージを積極的に取得します。

C)、高消費者--->飼育係---->ブローカーリーダー----->ブローカーフォロワー

このデータ取得方法では、前の手順よりも 1 つ手順が増えます。つまり、ブローカーの IP とポートを Zookeeper から取得するのに対し、前の方法ではブローカーの IP とポートが構成に直接書き込まれます。

前回のものをベースに、Zookeeper に基づいていくつかの最適化が行われ、3 つの重要な Zookeeper リスナーが追加されました。

1)、ZKリバランサーリスナー

リスナーは /consumers/group/ids ディレクトリを監視し、ディレクトリ下で子ノードが追加または削除されたときに再バランスをトリガーします。 4 回試行して失敗すると、例外がスローされます。

新しい ConsumerRebalanceFailedException をスローします (consumerIdString + " は " + config.rebalanceMaxRetries + " 回の再試行後に再バランスできません" )

2)、ZKセッションExpireListener

監視されるのは、各コンシューマー自身の一時ノード (/consumers/group/ids/consumerID) の削除と登録 (アクションなし) です。一時ノードが削除されると、handleNewSession は処理関数でノードを Zookeeper に再登録する必要があります。また、再バランス調整も行われます。

3)、ZKトピックパーティション変更リスナー

このリスナーは、/brokers/topics/topicName ノードのデータの変更、つまりパーティションの変更を監視します。新しいパーティションが追加されると、再バランスがトリガーされます。

IV.結論

この記事は主に、分散ストレージ システムの設計を誰もが理解できるようにすることを目的としています。まず、CAP 理論を紹介し、次に分散ストレージ システムのいくつかの要素について説明し、最後に Kafka を例に、分散メッセージ キューまたは分散ストレージ システムである Kafka の構造について説明します。これが皆様のお役に立てば幸いです。 ***、ポイントを述べるためにペンを手に取ってください。Zookeeper の理論と使用法については後ほど説明します。