Zookeeper-fundamentals
Zookeeper-基礎
ZooKeeperの動作について詳しく説明する前に、ZooKeeperの基本的な概念を見てみましょう。 この章では、次のトピックについて説明します-
- 建築
- 階層的な名前空間
- セッション
- 時計
ZooKeeperのアーキテクチャ
次の図をご覧ください。 ZooKeeperの「クライアントサーバーアーキテクチャ」を示しています。
ZooKeeperアーキテクチャの一部である各コンポーネントについて、次の表で説明しました。
| Part | Description |
|---|---|
| Client |
Clients, one of the nodes in our distributed application cluster, access information from the server. For a particular time interval, every client sends a message to the server to let the sever know that the client is alive. 同様に、サーバーはクライアントが接続すると確認応答を送信します。 接続されたサーバーから応答がない場合、クライアントはメッセージを別のサーバーに自動的にリダイレクトします。 |
| Server | Server, one of the nodes in our ZooKeeper ensemble, provides all the services to clients. Gives acknowledgement to client to inform that the server is alive. |
| Ensemble | Group of ZooKeeper servers. The minimum number of nodes that is required to form an ensemble is 3. |
| Leader | Server node which performs automatic recovery if any of the connected node failed. Leaders are elected on service startup. |
| Follower | Server node which follows leader instruction. |
階層的な名前空間
次の図は、メモリ表示に使用されるZooKeeperファイルシステムのツリー構造を示しています。 ZooKeeperノードは znode と呼ばれます。 すべてのznodeは名前で識別され、一連のパス（/）で区切られます。
- この図では、最初に「/」で区切られたルート znode があります。 ルートの下には、2つの論理名前空間 config および workers があります。
- config 名前空間は集中構成管理に使用され、 workers 名前空間は命名に使用されます。
- config 名前空間では、各znodeは最大1MBのデータを保存できます。 これは、親znodeにもデータを保存できることを除いて、UNIXファイルシステムに似ています。 この構造の主な目的は、同期されたデータを保存し、znodeのメタデータを記述することです。 この構造は、 ZooKeeper Data Model と呼ばれます。
ZooKeeperデータモデルのすべてのznodeは、 stat 構造を維持します。 statは、znodeの*メタデータ*を単に提供します。 _バージョン番号、アクション制御リスト（ACL）、タイムスタンプ、およびデータ長で構成されます。
- バージョン番号-すべてのznodeにはバージョン番号があります。つまり、znodeに関連付けられたデータが変更されるたびに、対応するバージョン番号も増加します。 複数のzookeeperクライアントが同じznodeで操作を実行しようとする場合、バージョン番号の使用は重要です。
- アクション制御リスト（ACL）-ACLは基本的にznodeにアクセスするための認証メカニズムです。 すべてのznodeの読み取りおよび書き込み操作を管理します。
- Timestamp -タイムスタンプは、znodeの作成および変更からの経過時間を表します。 通常はミリ秒単位で表されます。 ZooKeeperは、「トランザクションID」（zxid）からznodeへのすべての変更を識別します。 Zxid は一意であり、各トランザクションの時間を保持するため、あるリクエストから別のリクエストまでの経過時間を簡単に識別できます。
- データ長-znodeに保存されるデータの総量はデータ長です。 最大1MBのデータを保存できます。
Znodeのタイプ
Znodeは、持続、シーケンシャル、およびエフェメラルに分類されます。
- Persistence znode -永続性znodeは、その特定のznodeを作成したクライアントが切断された後でも生きています。 デフォルトでは、特に指定がない限り、すべてのznodeは永続的です。
- *エフェメラルznode *-エフェメラルznodeは、クライアントが動作するまでアクティブです。 クライアントがZooKeeperアンサンブルから切断されると、一時的なznodeは自動的に削除されます。 このため、短命のznodeのみがそれ以上子を持つことはできません。 一時的なznodeが削除されると、次の適切なノードがその位置を埋めます。 一時的なznodeは、リーダー選挙で重要な役割を果たします。
- シーケンシャルznode *-シーケンシャルznodeは永続的または一時的のいずれかです。 新しいznodeがシーケンシャルznodeとして作成されると、ZooKeeperは元の名前に10桁のシーケンス番号を付加してznodeのパスを設定します。 たとえば、パス */myapp を持つznodeがシーケンシャルznodeとして作成された場合、ZooKeeperはパスを /myapp0000000001 に変更し、次のシーケンス番号を0000000002に設定します。 2つの順次znodeが同時に作成される場合、ZooKeeperは各znodeに同じ番号を使用しません。 順次znodeは、ロックと同期で重要な役割を果たします。
セッション
セッションは、ZooKeeperの操作にとって非常に重要です。 セッション内のリクエストは、FIFO順で実行されます。 クライアントがサーバーに接続すると、セッションが確立され、 session id がクライアントに割り当てられます。
クライアントは、特定の時間間隔で*ハートビート*を送信して、セッションを有効に保ちます。 ZooKeeperアンサンブルが、サービスの開始時に指定された期間（セッションタイムアウト）を超えてクライアントからハートビートを受信しない場合、クライアントが死んだと判断します。
通常、セッションタイムアウトはミリ秒単位で表されます。 何らかの理由でセッションが終了すると、そのセッション中に作成された一時znodeも削除されます。
時計
ウォッチは、クライアントがZooKeeperアンサンブルの変更に関する通知を取得するためのシンプルなメカニズムです。 クライアントは、特定のznodeの読み取り中に監視を設定できます。 ウォッチは、znode（クライアントが登録する）の変更について登録されたクライアントに通知を送信します。
Znodeの変更は、znodeに関連付けられたデータの変更、またはznodeの子の変更です。 ウォッチは一度だけトリガーされます。 クライアントが通知を再度必要とする場合は、別の読み取り操作で行う必要があります。 接続セッションの有効期限が切れると、クライアントはサーバーから切断され、関連するウォッチも削除されます。
