ジャワ——「インタビューの質問——動物園の飼育員」

分散ネーミングサービスとして、ネーミングサービスとは、指定された名前を通じてリソースまたはサービスのアドレスを取得することを指します。ZooKeeper を使用して、名前として使用できるグローバルパスを作成し、サービスによって提供されるサービスのアドレスを指します。クラスター内のクラスター、またはリモートオブジェクトなど。

統一ネーミングサービスのネーミング構造図は以下のとおりです。

1. 分散環境では、さまざまなサービスの識別を容易にするために、アプリケーション/サービスに統一した名前を付けることが必要になることがよくあります。

ドメイン名と IP の対応と同様に、IP は覚えにくいですが、ドメイン名は覚えやすいです。
リソースまたはサービスのアドレス、プロバイダー、およびその他の情報を名前で取得します。

2. サービス/アプリケーション名を階層構造で整理します。

サービス名とアドレス情報を ZooKeeper に書き込むことができ、クライアントは ZooKeeper を通じて利用可能なサービスのリストを取得できます。

構成管理

プログラムは別のマシンに分散してデプロイされ、プログラムの構成情報は ZooKeeper の znode 配下に配置され、構成が変更されたとき、つまり znode が変更されたときに、zk のディレクトリノードの内容を次のように変更できます。 use ウォッチは各クライアントに設定を変更するように通知します。

ZooKeeper の構成管理構造図は次のとおりです。

1. 分散環境では、構成ファイルの管理と同期が一般的な問題になります。

Hadoop クラスターなどのクラスターでは、すべてのノードの構成情報が一貫しています。
構成ファイルが変更された後は、各ノードと迅速に同期できることが期待されます。

2. 構成管理は ZooKeeper によって実装できます。

構成情報は、ZooKeeper 上の Znode に書き込むことができます。
各ノードはこの Znode をリッスンします。
Znode 内のデータが変更されると、ZooKeeper は各ノードに通知します。

クラスタ管理

いわゆるクラスター管理とは、マシンの終了と参加の有無、およびマスターの選択です。

クラスタ管理とは主にクラスタ監視とクラスタ制御を指します。前者はクラスタの実行状態の収集に重点を置き、後者はクラスタの運用と制御に重点を置きます。開発および運用保守では、クラスターに直面して、次のような要件が発生することがよくあります。

1. クラスター内で動作しているマシンの数を知りたい

2. クラスター内の各マシンの実行時状態に関するデータを収集します。

3. クラスター内のマシン上でオンラインおよびオフライン操作を実行します。

クラスタ管理構造図は次のとおりです。

1. 分散環境では、各ノードの状態をリアルタイムで知る必要があり、ノードのリアルタイムの状態に応じていくつかの調整を行うことができます。

2. ZooKeeper で実装できます。

ZooKeeper 上の Znode にノード情報を書き込むことができます。
この Znode をリッスンして、リアルタイムのステータス変化を取得します。

3. 代表的な用途

Hbase でのマスターステータスの監視と選択。

ZooKeeper の強力な一貫性を使用すると、分散型の高い同時実行性の場合にノード作成のグローバルな一意性を保証できます。つまり、/currentMaster ノードを同時に作成する複数のクライアントリクエストがある場合、正常に作成できるクライアントリクエストは 1 つだけです。終わり

分散型通知と調整

1. 分散環境では、サービスが管理するサブサービスのステータスを知る必要があることがよくあります。

a) NameNode は各データノードのステータスを知る必要があります。

b) JobTracker は各 TaskTracker のステータスを知る必要があります。

2. ハートビート検出メカニズムは ZooKeeper を通じて実現できます。

3. 情報のプッシュは、パブリッシュ/サブスクライブシステムに相当する ZooKeeper によって実現できます。

分散ロック

異なるノード上の異なるサービスは、いくつかのリソースに順次アクセスする必要がある場合があり、ここでは分散ロックが必要です。

分散ロックには、書き込みロック、読み取りロック、タイミングロックという特性があります。

書き込みロック: zk 上に作成された一時的な番号のないノード。これは順序のない番号であるため、作成時に自動的に番号が付けられることはなく、ロックを取得して書き込みできるのは 1 つのクライアントだけです。

読み取りロック: zk 上に一時的に番号付きノードを作成します。これにより、次回クライアントが参加するときに同じノードが同時に作成された場合でも、自動的に番号が付けられ、ロックオブジェクトを取得して読み取ることができます。

タイミングロック: zk 上に作成された一時的な番号付きノードは、番号のサイズに応じてロックを制御します。

分散キュー

分散キューには 2 つのタイプがあります。

1. キューのメンバーがすべて集まると、キューは使用可能になりますが、それ以外の場合は、すべてのメンバーが到着するのを待ちます。これは同期キューです。

a) ジョブは複数のタスクで構成されており、すべてのタスクが完了した後でのみジョブが完了するまで実行されます。

b) ジョブ用に /job ディレクトリを作成し、このディレクトリの下に完了したタスクごとに一時 Znode を作成します。一時ノードの数がタスクの合計数に達すると、ジョブが完了したことを示します。

2. キューは、プロデューサーモデルとコンシューマーモデルの実装など、FIFO 方式に従ってエンキューおよびデキュー操作を実行します。

3. Zookeeper の動作原理について教えてください。

Zookeeper の中核はアトミックブロードキャストであり、サーバー間の同期を保証します。このメカニズムを実装するプロトコルは、Zab プロトコルと呼ばれます。

Zab プロトコルには、リカバリモード (マスター選出) とブロードキャストモード (同期) の 2 つのモードがあります。

Zab プロトコルの正式名は、Zookeeper Atomic Broadcast** (Zookeeper Atomic Broadcast) です。Zookeeper は、Zab プロトコルを使用して、分散トランザクションの最終的な一貫性を確保します。Zab プロトコルでは、各リーダーが検出、同期、ブロードキャストという 3 つの段階を通過する必要があります。

サービスが開始されるか、リーダーがクラッシュした後、Zab はリカバリモードに入ります。リーダーが選出され、ほとんどのサーバーがリーダーとの状態の同期を完了すると、リカバリモードは終了します。状態の同期により、リーダーとサーバーのシステム状態が確実に同じになります。

トランザクションの逐次一貫性を確保するために、Zookeeper は増分トランザクション ID 番号 (zxid) を使用してトランザクションを識別します。すべての提案には、提案時に zxid が追加されます。実装では、zxid は 64 ビットの数値であり、その上位 32 ビットは、リーダー関係が変化したかどうかを識別するためにエポックによって使用されます。リーダーが選出されるたびに、現在の統治期間を識別する新しいエポックが作成されます。あのリーダーの。下位 32 ビットはカウントアップに使用されます。

紀元：天皇の年号と解釈でき、新しい皇帝指導者が誕生すると、新しい紀元年名が生まれます。

各サーバーには、作業プロセス中に 3 つの状態があります。

探しています: 現在のサーバーはリーダーが誰であるかを知らず、探しています。
LEADING: 現在のサーバーが選出されたリーダーです。
以下: リーダーが選出され、現在のサーバーはリーダーと同期されています。

4. Zookeeper の通知メカニズムについて説明してください。

Zookeeper を使用すると、クライアントはサーバー上の znode にウォッチャーを登録できます。サーバー上の指定されたイベントによってウォッチャーがトリガーされると、サーバーは指定されたクライアントにイベント通知を送信して分散通知機能を実装し、クライアントはこれに従うことになります。ビジネスに変更を加えるための Watcher Notify 状態とイベントタイプ。

大きく分けて以下の3つのステップに分かれます。

クライアントがウォッチャーを登録する

1. getData、getChildren、exist の 3 つの API を呼び出し、Watcher オブジェクトを渡します。2. リクエストをマークし、Watcher を WatchRegistration にカプセル化します。3. それを Packet オブジェクトにカプセル化して、サーバーにリクエストを送信します。4. サーバーからの応答を受信した後、ウォッチャーを ZKWatcherManager に登録して管理します。5. 返送して登録を完了するよう要求します。

サーバー処理ウォッチャー

1. サーバーは Watcher を受信して保存します。2. ウォッチャーをトリガーします。 3. process メソッドを呼び出してウォッチャーをトリガーします。

クライアントコールバックウォッチャー

1. クライアントの SendThread スレッドがイベント通知を受信し、EventThread スレッドが Watcher をコールバックします。2. クライアントのウォッチャーメカニズムも 1 回限りであり、一度トリガーされるとウォッチャーは無効になります。

クライアントは特定の znode のウォッチャーイベントを作成し、znode が変更されると、これらのクライアントは zk 通知を受け取り、クライアントは znode の変更に応じてビジネスを変更できます。

5. Zookeeper のノードへの監視通知は永続的ですか?

いいえ、一回限りです。サーバーであってもクライアントであっても、Watcher がトリガーされると、Zookeeper は対応するストレージから Watcher を削除します。この設計により、サーバーへの負荷が効果的に軽減されます。そうでないと、非常に頻繁に更新されるノードの場合、サーバーはイベント通知をクライアントに継続的に送信することになり、ネットワークとサーバーの両方に多大な負荷がかかります。

6. Zookeeper クラスター内の役割は何ですか?

クラスターでは少なくとも 3 つが必要です。または、奇数である 2N + 1 ユニットを保証します。なぜ奇数が保証されるのですか? 主に選挙アルゴリズム用。

7. Zookeeper クラスター内のサーバーの動作ステータスは何ですか?

探しています

リーダー状態を探します。サーバーがこの状態にある場合、サーバーは現在のクラスターにリーダーが存在しないと判断するため、リーダー選出状態に入る必要があります。

続く

フォロワーのステータス。現在のサーバーの役割がフォロワーであることを示します。

主導的

リーダーのステータス。現在のサーバーの役割がリーダーであることを示します。

観察する

オブザーバーのステータス。現在のサーバーの役割がオブザーバーであることを示します。

8. Zookeeper クラスター内のリーダーはどのように選出されますか?

リーダーがクラッシュするか、ほとんどのフォロワーを失うと、Zookeeper はリカバリモードに入ります。リカバリモードでは、すべてのサーバーが LOOKING の状態に戻るように、新しいリーダーを再選出する必要があります。

Zookeeper には、基本 paxos に基づくものと高速 paxos に基づく 2 つの選出アルゴリズムがあります。デフォルトは fast paxos です。スペースの問題のため、次のことをお勧めします: [配布] 動物園飼育員のリーダー選挙

9. Zookeeper はトランザクションの逐次一貫性をどのように保証しますか?

Zookeeper は増分トランザクション ID を使用して識別し、すべての提案 (プロポーザル) は提案されるときに zxid とともに追加されます。zxid は実際には 64 ビットの数値です。

上位 32 ビットは、リーダーが変更されたかどうかを識別するためにエポックによって使用され、新しいリーダーが生成されると、エポックはインクリメントされます。下位 32 ビットはカウントアップに使用されます。新しいプロポーザルが生成されると、まずデータベースの 2 段階のプロセスに従って他のサーバーにトランザクションの実行要求が送信され、半数以上のマシンが実行して成功すると、実行が開始されます。

10. ZooKeeper クラスター内でサーバーはどのように通信しますか?

リーダーサーバーは、各フォロワー/オブザーバーサーバーとの TCP 接続を確立し、各フォロワー/オブザーバーに対して LearnerHandler と呼ばれるエンティティを作成します。

LearnerHandler は主に、データの同期、リクエストの転送、提案の投票など、リーダーとフォロワー/オブザーバー間のネットワーク通信を担当します。
リーダーサーバーは、すべてのフォロワー/オブザーバーの LearnerHandler を保存します。

11. ZooKeeper 分散ロックはどのように実装されていますか?

Zookeeper 分散ロックをめぐって競合する N 個のクライアント (クライアント 1 とクライアント 2 など) が存在する場合。おおよそ次のとおりです。

1. 全員が立ち上がり、ロックノードの下に一時的に順序付けされたノードを次々と直接作成します

2. 最初のノードではない場合は、前のノードにリスナーを追加します

3. 前のノードがロックを解放している限り、そのノードは先頭にキューイングされます。これはキューイングメカニズムと同等です。

また、一時シーケンシャルノードを使用するもう 1 つの目的は、一時シーケンシャルノードを作成した後にクライアントが誤ってクラッシュしても問題ないことです。Zookeeper は、クライアントがダウンしていることを感知すると、対応する一時シーケンシャルノードを自動的に削除します。ロックを自動的に解放するか、独自のキューを自動的にキャンセルします。

ローカルロックは JDK を使用して実装できますが、分散ロックは分散コンポーネントを使用する必要があります。ZooKeeper、Redis など。オンラインコードのセクションは大きく、インタビューは通常書かれていません。いくつかの重要なポイントについてお話します。

注意点としては以下のようなものが挙げられます。

デッドロック問題：事故によりロックがデッドロックになるはずがないため、ZKの一時ノードを使用し、クライアント接続に失敗した場合は自動的にロックを解除します。
ロック待機の問題: ロックにはキューイング要件があるため、ZK の順次ノードが必要です。
ロック管理の問題: ユーザーがロックを解除すると、他のユーザーに通知する必要があるため、監視が必要です。
モニタリングの群集効果: たとえば、ロックの競合者が 1,000 人いてロックが解除された場合、1,000 人の競合者に通知され、審査され、シリアル番号が最も小さい競合者が最終的にロックを取得します。他の 999 人の競技者は、聞くために再登録します。これが群れ効果で、何かが起こると群れ全体が警戒します。各競技者は自分の前のノードのみを監視する必要があります。たとえば、2 番がロックを解除すると、3 番にのみ通知されます。

12. Zookeeper のシステムアーキテクチャを理解していますか?

ZooKeeper アーキテクチャ図を理解して習得する必要がある主な事項は次のとおりです。

(1) ZooKeeper はサーバー (Server) とクライアント (Client) に分かれており、クライアントは ZooKeeper サービス全体のどのサーバーにも接続できます (leaderServes パラメーターが明示的に設定されていない限り、リーダーはクライアント接続を受け入れることができません)。

(2) クライアントは、リクエストの送信、応答の受信、監視イベントの取得、およびハートビートの送信に使用する TCP 接続を使用および維持します。この TCP 接続が切断されると、クライアントは自動的に別の ZooKeeper サーバーへの接続を試みます。クライアントが ZooKeeper サービスに初めて接続すると、接続を受け入れる ZooKeeper サーバーがクライアントのセッションを確立します。クライアントが別のサーバーに接続すると、セッションは新しいサーバーによって再確立されます。

(3) 上の図の各サーバーは、Zookeeper サービスがインストールされているマシン、つまり Zookeeper サービスを提供するクラスター全体 (または擬似クラスター) を表します。

(4) ZooKeeper サービスを構成するサーバーは相互に認識している必要があります。ZooKeeper サービスは、メモリ内の状態イメージ、永続ストレージ内のトランザクションログとスナップショットを維持し、大部分のサーバーが利用可能な限り ZooKeeper サービスを利用できます。

(5) ZooKeeper が開始されると、インスタンスからリーダーが選出され、リーダーはデータ更新やその他の操作の処理を担当します。ほとんどのサーバーがメモリ内のデータを正常に変更した場合にのみ、更新操作が成功したとマークされます。各サーバーはデータのコピーをメモリに保存します。

(6) Zookeeper はクラスター内で複製でき、Zab プロトコル (Zookeeper Atomic Broadcast) を通じてクラスター間でデータの一貫性が維持されます。

(7) Zab プロトコルは、リーダー選出フェーズとアトミックブロードキャストフェーズの 2 つのフェーズで構成されます。

a) クラスター内でリーダーが選出され、他のマシンはフォロワーと呼ばれ、すべての書き込み操作はリーダーに送信され、すべての更新はブロードキャストを通じてフォロワーに伝えられます。
b) リーダーがクラッシュするか、リーダーがフォロワーの大部分を失った場合、すべてのサーバーを正しい状態に復元するために新しいリーダーを再選出する必要があります。
c) リーダーが選出され、ほとんどのサーバーがリーダーとの状態同期を完了すると、リーダー選出プロセスは終了し、アトミックブロードキャストプロセスに入ります。
d) アトミックブロードキャストは、リーダーとフォロワーの間で情報を同期し、リーダーとフォロワーのシステムステータスが同じになるようにします。

13. Zookeeper はなぜこのように設計されているのですか?

ZooKeeper 設計の目的は、高性能、高可用性、逐次一貫性のある分散調整サービスを提供し、データの最終的な一貫性を確保することです。

高性能 (シンプルなデータモデル)

1. データノードをツリー構造に編成します。

2. すべてのデータノードはメモリに保存されます。

3. フォロワーとオブザーバーは非トランザクション要求を直接処理します。

高可用性 (クラスターの構築)

1. マシンの半数以上が生き残れば、サービスは正常に実行できます。

2. リーダーの自動選出

逐次整合性（トランザクション操作の順序）

1. 各トランザクションリクエストは、処理のためにリーダーに転送されます。

2. 各トランザクションには、グローバルに一意の増分 ID (zxid、64 ビット: エポック + 自動増分 ID) が割り当てられます。

最終的な整合性

1. 議決権行使の提案により取引提出の信頼性を確保する

2. 提案された投票方法では、クライアントがトランザクションの正常な送信を受信した後にのみ、ノードの半分以上が最新のデータを参照できるようにすることができます。

14. Zookeeper ではどのような役割があるか知っていますか?

システムモデル:

リーダー

リーダーサーバーは、クライアントに読み取りおよび書き込みサービスを提供します。投票の開始と解決、およびシステムステータスの更新を担当します。

学習者

フォロワー (フォロワー) フォロワーサーバーは、クライアントに読み取りサービスを提供し、リーダー選出プロセスに参加し、書き込み操作の「半分以上の書き込みが成功する」戦略に参加します。
オブザーバー (オブザーバー) オブザーバーサーバーは、クライアントに読み取りサービスを提供し、リーダー選出プロセスには参加せず、書き込み操作の「半分以上の書き込みが成功する」戦略にも参加しません。これは、書き込みパフォーマンスに影響を与えることなく、クラスターの読み取りパフォーマンスを向上させるために使用されます。

クライアント

サービスリクエストのイニシエーター。

15. Zookeeper ノード ZNode と関連する属性についてご存知ですか?

どのようなタイプのノードがありますか?

Znode には 2 つのタイプがあります。

永続的: クライアントとサーバーが切断された後、作成されたノードは削除されません (デフォルト)。

エフェメラル: クライアントとサーバーが切断された後、作成されたノードは自動的に削除されます。

Znodeには4つの形式があります

永続ディレクトリノード (PERSISTENT): クライアントが Zookeeper から切断した後も、ノードには永続的な連続番号ディレクトリノード (PERSISTENT_SEQUENTIAL) が残ります。
クライアントが Zookeeper から切断した後も、ノードはまだ存在しますが、Zookeeper はノード名に次のように連続番号を付けます: 一時ディレクトリノード (EPHEMERAL)
クライアントが Zookeeper から切断されると、ノードが削除されます: 一時連続番号ディレクトリノード (EPHEMERAL_SEQUENTIAL)
クライアントが Zookeeper から切断された後、ノードは削除されますが、Zookeeper はノード名に連続番号を付けます。

注: ZNode の作成時にシーケンス識別子を設定すると、ZNode 名の後に値が追加されます。シーケンス番号は、親ノードによって維持される単調増加のカウンターです。

ノードの属性とは何ですか

znode ノードはデータを保存できるだけでなく、その他の特別なプロパティも持つことができます。次に、/test ノードを作成して、そのさまざまな属性の意味を分析します。

[zk: localhost:2181(CONNECTED) 6] get /test

456

cZxid = 0x59ac //

ctime = 月 3 月 30 日 15:20:08 CST 2020

mZxid = 0x59ad

mtime = 2020 年 3 月 30 日月曜日 15:22:25 CST

pZxid = 0x59ac

バージョン = 0

データバージョン = 2

aclバージョン = 0

ephemeralOwner = 0x0

データ長 = 3

子供の数 = 0

プロパティの説明

16. Zookeeper のマスター選択プロセスについて簡単に説明してください

Zookeeper の中核はアトミックブロードキャストであり、サーバー間の同期を保証します。このメカニズムを実装するプロトコルは、Zab プロトコルと呼ばれます。Zab プロトコルには、リカバリモード (マスター選出) とブロードキャストモード (同期) の 2 つのモードがあります。サービスが開始されるか、リーダーがクラッシュした後、Zab はリカバリモードに入ります。リーダーが選出され、ほとんどのサーバーがリーダーとの状態同期を完了すると、リカバリモードは終了します。状態の同期により、リーダーとサーバーのシステム状態が確実に同じになります。リーダーの選出は、分散データの一貫性を確保するための鍵となります。

選挙には 2 つの主なシナリオがあります。それは、初期化とリーダーの不在です。

zk クラスター内のサーバーで次の 2 つの状況のいずれかが発生すると、リーダーの選出が開始されます。

(1) サーバが初期化され、起動されます。

(2) サーバ稼働中はリーダーとの接続を維持できません。

マシンがリーダー選出プロセスに入ると、現在のクラスターは次の 2 つの状態になる場合もあります。

(1) クラスター内に既にリーダーが存在します。

(2) 確かにクラスター内にリーダーは存在しません。

まず、最初のケースでは、通常、クラスター内の特定のマシンが比較的遅く起動され、起動する前にクラスターは正常に動作しています。つまり、リーダーサーバーがすでに存在します。マシンがリーダーを選出しようとすると、現在のサーバーのリーダー情報が通知されるため、リーダーマシンとの接続を確立し、状態の同期を実行するだけで済みます。

重要な点は、リーダーが不在であることと、現時点でのリーダー選択システムであることです。

投票情報には 2 つの基本情報が含まれます。

sid: クラスター内のマシンのシリアル番号を識別するために使用されるサーバー ID。

zxid: Zookeeper のトランザクション ID 番号。

ZooKeeper の状態のすべての変更は、zxid と呼ばれる増分されたトランザクション ID に対応します。zxid の増分性質により、zxid1 が zxid2 より小さい場合、zxid1 は zxid2 より前に発生する必要があります。ノードを作成したり、ノードのデータを更新したり、ノードを削除すると、Zookeeper の状態が変化し、結果として zxid の値が増加します。

投票情報は(sid,zxid)の形式で識別されます。

たとえば、現在のサーバーが sid が 1、zxid が 8 のサーバーをリーダーに推奨したい場合、投票情報は (1, 8) のように表現できます。

クラスター内の各マシンは独自の投票を送信した後、クラスター内の他のマシンからの投票も受け入れます。各マシンは、他のマシンから受け取った投票を特定のルールに従って処理し、自身の投票を変更するかどうかを決定します。

ルールは次のとおりです。

(1) 初期段階では全員が自分に投票します。

(2) 他のサーバーから投票を受け取る場合は、他人の投票と自分の投票を比較する必要がありますが、そのルールは次のとおりです: 最初に zxid を確認します。zxid が大きいサーバーがリーダーとして優先されます。zxid が同じ場合、sid が比較され、sid が大きいサーバーがリーダーになります。

すべてのサービスが開始されるときの選択プロセスは次のとおりです。

3 つのサーバー、server1、server2、server3:

1.server1 が起動しますが、マシンは選択されません。

2. サーバー 2 を起動し、サーバー 1 とサーバー 2 のステータスを検索中、ブロードキャスト投票に変更します。

3. Server3 が起動し、状態が looking に変わり、ブロードキャスト投票に参加します。

4. 初対面の状態では、誰もがお互いのことを知りませんので、誰もが自分を王様だと思い、自分をリーダーとして投票します。

5. 投票情報の説明投票情報は本来 5 つのタプルですが、ここでは論理を明確にするために式を簡略化しています。

初回は zxid = 0 で、sid は各ノードの名前です。この sid はzoo.cfg で設定されており、繰り返されません。

1. 初期 zxid=0、server1 投票 (1, 0)、server2 投票 (2, 0)、server3 投票 (3, 0)

2. サーバー 1 が投票 (2, 0) を受信すると、最初に投票の正当性を検証し、次に自分の投票を pk します。pk のロジックは、最初に zxid を比較することです、server1 (zxid) = server2 (zxid) = 0、zxid が等しい次に、sid、server1 (sid) < server2 (sid)、pk を比較すると、結果として、server2 の投票が勝ちます。server1 は投票を (2, 0) に更新し、server1 は再度投票します。

3. TODO ここで最終的に 2 になるか 3 になるかは実験によって決定する必要があります。

4. サーバー 2 がサーバー 1 から投票を受け取ると、最初に投票の正当性を検証し、次に pk を実行すると、自身の投票が勝ちます。サーバーは自身の投票を更新する必要はありません。pk の後、投票を再度送信します。

5. 投票を数えます pk 後、投票が行われ、半数以上のノードが同じ票を投じた場合、リーダーが選出されたと判断されます。

6. 選挙が終了すると、選択したノードのステータスが LOOKING から LEADING に変わり、選挙に参加している他のノードのステータスが LOOKING から FOLLOWING に変わります。オブザーバーノードが存在する場合、オブザーバーが選挙に参加しない場合、その状態は選挙の前後で常に OBSERVING となり、変化はありません。

一般的に言えば

投票開始 -> ノードのステータスが LOOKING になる -> 各ノードが自ら選択 -> PK の投票を受け取る -> big sid が勝利 -> 投票を更新 -> 再度投票 -> 投票を数え、投票結果の半分以上 -> ノードのステータス自身のキャラクターのステータスに更新されます。

17. Zookeeper クラスターの数が一般的に奇数なのはなぜですか?

まず第一に、飼育員の選出ルールを明確にする必要があります。リーダーの選出には、利用可能なノードの数 > ノードの総数 / 2 が必要です。

例: 書き込みが成功したかどうかのマーク付けは、半分以上のノードが書き込みリクエストを正常に送信した場合にのみ有効とみなされます。同様に、Zookeeper のリーダーノードの選択は、ノードの半分以上が同意した場合にのみ有効です。最後に、Zookeeper が正常かどうかは、ノードの半分以上が正常かどうかによって決まります。これは CAP の一貫性原則に基づいています。

Zookeeper には、クラスター内のマシンの半分以上が正常に動作している限り、クラスター全体が外部から利用できるという機能があります。

つまり、飼育員が 2 人いる場合、1 人の飼育員が死亡している限り、その飼育員は使用できません。1 は半分以下であるため、2 人の飼育員の死亡耐性は 0 です。

同様に、飼育員が 3 人いる場合、そのうちの 1 人が死亡し、正常な飼育員が 2 人、つまり半分以上残っているため、3 人の飼育員の許容値は 1 になります。

同じやり方で：

2->0; 2 人の飼育員、最大 0 人の飼育員が利用できなくなります。
3->1; 飼育員は 3 人ですが、最大 1 人の飼育員が不在になる可能性があります。
4->1; 飼育員は 4 人ですが、最大 1 人の飼育員が不在になる可能性があります。
5->2; 5 人の飼育員、最大 2 人の飼育員が利用できない場合があります。
6->2; 2 人の飼育員、最大 0 人の飼育員が利用できない場合があります。
....

2n と 2n-1 の許容値は同じであり、どちらも n-1 であるというルールが見つかります。効率を高めるために、不要な Zookeeper を追加する必要はありません。

Zookeeper の選挙戦略では、ノードの半数以上がリーダーになることに同意する必要があり、ノードが偶数であれば、同じ票数になる可能性があります。

18. Zookeeper リスナーの原理をご存知ですか?

1. Main() スレッドを作成します。

2. Main() スレッドに 2 つのスレッドを作成します。1 つはネットワーク接続通信 (connect) を担当し、もう 1 つはリッスン (listener) を担当します。

3. 登録されたリスニングイベントを接続スレッドを通じて Zookeeper に送信します。

4. 登録されたリスニングイベントを Zookeeper の登録済みリスナーリストに追加します。

5. Zookeeper は、データまたはパスの変更があることを検出すると、このメッセージをリスナースレッドに送信します。

6. process() メソッドがリスナースレッド内で呼び出されます。

19. Zookeeper の ACL 権限制御メカニズムについて話す

UGO（ユーザー/グループ/その他）

これは現在 Linux/Unix ファイルシステムで使用されており、最も広く使用されている権限制御方法でもあります。これは、大まかなファイルシステムのアクセス許可制御モードです。

ACL (Access Control List) アクセス制御リスト

次の 3 つの側面が含まれます。

許可モード (スキーム)

(1) IP：IPアドレス粒度による許可制御

(2) ダイジェスト: 最も一般的に使用され、権限設定にユーザー名:パスワードに似た権限識別子を使用します。これは、権限制御のためにさまざまなアプリケーションを区別するのに便利です。

(3) World: 最もオープンな権限制御方式で、権限識別子「world:anyone」を 1 つだけ持つ特殊なダイジェストモードです。

(4) スーパー: スーパーユーザー

認可されたオブジェクト

認可オブジェクトとは、認可が付与されるユーザー、または IP アドレスやマシンライトなどの指定されたエンティティを指します。

許可

(1) CREATE: データノード作成権限。認可されたオブジェクトがこの Znode の下に子ノードを作成できるようにします。

(2) DELETE: 子ノードの削除許可。許可されたオブジェクトがデータノードの子ノードを削除できるようにします。

(3) READ: データノードの読み取り権限。許可されたオブジェクトがデータノードにアクセスし、そのデータコンテンツや子ノードリストなどを読み取ることができます。

(4) WRITE: データノード更新権限。許可されたオブジェクトがデータノードを更新できるようにします。

(5) ADMIN: データノード管理権限。認可されたオブジェクトがデータノード上で ACL 関連の設定操作を実行できるようにします。

20. Zookeeper の展開モードは何ですか?

Zookeeper には 3 つの展開モードがあります。

1. スタンドアロン展開: クラスター上で実行します。

2. クラスター展開: 複数のクラスターが実行されます。

3. 擬似クラスター展開: クラスターは複数の Zookeeper インスタンスを起動して実行します。

21. Zookeeper クラスターはマシンの動的な追加をサポートしていますか?

実はこれは水平展開であり、Zookeeperはこの点があまり得意ではありません。ふたつのやり方：

すべて再起動: すべての Zookeeper サービスを閉じ、構成を変更した後に開始します。以前のクライアントセッションは影響を受けません。

1 つずつ再起動する: マシンの半分以上が稼働しており利用可能であるという原則に基づき、マシンを再起動しても、クラスター全体が提供する外部サービスには影響しません。これがより一般的な方法です。

バージョン 3.5 では、動的拡張のサポートが開始されました。

22. ZABプロトコルについて説明する

ZABプロトコルはZooKeeper自身が定義したプロトコルであり、正式名称はZooKeeperアトミックブロードキャストプロトコルといいます。

ZAB プロトコルには 2 つのモードがあります。リーダーノードがクラッシュしたときに回復する方法と、すべてのノードにメッセージをブロードキャストする方法です。

ZooKeeper クラスター全体にリーダーノードがない場合、クラッシュが発生します。たとえば、クラスターの起動が開始されたばかりで、この時点ではノードはお互いを認識していません。たとえば、リーダーノードの動作がダウンしているか、ネットワークに問題があり、他のノードがリーダーノードに ping を送信できないとします。このとき、ZAB のノード崩壊プロトコルが必要となり、すべてのノードが新しいリーダーを選出するために選出モードに入ります。選挙プロセス全体は放送によって実現されます。選挙が成功した後は、すべてがリーダーのデータに基づく必要があるため、データの同期が必要になります。

23. ZAB と Paxos アルゴリズムの関係と違いは何ですか?

同じ点：

(1) どちらもリーダープロセスと同様の役割を持ち、複数のフォロワープロセスの動作を調整する責任があります。

(2) リーダープロセスは、提案を送信する前に、フォロワーの半数以上が正しいフィードバックを提供するのを待ちます。

(3) ZAB プロトコルでは、各プロポーザルには現在のリーダーサイクルを表すエポック値が含まれており、Paxos での名前は Ballot です。

違い：

ZAB は可用性の高い分散データマスターおよびバックアップシステム (Zookeeper) を構築するために使用され、Paxos は分散された一貫性のあるステートマシンシステムを構築するために使用されます。

24. ZooKeeper のダウンタイムにどう対処するか?

ZooKeeper 自体もクラスターなので、奇数のサーバーを構成することをお勧めします。ダウンタイムのため選挙が必要であり、同数を避けるためには +1 票の半分が選挙を通過する必要があります。偶数のサーバーを持たずに参加してください。

フォロワーがダウンしていても問題はなく、使用には影響しません。ユーザーは気づいていません。リーダーがダウンした場合、クラスターは外部サービスを停止して選挙を開始する必要があります。リーダーノードが選出された後、すべてのノードとリーダーのデータが確実に統合されるようにデータ同期が実行され、外部サービスが開始されます。

なぜ投票には半分 + 1 が必要なのでしょうか? 半分で十分な場合、ネットワークの問題によりクラスターが 2 人のリーダーを選出し、それぞれのリーダーを弟の半分がサポートするため、データが混乱してしまいます。

25. ZooKeeper におけるセッション管理の考え方について説明してください。

バケット戦略:

簡単に言うと、セッションの有効期限には、15 秒、15.1 秒、15.8 秒などの間隔があり、ZooKeeper はこれらのセッションを一律 16 秒で期限切れにします。これは管理上非常に便利です。次の式を参照してください。有効期限は常に ExpirationInterval の整数倍になります。

計算式：

ExpirationTime = currentTime + sessionTimeout

ExpirationTime = (ExpirationTime / ExpirationInrerval + 1) * ExpirationInterval 、

画像を参照してください:

デフォルトで設定されているセッションタイムアウトは 2tickTime ～ 20tickTime です。

26. ZooKeeper の負荷分散と Nginx の負荷分散の違いは何ですか?

飼育員：

単一点の問題はなく、zab メカニズムにより、単一点障害が発生してもリーダーを再選出できます。
サービスの登録と検出のみを担当し、転送は担当せず、データ交換 (消費者とサーバー間の直接通信) を削減します。
対応する負荷分散アルゴリズムを自分で実装する必要があります

Nginx：

単一点の問題があり、単一点の負荷が高く、データ量が大きいため、高可用性を実現するには KeepAlived による支援が必要です。
各ロードは中間転送の役割として機能し、それ自体がリバースプロキシサーバーになります。
組み込みの負荷分散アルゴリズム

27. ZooKeeperの連載について語る

シリアル化:

メモリデータはハードディスクに保存する際にシリアル化する必要があります。
ネットワークを通じて他のノードに送信されるメモリデータはシリアル化する必要があります。

ZK で使用されるシリアル化プロトコルは Jute で、Record インターフェイスを提供します。このインターフェイスには 2 つのメソッドが用意されています。

シリアル化メソッド
deserialize 逆シリアル化メソッド

この 2 つのメソッドでは、シリアル化するメソッドをストリームオブジェクトに格納できます。

28. Zookeeper の Zxid とは何ですか?またその機能は何ですか?

Zxid (トランザクション ID) は、トランザクションの逐次一貫性を確保するために、ZooKeeper は増分トランザクション Zxid を使用してトランザクションを識別します。Zxid が提案に追加されます。Zxid は 64 ビットの数値であり、その上位 32 ビットはエポックによって王朝の変更を識別するために使用されます。たとえば、エポックは選挙が行われるたびに変更されます。下位 32 ビットはカウントアップに使用されます。

Epoch: 現在のクラスターの年齢または周期として理解できます。各リーダーは皇帝のようなもので、独自の年名を持っています。したがって、王朝が変わるたびに、リーダーは変更後の前の時代に 1 を加えます。このようにして、古いリーダーがクラッシュして回復した後でも、フォロワーは現在のリーダーの命令に従うだけなので、誰もそれを聞きません。

29. ZooKeeperの永続化メカニズムを説明する

持続性とは何ですか?

ディスクまたはファイルに保存されたデータ。
マシンの再起動後、データは失われません。メモリ -> ディスクのマッピングはシリアル化に似ています。

ZooKeeper の永続性:

SnapShot スナップショット、メモリ内の全データを記録
TxnLog 増分トランザクションログ。各追加、削除、および変更レコードを記録します (チェックはトランザクションログではないため、データ変更は発生しません)

永続化はなぜこんなに面倒なのですか?

スナップショットの欠点は、ファイルが大きすぎるため、スナップショットファイルが最新のデータではなくなることです。インクリメンタルトランザクションログの欠点は、実行に時間がかかること、ログが多すぎること、読み込みが遅すぎることです。この 2 つを組み合わせると最も効果的です。

スナップショットモード:

DataTree データ構造内の ZooKeeper メモリに保存されているデータは、定期的にディスクに保存されます。
スナップショットファイルはデータの定期的な完全バックアップであるため、通常、スナップショットファイル内のデータは最新ではありません。

画像を参照してください:

30. 動物園飼育員選挙における投票情報の 5 つのタプルとは何ですか?

リーダー: 選出されたリーダーの SID
Zxid: 選出されたリーダーのトランザクション ID
Sid: 現在のサーバーの SID
選挙エポック: 現在の投票ラウンド
peerEpoch: 現在のサーバーのエポック

エポック > Zxid > シド

Epoch と Zxid は同じかもしれませんが、Sid は違うはずなので、2 票の結果は確実に PK になります。

31. Zookeeper のスプリットブレインについて話しますか?

簡単に言うと、スプリットブレインとは、クラスター内に 2 つのノードがある場合、両方のノードがこのクラスター内でマスターを選択する必要があることを認識していることを意味します。そして両者の通信に問題がなければ合意が得られ、どちらかがマスターとして選ばれます。しかし、それらの間の通信に問題がある場合、2 つのノードはマスターが存在しないと認識し、それぞれが自分自身をマスターとして選択するため、クラスター内に 2 つのマスターが存在することになります。

Zookeeper にとって、ノードが停止しているかどうかをどのような状況で判断するかという非常に重要な問題があります。分散システムでは、これらはモニターによって判断されますが、モニターが他のノードの状態を判断することも困難です。唯一信頼できる方法はハートビートです。Zookeeper はまた、ハートビートを使用してクライアントがまだ生きているかどうかを判断します。

ZooKeeper を使用してリーダー HA を実行する方法は基本的に同じです: 各ノードはリーダーを象徴する一時ノードの登録を試行し、登録に失敗した他のノードはフォロワーになり、リーダーによって作成された一時ノードを監視メカニズムを通じて監視します。内部のハートビートメカニズムは、リーダーのステータスを決定するために使用されます。リーダーに事故が発生すると、動物園の飼育員はそれをすぐに学習して他のフォロワーに通知し、他の花もそれに応じて応答し、切り替えが完了します。この一部は行われます。。しかし、ここには非常に深刻な問題があります。これに気付かないと、短期間でシステムにスプリットブレインが発生します。ハートビートタイムアウトはリーダーのハングアップである可能性もありますが、 Zookeeper ノード間のネットワークに問題があり、その結果、リーダーが死亡しました。一時停止アニメーションの場合、リーダーは実際には死亡しませんでしたが、ZooKeeper のネットワークに問題があったため、Zookeeper はダウンしていると判断し、他のノードに切り替えるように通知しました。そのため、フォロワーの 1 人がリーダーになりましたが、元のリーダーはリーダーになりませんでしたこのとき、クライアントにもリーダー切り替えのメッセージが届きますが、それでも多少の遅延が発生します。Zookeeper は通信する必要があり、1 つずつ通知される必要があります現時点では、システム全体が非常に混乱しています。おそらく一部のクライアントは新しいリーダーに接続するように通知されています。一部のクライアントはまだ古いリーダーに接続しています。2 つのクライアントがリーダーの同じデータを更新する必要がある場合、同時に、これら 2 つのクライアントが現時点で新旧のリーダーに接続されている場合、深刻な問題が発生します。

簡単な概要は次のとおりです:死んだふり:リーダーはハートビートタイムアウト (ネットワーク上の理由による) により死亡したと思われますが、実際にはリーダーはまだ生きています。スプリットブレイン:仮死状態のため、新しいリーダーを選出するために新しいリーダー選挙が開始されますが、古いリーダーネットワークが再び接続され、その結果 2 つのリーダーが発生します。一部のクライアントは古いリーダーに接続し、一部のクライアントはその後、新しいリーダー。

32. 動物園飼育員のスプリットブレインの原因は何ですか?

主な理由は、タイムアウト判定時に Zookeeper クラスタと Zookeeper クライアントが完全に同期できないことです。同時に、検出と切り替え後に各クライアントに通知するための一連の速度もあります。一般に、この状況が発生する可能性は非常に低く、リーダーノードを Zookeeper クラスターネットワークから切断する必要がありますが、他のクラスターロール間のネットワークには問題がなく、上記の条件を満たす必要がありますが、一度発生するとデータに一貫性がありません。

33. Zookeeper はスプリットブレイン問題をどのように解決しますか?

スプリットブレイン問題を解決するには、一般に次の方法があります。クォーラム (定足数) 方法: たとえば、3 つのノードを持つクラスターでは、クォーラム = 2、つまり、クラスターは 1 つのノードの障害を許容できます。リーダーを 1 人選出でき、クラスターは引き続き使用できます。たとえば、4 つのノードを持つクラスターの場合、そのクォーラム数は 3 であり、クォーラム数は 3 を超える必要があります。これは、クラスターの許容値が 1 のままであることを意味します。2 つのノードに障害が発生した場合、クラスター全体は依然として無効になります。これは、動物園の飼育員が「スプリットブレイン」を防ぐために使用するデフォルトの方法です。

冗長通信（冗長通信）モードが使用されます。クラスタ内で複数の通信モードが使用され、1 つの通信モードの障害によってクラスタ内のノードが通信できなくなるのを防ぎます。

フェンシング（共有リソース）方式：例えば、共有リソースが見えていればクラスタ内にあることを意味し、共有リソースのロックを取得できるリーダーがリーダーとなります。リソースがある場合、クラスター内にいません。

動物園の飼育員の「脳の分裂」を回避するのは実際には非常に簡単です。フォロワーノードが切り替わるとき、古いリーダーノードに問題があることを確認した後すぐに切り替わるのではなく、古いリーダーノードが正常に動作していることを確認するために十分な時間スリープします。リーダーは変更について通知されており、関連するシャットダウンクリーンアップ作業を実行してからマスターとして登録すると、この種の問題は回避できます。スリープ時間は通常、飼育員によって定義されたタイムアウト時間として定義されますが、システムがそうでない場合もあります。この期間中は利用できますが、データの不整合による影響を考慮すると価値があります。

1. ZooKeeper は、「スプリットブレイン」現象を防ぐためにデフォルトでクォーラムを採用します。つまり、クラスター内の半分を超えるノードだけがリーダーを選出するために投票します。この方法により、唯一のリーダーが選出されるか、選出が失敗するかにかかわらず、リーダーの一意性が保証されます。飼育員における定足数の役割は次のとおりです。

クラスター内のノードの最小数は、クラスターが確実に使用できるようにリーダーを選出するために使用されます。
データが安全に保存される前に、クラスター内の最小数のノードによってデータが保存されたことをクライアントに通知します。これらのノードがデータを保存すると、クライアントはデータが安全に保存されたことが通知され、他のタスクを続行できるようになります。最終的にはクラスター内の残りのノードにもデータが保持されます。

リーダーが仮死状態で死亡した場合、残りの信者が新しいリーダーを選出します。このとき、古いリーダーは復活し、依然として自分自身をリーダーであると認識しており、このとき、他のフォロワーへの書き込みリクエストの送信も拒否されます。新しいリーダーが生成されるたびに、エポックラベル (リーダーの現在の支配期間を識別する) が生成されるためです。このエポックは増分です。フォロワーが新しいリーダーの存在を確認し、そのエポックを知っている場合、彼らはそのエポックを拒否します現在のリーダーより小さいこと。エポックに対するすべてのリクエスト。新しいリーダーの存在を知らないフォロワーはいますか? それは可能ですが、ほとんどのフォロワーは間違いなくそうではなく、そうでない場合は新しいリーダーを生成できません。Zookeeper の文章もクォーラムの仕組みに従っているため、多数派に支持されていない書き込みは無効であり、たとえ古いリーダーが自分をリーダーだと思っていたとしても、効果はありません。

上記のデフォルトのクォーラム方式を使用して「スプリットブレイン」を回避することに加えて、動物園管理者は次の予防策を講じることもできます。 2. 二重回線などの冗長なハートビートラインを追加して、「スプリットブレイン」の可能性を最小限に抑えます。3. ディスクロックを有効にします。サービス提供側は共有ディスクをロックし、「スプリットブレイン」が発生すると、相手側は共有ディスクリソースを完全に「奪うことができなくなります」。しかし、ロックディスクの使用には大きな問題があり、共有ディスクを占有している側が積極的に「ロックを解除」しないと、相手は共有ディスクを取得することができません。実際には、サービスノードが突然クラッシュしたりクラッシュしたりすると、ロック解除コマンドを実行できなくなります。バックアップノードは、共有リソースとアプリケーションサービスを引き継ぐことができません。そこで誰かが HA の「スマート」ロックを設計しました。つまり、サービス提供側は、ハートビートラインがすべて切断されている (ピアエンドが検出できない) と判明した場合にのみ、ディスクロックを有効にします。通常は施錠されていません。4. 仲裁メカニズムをセットアップします。たとえば、参照 IP (ゲートウェイ IP など) を設定します。ハートビートラインが完全に切断されると、両方のノードが参照 IP に ping を実行します。失敗した場合は、ブレークポイントが「ハートビート」だけでなくローカルエンドにあることを意味します。、ただし、外部の「サービス」も同様です。ローカルエンドのローカルネットワークリンクが切断されている場合、アプリケーションサービスを開始（または継続）しても無駄であるため、競争は自主的に放棄され、ping できるエンドが行われます。参照 IP でサービスを開始できます。より安全にするために、参照 IP に ping できない側は単に自身を再起動して、まだ占有されている可能性のある共有リソースを完全に解放します。

34. Zookeeper の CAP 問題に関するトレードオフについて教えてください。

一貫性 C : Zookeeper は強力な一貫性システムですが、強力な可用性を確保するために、「半分以上の成功は成功を意味する」というデータ同期方法では、一部のノードでデータの不整合が発生する可能性があります。したがって、Zookeeper は、すべてのノードのデータを同期するための sync() オペレーションも提供します。これは、C と A の選択をユーザーに委ねます。これは、sync() を使用すると、同期時間が必然的に長くなり、可用性がいくらか失われるためです。

可用性 A : Zookeeper データはメモリに保存され、各ノードは読み取り要求に良好な応答性能で応答できます。Zookeeper は、データがロックなしで常に利用できることを保証します。そして、ノードの半分以上が最新のデータを持っています。

パーティション許容値 P : フォロワーノードが多すぎると、データ同期の遅延が増加します (フォロワーの半数以上が書き込みとコミットを完了する必要があります)。同時に、選挙プロセスの収束速度が遅くなり、可用性が低下します。Zookeeper はオブザーバーノードを導入することでこの問題を軽減します。オブザーバーノードを追加すると、クラスターはクライアント要求に対してより多くのノードを受け入れることができ、オブザーバーは投票に参加しなくなるため、可用性とスケーラビリティが向上しますが、マルチノードのデータ同期が常に問題になります。そのため、一貫性が低下します。

35. 監視監視はなぜ 1 回限りですか?

サーバーが頻繁に変更され、監視クライアントが多数ある場合は、変更のたびにすべてのクライアントに通知する必要があり、ネットワークとサーバーに多大な負荷がかかります。

通常、クライアントは getData(node A,true) を実行し、ノード A が変更または削除された場合、クライアントはその監視イベントを取得しますが、その後ノード A が再び変更され、クライアントは監視イベントを設定しません。クライアントには送信されなくなりました。

実際のアプリケーションでは、多くの場合、クライアントはサーバーのすべての変更を知る必要はなく、最新のデータのみが必要です。