Hadoopの分散サービスフレームワーク-ZooKeeper

ZooKeeper

1.はじめに

1.1それはなんですか？

Zookeeperは、分散アプリケーションの調整サービスを提供するオープンソースの分散Apacheプロジェクトです。

1.2、設計目標

Zookeeperは開発には使用されず、それらのほとんどは他のクラスターにサービスを提供します
ほとんどのアプリケーションはプライベートな調整プログラムを開発する必要がありますが、調整プログラムを繰り返し作成するには、多くの時間、人的資源、その他のリソースが必要です。共通の調整サービスメカニズムを持つために、Zookeeperが誕生しました。
ZooKeeperの設計目標は、これらの複雑でエラーが発生しやすい分散整合性サービスをカプセル化して、効率的で信頼性の高いプリミティブセットを形成し、ユーザーに一連のシンプルで使いやすいインターフェイスを提供することです。

プリミティブ：オペレーティングシステムまたはコンピュータネットワークの用語カテゴリ。これは、特定の機能のプロセスを完了するために使用されるいくつかの命令で構成されています。これは分割できません。つまり、プリミティブの実行は継続的である必要があり、実行中に中断することはできません。

1.3、役割

飼育係は、次のような機能を実装するために使用することができ、データが公開/サブスクリプション、負荷分散、コマンドサービス、分散協調/通知、クラスタ管理、マスターの選択、分散ロック、および分散キュー、分散システムでは一般的です。

2.機能

リーダー（リーダー）と複数のフォロワー（フォロワー）で構成されるクラスター
盟主投票の開始と解決を担当し、システムステータスを更新します。
フォロワー顧客の要求を受け取り、結果を最後まで返し、リーダー選出プロセス中に投票に参加するために使用されます
クラスター内のノードの半分以上が存続する限り、Zookeeperクラスターは正常に機能できます
グローバルデータは一貫しています。各サーバーは同じデータのコピーを保存します。クライアントがどのサーバーに接続しても、データは一貫しています。
更新要求は順番に実行され、同じクライアントからの更新要求は送信された順序で実行されます。
データ更新の原子性、データ更新は成功または失敗します
リアルタイム、特定の時間範囲内で、クライアントは最新のデータを読み取ることができます

3、データ構造

Zookeeperは、ファイルシステムと同様のデータ構造を維持します。各ノードはZnodeと呼ばれます。Znodeを自由に追加および削除したり、Znodeの下にサブZnodeを追加および削除したりできます。他のファイルシステムとは異なり、Znodeはデータを保存できます。

ここに画像の説明を挿入

Znode
■各Znodeはデフォルトで保存できます1MBデータ
■すべてのZnodeはユニークな道ロゴ
Znodeノードタイプ
■PERSISTENT：永続ノード、デフォルトタイプ
   ■クライアントがzookeeperから切断した後も、ノードは存在します
■PERSISTENT_SEQUENTIAL：永続シーケンス番号ノード
   ■クライアントがzookeeperから切断した後も、ノードは存在しますが、Zookeeperはノード名に番号を付けます順番に
■EPHEMERAL：一時ノード
   ▪クライアントがzookeeperから切断した後、ノードが削除されます
■EPHEMERAL_SEQUENTIAL：一時シーケンス番号付けノード
   ▪クライアントがzookeeperから切断した後、ノードが削除されますが、Zookeeperはノード名にシリアル番号を付けます

4.動作メカニズム

4.1、動作原理

飼育係=ファイルシステム+通知メカニズム
■飼育係がされ、分散サービス管理フレームワークを設計に基づいて、観察モードデザインモードから。それが担当する保存及び管理データをすることを、誰もが気にして、観察者の登録を受け入れる。
■一度データは状態にあります変更が発生すると、Zookeeperは、クラスター内で同様のマスター/スレーブ管理モデルを実現するために、Zookeeperに登録されているオブザーバーにそれに応じて応答するよう通知する責任があります。

4.2。選挙メカニズム

選挙のメカニズムを説明する大規模な言葉による参照Zookeeper

4.2.1。基本概念

半分のメカニズム：クラスター内のマシンの半分以上が存続し、クラスターが使用可能になります。したがって、飼育係は奇数台のマシンにインストールするのに適しています。
Zookeeperは、構成ファイルでマスターとスレーブを指定していませんが。ただし、zookeeperが機能している場合、一方のノードがリーダーで、もう一方のノードがフォロワーであり、リーダーは内部の選出メカニズムによって一時的に生成されます。
リーダー選択メカニズムの場合、
zookeeperは次の3つの方法を提供します。▶LeaderElection
▶AuthFastLeaderElection
▶FastLeaderElection

4.2.2、FastLeaderElection選挙プロセス

Zookeeperクラスター内のサーバーで次の2つの状況のいずれかが発生した場合は、次のように入力する必要があります。 Leader 选举

（1）サーバーが初期化されて起動します
ここに画像の説明を挿入

サーバー1は起動し、投票してから投票情報を送信します。他のマシンはまだ起動していないため、フィードバック情報を受信できません。サーバー1のステータスは常にLOOKING（選挙ステータス）に属します。
サーバー2が起動し、自分で投票し、以前に起動したサーバー1と結果を交換します。サーバー2の数が多いため、サーバー2が勝ちますが、現時点では投票数が半分以下であるため、2つのステータスサーバーはまだ同じLOOKINGです。
サーバー3が起動し、自分で投票し、以前に起動したサーバー1および2と情報を交換します。サーバー3の数が最も多いため、サーバー3が勝ちます。現時点では、投票数は半分以上です。サーバー1と2がFOLLOWINGサーバー3に変更され、サーバー3のステータスが変更されます。ステータスはLEADINGです。
サーバー4が起動し、自分に投票して、前のサーバー1、2、3と情報を交換します。サーバー4の数は多いですが、サーバー3は以前に勝ったため、サーバー4は子供にしかなれません。
サーバー5が起動し、次のロジックはサーバー4と同じで弟になります

最終的に、サーバー3がリーダーであり、ステータスはLEADING;残りのサーバーはフォロワーであり、ステータスはFOLLOWING

（2）サーバー運用中のリーダー障害
ここに画像の説明を挿入
クラスターリーダーノード障害
運用期間の選択は、基本的に初期状態の投票プロセスと同様であり、大まかに次のステップに分けることができます。

（1）ステータスの変更。リーダーに障害が発生すると、残りの非オブザーバーサーバーはサーバーのステータスをLOOKINGに変更し、リーダーの選出プロセスを開始します。

（2）各サーバーが投票を行います。

（3）各サーバーから投票を受け取り、他のサーバーのデータが自分のサーバーよりも新しい場合は投票を変更します。

（4）投票の処理と開票各ラウンドの投票後に投票がカウントされ、その半分以上を選出することができます。

（5）サーバーのステータスを変更し、選出を発表します。

さらに面倒なことはせずに、最初に写真を撮りましょう。
ここに画像の説明を挿入
ランナーリーダーが失敗した後の選挙プロセス
（1）初めて投票するときは、各マシンが自分自身に投票します。

（2）次に、各マシンが他のマシンに投票を送信します。他のマシンのzxidが自分のマシンよりも大きい場合は、投票を変更して再度投票する必要があります。たとえば、server1は3票を獲得し、server2のxzidが102であることがわかり、pkは自分が負けたことを知りました。その後、彼はserver2にボスとして投票することにしました。

4.2.3、コアコンセプト

（1）サーバーID（またはsid）：サーバーID

たとえば、サーバーは3つあり、その数は1、2、および3です。数値が大きいほど、選択アルゴリズムの重みが大きくなります。たとえば、最初の起動時にサーバーIDに基づいて比較が実行されます。

（2）Zxid：トランザクションID

サーバーに格納されているデータのトランザクションID。値が大きいほど、データは新しくなります。選択アルゴリズムでは、データが新しいほど、重みが大きくなります。

（3）エポック：論理クロック

投票数とも呼ばれ、同じ投票ラウンドの論理クロック値は同じであり、このデータは投票ごとに増加します。

（4）サーバーステータス：選挙ステータス

LOOKING、キャンペーンステータス

FOLLOWING、フォロワーステータス、リーダーステータスの同期、投票への参加

OBSERVING、状態を観察し、リーダーの状態を同期し、投票に参加しない

LEADING、リーダーステータス

4.2.4。まとめ

（1）Zookeeperの選出は、サーバーの初期状態と実行状態で行われます。

（2）初期状態では、サーバーのsid番号で比較されます。数値が大きいほど重みが大きくなり、半分以上の票が投じられた場合はリーダーを選択できます。

（3）リーダーの失敗は、新しい選挙ラウンドをトリガーします。新しいzxidがデータを表すほど、重みが大きくなります。

（4）実行中の選挙では、スプリットブレインの状況が発生する可能性があります。自分で学ぶことができます。

4.3。リスナーの原則

ここに画像の説明を挿入
（1）最初にmain（）スレッドが必要です
（2 ）スレッドにZookeeperクライアントを作成し、次に2つのスレッドを作成します。1つはネットワーク接続通信（connet）を担当し、もう1つはリスニング（リスナー）を担当します。
（3）合格接続スレッドは登録済みリスナーイベントをZookeeperに送信します
（4）イベントをZookeeperの登録済みリスナーのリストに追加します
（5）Zookeeperがデータまたはパスの変更をリッスンすると、このメッセージをリスナースレッドに送信します
（ 6））process（）メソッドは、処理のためにリスナースレッド内で呼び出され
ます。2。一般的な監視
（1）ノードデータの変更の監視：
get path [watch]
（2）子ノードの変更の監視
ls path [watch] ]

4.4。ワークフロー

（1）クライアントはzookeeperサーバーにデータを書き込む要求を送信します
（2）サーバーがリーダーでない場合は、要求をリーダーに転送します
（3）リーダーは要求を処理し、すべてのフォロワーにデータをブロードキャストします。フォロワーは書き込み操作を実行します
（4）フォロワーの半分がOKをフィードバックする限り、リーダーはすべてのフォロワーにコミットメッセージを送信します
ここに画像の説明を挿入