Zookeeperを使い始めるには必見です

動物園の飼育係の紹介

Zookeeperは、分散サービスフレームワークであり、Apache Hadoopのサブプロジェクトです。主に、統合ネーミングサービス、状態同期サービス、クラスター管理、アプリケーション構成の分散管理など、分散アプリケーションでよく発生するデータ管理の問題を解決するために使用されます。アイテムなど前の説明は少し公式です。簡単に言えば、zookeeper =ファイルシステム+モニター通知メカニズムです。

注：クライアントとサーバー間の接続はTCPロング接続に基づいており、最下層はデフォルトでjavaのNIOメソッドを使用し、netty実装メソッドも構成できます。クライアント側は、セッションであるサーバー側のデフォルトポート2181に接続します。最初の接続確立から開始して、クライアントはセッションのライフサイクルを開始し、クライアントはサーバーにpingパケットを要求します。各セッションはタイムアウト期間を設定できます。

zookeeperのデータ構造

zookkeeperによって提供される名前空間は、キー値の形式で格納される標準のファイルシステムと非常によく似ています。名前キーは、スラッシュ/で区切られた一連のパス要素です。動物園管理者の名前空間の各ノードは、パスで識別されます。

BASE理論

BASEは、Basicly Available、Soft-state、およびEventallyConsistentの3つのフレーズの略語です。

基本的に使用可能：分散システムに障害が発生すると、可用性の一部（サービスの低下、ページの低下）が失われる可能性があります。
ソフト状態：分散システムの中間状態を許可します。また、中間状態はシステムの可用性に影響を与えません。ここでの中間状態とは、異なるデータレプリケーション（データバックアップノード）間のデータ更新を遅らせることができる結果整合性を指します。
結果整合性：データ複製は、一定期間にわたって整合性に達します。

BASE理論は、CAPの整合性と可用性の間のトレードオフの結果です。理論の中心的な考え方は、強力な整合性を実現することはできませんが、各アプリケーションは、システムを結果整合性に到達させるための適切な方法を採用できます。

4種類のznode

PERSISTENT-永続ディレクトリノード

クライアントがzookeeperから切断した後も、ノードはまだ存在しています
PERSISTENT_SEQUENTIAL-永続的なシーケンス番号ディレクトリノード

クライアントがzookeeperから切断された後も、ノードは存在しますが、Zookeeperはノード名に連番を付けます
EPHEMERAL-一時ディレクトリノード

クライアントがzookeeperから切断した後、ノードは削除されます
EPHEMERAL_SEQUENTIAL-一時的なシーケンス番号付けディレクトリノード

クライアントがzookeeperから切断した後、ノードは削除されますが、Zookeeperはノード名に連番を付けます

Zookeeperノードの特性

1.同じレベルのノードのキー名は一意です

2.ノードを作成するときは、フルパスを用意する必要があります

3.セッションが閉じられ、一時ノードがクリアされます

4.シーケンスノードを自動的に作成します

5.ノードの変更を監視するメカニズムを監視する

イベント監視メカニズムはオブザーバーモードに似ています。監視プロセスでは、クライアントはサーバー上のノードパスにウォッチャーを登録し、クライアントは特定のウォッチャーも保存します。ノードデータまたは子ノードが変更されると、サーバーは通知します。クライアント最後に、クライアントはコールバック処理を実行します。特記事項：監視イベントが1回トリガーされると、イベントは無効になります。

ヒント：一般的なコマンドの章でwatchの使用を監視するには、getコマンドを参照してください。次の章では、watchの実装の原則について詳しく説明します。

6. deleteコマンドは、レイヤーごとにのみ削除できます

ヒント：新しいバージョンは、deleteallコマンドを使用して再帰的に削除できます。

上記の多くのノード特性により、zookeeperは次のようなさまざまな古典的なアプリケーションシナリオを開発できません。

データのパブリッシュ/サブスクライブ
負荷分散
分散調整/通知
クラスター管理
マスターマネジメント
分散ロック

動物園の飼育係のピアノードの独自の機能を利用して、複数のユーザーが特定のメニューで同時に一時的なサブノードを作成し、分散ロックを正常に作成します。ロックを取得していない他のユーザーは、サブノードを変更するウォッチャーを登録します。このメニュー。ロックを取り戻すためにイベントをリッスンします。

分散キュー

Zookeeperデータ同期プロセス

Zookeeperでは、ZABプロトコルは主に分散データの整合性を実現するために使用されます。

ZAB契約は、次の2つの部分に分かれています。

ニュース番組
クラッシュリカバリ

ニュース番組

Zookeeperは、単一のメインプロセスリーダーを使用して、クライアントからのすべてのトランザクションリクエストを受信して処理します（フォロワーノードがリクエストを受信した場合でも、リーダーに転送され、リーダーはすべてのフォロワーノードにトランザクションリクエストを送信します）、およびZABプロトコルのアトミックブロードキャストプロトコルを採用し、提案提案としてすべてのフォロワーノードにトランザクションリクエストをブロードキャストします。クラスター内のフォロワーサーバーの半分以上が正しいACKフィードバックを提供すると、リーダーはコミットメッセージをに送信します。提案を送信するために、すべてのフォロワーサーバーを再度実行します。このプロセスは、略して2pcトランザクション送信と呼ばれます。プロセス全体は次の図を参照できます。オブザーバーノードはリーダーデータの同期のみを担当し、2PCデータ同期プロセスには参加しないことに注意してください。

クラッシュリカバリ

通常の状況では、メッセージブロードキャストは正常に機能しますが、リーダーサーバーがクラッシュするか、ネットワークの原則によりリーダーサーバーがフォロワーの半分以上との通信を失うと、クラッシュリカバリモードになり、新しいリーダーサーバーは次のことを行う必要があります。選出される。このプロセスでは、データの不整合の2種類の隠れた危険性が存在する可能性があります。これらは、ZABプロトコルの特性によって回避する必要があります。

リーダーサーバーがメッセージcommitを送信すると、すぐにクラッシュします
提案を行った直後にリーダーサーバーがクラッシュしました

ZABプロトコルの回復モデルは、次の戦略を使用します。

最大のzxidを持つノードを新しいリーダーとして選択します
新しいリーダーは、トランザクションログ内のコミットされていないメッセージを処理します