Zookeeper-基本

ZooKeeperの動作に深く入る前に、ZooKeeperの基本的な概念を見てみましょう。この章では、次のトピックについて説明します-

Architecture
階層的な名前空間
Session
Watches

ZooKeeperのアーキテクチャ

次の図を見てください。これは、ZooKeeperの「クライアントサーバーアーキテクチャ」を表しています。

次の表では、ZooKeeperアーキテクチャの一部である各コンポーネントについて説明しました。

部	説明
クライアント	分散アプリケーションクラスターのノードの1つであるクライアントは、サーバーからの情報にアクセスします。特定の時間間隔で、すべてのクライアントがサーバーにメッセージを送信して、クライアントが生きていることをサーバーに通知します。同様に、クライアントが接続すると、サーバーは確認応答を送信します。接続されたサーバーからの応答がない場合、クライアントはメッセージを別のサーバーに自動的にリダイレクトします。
サーバ	ZooKeeperアンサンブルのノードの1つであるサーバーは、すべてのサービスをクライアントに提供します。サーバーが稼働していることを通知するためにクライアントに確認応答を与えます。
アンサンブル	ZooKeeperサーバーのグループ。アンサンブルを形成するために必要なノードの最小数は3です。
盟主	接続されたノードのいずれかに障害が発生した場合に自動回復を実行するサーバーノード。リーダーはサービスの開始時に選出されます。
フォロワー	リーダーの指示に従うサーバーノード。

階層的な名前空間

次の図は、メモリ表現に使用されるZooKeeperファイルシステムのツリー構造を示しています。ZooKeeperノードはznode。すべてのznodeは名前で識別され、一連のパス（/）で区切られます。

この図では、最初にルートがあります znode「/」で区切ります。ルートの下には、2つの論理名前空間がありますconfig そして workers。
ザ・ config 名前空間は、一元化された構成管理と workers 名前空間は命名に使用されます。
下 config名前空間では、各znodeは最大1MBのデータを格納できます。これは、親znodeがデータも格納できることを除いて、UNIXファイルシステムに似ています。この構造の主な目的は、同期されたデータを格納し、znodeのメタデータを記述することです。この構造は次のように呼ばれますZooKeeper Data Model。

ZooKeeperデータモデルのすべてのznodeは、 stat構造。統計は単に提供しますmetadataznodeの。これは、バージョン番号、アクション制御リスト（ACL）、タイムスタンプ、およびデータ長で構成されます。

Version number−すべてのznodeにはバージョン番号があります。つまり、znodeに関連付けられたデータが変更されるたびに、対応するバージョン番号も増加します。複数のzookeeperクライアントが同じznodeで操作を実行しようとしている場合は、バージョン番号の使用が重要です。
Action Control List (ACL)− ACLは基本的に、znodeにアクセスするための認証メカニズムです。これは、すべてのznode読み取りおよび書き込み操作を管理します。
Timestamp−タイムスタンプは、znodeの作成と変更からの経過時間を表します。通常、ミリ秒単位で表されます。ZooKeeperは、「トランザクションID」（zxid）からznodeへのすべての変更を識別します。Zxid は一意であり、各トランザクションの時間を維持するため、あるリクエストから別のリクエストまでの経過時間を簡単に識別できます。
Data length−znodeに格納されているデータの合計量がデータ長です。最大1MBのデータを保存できます。

Znodeの種類

Znodeは、永続性、順次、および一時的なものとして分類されます。

Persistence znode−永続性znodeは、その特定のznodeを作成したクライアントが切断された後も存続します。デフォルトでは、特に指定がない限り、すべてのznodeは永続的です。
Ephemeral znode−エフェメラルznodeは、クライアントが稼働するまでアクティブです。クライアントがZooKeeperアンサンブルから切断されると、エフェメラルznodeは自動的に削除されます。このため、一時的なznodeのみがそれ以上子を持つことは許可されていません。エフェメラルznodeが削除されると、次の適切なノードがその位置を埋めます。一時的なznodeは、リーダー選出において重要な役割を果たします。
Sequential znode−シーケンシャルznodeは、永続的または一時的のいずれかになります。新しいznodeがシーケンシャルznodeとして作成されると、ZooKeeperは、元の名前に10桁のシーケンス番号を付加してznodeのパスを設定します。たとえば、パスを持つznodeの場合/myapp シーケンシャルznodeとして作成されると、ZooKeeperはパスをに変更します /myapp0000000001次のシーケンス番号を0000000002に設定します。2つの連続するznodeが同時に作成される場合、ZooKeeperは各znodeに同じ番号を使用することはありません。シーケンシャルznodeは、ロックと同期において重要な役割を果たします。

セッション

ZooKeeperの操作には、セッションが非常に重要です。セッション内の要求はFIFO順に実行されます。クライアントがサーバーに接続すると、セッションが確立され、session id クライアントに割り当てられます。

クライアントは送信します heartbeatsセッションを有効に保つために特定の時間間隔で。ZooKeeperアンサンブルは、サービスの開始時に指定された期間（セッションタイムアウト）を超えてクライアントからハートビートを受信しない場合、クライアントが停止したと判断します。

セッションタイムアウトは通常、ミリ秒単位で表されます。何らかの理由でセッションが終了すると、そのセッション中に作成されたエフェメラルznodeも削除されます。

時計

ウォッチは、クライアントがZooKeeperアンサンブルの変更に関する通知を受け取るためのシンプルなメカニズムです。クライアントは、特定のznodeを読み取りながらウォッチを設定できます。ウォッチは、（クライアントが登録する）znodeの変更について、登録されたクライアントに通知を送信します。

Znodeの変更は、znodeに関連付けられたデータの変更、またはznodeの子の変更です。ウォッチは1回だけトリガーされます。クライアントが再度通知を必要とする場合は、別の読み取り操作を介して行う必要があります。接続セッションの有効期限が切れると、クライアントはサーバーから切断され、関連するウォッチも削除されます。