Zookeeper は、マルチレベルのノード名前空間を提供します (ノードは znode と呼ばれます)。ファイルシステムとは異なり、これらのノードは関連するデータを設定できますが、ファイルシステムではファイルノードのみがデータを格納でき、ディレクトリノードはデータを格納できません。 「インタビューコラム」をフォローして、より詳しいインタビュー辛口情報を入手しましょう。
高スループットと低遅延を確保するために、Zookeeper はこのツリー状のディレクトリ構造をメモリ内に維持します。この機能により、Zookeeper が大量のデータを保存するために使用されるのを防ぎます。データ ストレージの上限各ノードのサイズは 1M です。サービスの開始時、またはリーダーがクラッシュした後、Zab はリカバリ モードに入ります。リーダーが選出され、過半数を獲得したとき、サーバーが完了した後、リーダーとのステータス同期が完了すると、リカバリーモードが終了します。状態の同期により、リーダーとサーバーのシステム状態が確実に同じになります。
リーダーがほとんどのフォロワーとステータスを同期すると、メッセージのブロードキャストを開始できます。つまり、ブロードキャスト状態になります。現時点では、サーバーが ZooKeeper サービスに参加すると、サーバーは回復モードで起動し、リーダーを検出し、ステータスをリーダーと同期します。同期が完了するとメッセージブロードキャストにも参加します。 ZooKeeper サービスは、リーダーがクラッシュするか、リーダーがフォロワーのサポートの大部分を失うまで、ブロードキャスト状態のままになります。
#手動で削除しない限り、ノードは常に Zookeeper に存在します
一時ノードのライフ サイクルはクライアント セッションにバインドされています。クライアント セッションが期限切れになると (クライアントと動物園管理者の間の切断が必ずしもセッションの期限切れを意味するわけではありません)、クライアントによって作成されたすべての一時ノードは、削除されました。
基本的な特性は、シーケンスが異なることを除き、永続ノードと同じです。属性がノード名の後に追加されます。親ノードによって維持される自動増加する整数値が追加されます。
基本的な特性は一時ノードと同じですが、シーケンス属性が追加されています。親ノードによって維持されるノード名の後に追加される、自動増加する整数。
Zookeeper を使用すると、クライアントはサーバー上の Znode に Watcher を登録できます。サーバー上の指定されたイベントによって、このウォッチャーがトリガーされます。サーバーは、分散通知機能を実装するために指定されたクライアントにイベント通知を送信し、クライアントはウォッチャーの通知ステータスとイベント タイプに基づいてビジネスを変更します。面接のヒントをさらに得るために、「面接コラム」に注目してください。
動作メカニズム:
(1) クライアントはウォッチャーを登録します
(2) サーバーはウォッチャーをプロセスします
(3) クライアント コールバック ウォッチャー
Watcher 機能の概要:
(1) 1 回限り
サーバーであってもクライアントであっても、Watcher がトリガーされると、Zookeeper は対応するストレージからそれを削除します。この設計により、サーバーへの負荷が効果的に軽減されます。そうでないと、ノードが非常に頻繁に更新される場合、サーバーはイベント通知をクライアントに継続的に送信することになり、ネットワークとサーバーの両方に大きな負荷がかかります。
(2) クライアントのシリアル実行
クライアントの Watcher コールバックの処理はシリアル同期処理です。
(3) 軽量
3.1. ウォッチャー通知は非常にシンプルで、イベントが発生したことをクライアントに通知するだけで、イベントの具体的な内容については説明しません。
3.2. クライアントがサーバーにウォッチャーを登録するとき、クライアントの実際のウォッチャー オブジェクト エンティティはサーバーに渡されず、クライアント リクエスト内のブール型属性でマークされるだけです。
(4) ウォッチャー イベントが非同期で送信される
ウォッチャー通知イベントがサーバーからクライアントに非同期で送信されます。これにより問題が発生します。異なるクライアントとサーバーはソケットを介して通信します。 Zookeeper 自体が順序保証を提供しているため、クライアントはイベントをリッスンするまで監視している znode の変更を認識しません。したがって、Zookeeper を使用する場合、ノードのすべての変更を監視できることは期待できません。 Zookeeper は最終的な整合性のみを保証できますが、強い整合性は保証できません。
(5) ウォッチャーの登録 getData、exists、getChildren
(6) トリガー ウォッチャーの作成、削除、setData
(7) クライアントが新しいサーバーに接続すると、セッション イベントによって監視がトリガーされます。サーバーへの接続が失われると、時計を受信できなくなります。クライアントが再接続すると、必要に応じて、以前に登録されたすべてのウォッチが再登録されます。通常、これは完全に透明です。監視が失われる可能性がある特殊なケースは 1 つだけあります。未作成の znode 上の既存の監視の場合、クライアントが切断されている間に作成され、その後クライアントが接続する前に削除された場合、この監視イベントは失われる可能性があります。
(1) getData()/getChildren() / を呼び出す3 つの API を使用して、Watcher オブジェクトを渡します。
(2) リクエストをマークし、Watcher を WatchRegistration にカプセル化します。
(3) それを Packet オブジェクトにカプセル化し、リクエストを送信します# # サーバーへ
#(4) サーバー応答を受信後、管理用にZKWatcherManagerにWatcherを登録 (5) リクエストが返され、登録が完了します。#(2) ウォッチャー トリガー
setData() トランザクション リクエストを受信するサーバーを例として、NodeDataChanged イベントをトリガーします。
2.1 WatchedEvent のカプセル化
will notification ステータス (SyncConnected)、イベント タイプ (NodeDataChanged)、およびノード パスは WatchedEvent オブジェクトにカプセル化されます
2.2 Watcher のクエリ
WatchTable からのノード パスに基づいて Watcher を検索します
2.3 見つかりません ;クライアントがこのデータ ノードに Watcher
を登録していないことを示します2.4 検索; WatchTable と Watch2Paths から対応する Watcher を抽出して削除します (ここから、Watcher はサーバー側で 1 回限りであり、1 回トリガーされると無効になることがわかります)
(3 ) Watcher をトリガーするための処理メソッドを呼び出します。
ここでの処理は主に、ServerCnxn に対応する TCP 接続を通じて Watcher イベント通知を送信することです。
クライアントの SendThread スレッドがイベント通知を受信し、それを渡しますEventThread スレッド Callback Watcher に送信します。
クライアントのウォッチャー メカニズムも 1 回限りであり、一度トリガーされると、ウォッチャーは無効になります。
(1) IP: IP アドレス粒度による権限制御
(2) ダイジェスト: 最も一般的に使用され、ユーザー名:パスワードのような権限識別子を使用して権限を構成し、さまざまなアプリケーションの区別を容易にします。権限制御
(3) ワールド: 最もオープンな権限制御方法。権限識別子「world:anyone」を 1 つだけ持つ特殊なダイジェスト モードです。
(4) スーパー: スーパー ユーザー
認可オブジェクトは、IP アドレスやマシンなど、権限が付与されるユーザーまたは指定されたエンティティを指します。ライト。
(1) CREATE: データノード作成権限。承認されたオブジェクトが Znode
の下にサブノードを作成できるようにします。 ( 2) DELETE: 子ノードの削除権限。許可されたオブジェクトがデータ ノードの子ノードを削除できるようにします。
(3) READ: データ ノードの読み取り権限。許可されたオブジェクトがデータ ノードにアクセスできるようにします。そのデータ内容や子ノードのリストなどを読み取ります。
(4) WRITE: データ ノードの更新権限。承認されたオブジェクトがデータ ノードを更新できるようにします。
(5) ADMIN: データノード管理権限、承認されたオブジェクトを許可する データ ノードで ACL 関連の設定操作を実行します
です。
リーダー
(1) 独自のスケジューリングと処理クラスタのトランザクション処理の順序を確保するため
(2) クラスタ内の各サービスのスケジューラ
フォロワー
(1) クライアントの非トランザクションを処理するトランザクションのリクエストと転送 リーダーサーバーへのリクエスト
#(2) トランザクションリクエストの提案投票に参加#(3) リーダー選挙の投票に参加
#オブザーバー(1) バージョン 3.0 サーバーの役割は、クラスターのトランザクション処理機能に影響を与えることなく、クラスターの非トランザクション処理機能を向上させるために後で導入されます。(2) クライアントの非トランザクション要求を処理し、リーダー サーバーへのトランザクション リクエスト(3) いかなる形式の投票にも参加しない ##14. Zookeeper でのサーバーの動作ステータスクラスター全体がリーダーの選出を完了すると、学習者 (フォロワーとオブザーバーの総称) がリーダー サーバーに再登録されます。学習者サーバーは、リーダー サーバーへの登録を完了すると、データ同期フェーズに入ります。
データ同期プロセス: (すべてメッセージングによって実行されます)
学習者がリーダーに登録
データ同期
同期確認
Zookeeper のデータ同期は通常、次の 4 つのカテゴリに分類されます。
(1) 直接差分同期 (DIFF 同期)
(2) 最初にロールバックしてから差分同期 (TRUNC DIFF 同期)
(3) ロールバック同期のみ (TRUNC 同期)
(4) 完全同期 (SNAP 同期)
データ同期の前に、リーダー サーバーはデータ同期の初期化を完了します。
peerLastZxid:
minCommittedLog:
ZXID ロールバック同期のみ (TRUNC 同期)
完全同期 (SNAP 同期)
zookeeper は、グローバルに増分されるトランザクション ID を使用して識別します。すべての提案には、提案されるときに zxid が追加されます。zxid は実際には 64 ビットです。番号、上位32ビットはリーダーサイクルを識別するためのエポック(ピリオド、エポック、世紀、新時代)で、新しいリーダーが生成されると自動的にエポックが増加し、下位32ビットはカウントアップに使用されます。新しいプロポーザルが生成されると、まずデータベースの2段階のプロセスに基づいて他のサーバーにトランザクションの実行要求を発行し、半数以上のマシンが実行して成功すると実行が開始されます。
分散環境では、一部のビジネス ロジックはクラスター内の特定のマシンでのみ実行する必要があり、他のマシンが結果を共有できるため、繰り返しの計算が大幅に削減されます。 . パフォーマンスが向上するため、リーダーの選出が必要です。
Zookeeper 自体もクラスターなので、3 つ以上のサーバーを構成することをお勧めします。 Zookeeper 自体も、1 つのノードがダウンしても他のノードがサービスを提供し続けることを保証する必要があります。
フォロワーがダウンしても、アクセスを提供するサーバーはまだ 2 つあります。Zookeeper 上のデータには複数のコピーがあるため、データは失われません。
リーダーがマシンにダウンした場合、Zookeeper新しいリーダーを選出します。
ZK クラスタの仕組みは、半分以上のノードが正常であれば、クラスタは正常にサービスを提供できます。クラスターが失敗するのは、ZK ノードが多すぎて、半分または半分未満のノードしか機能しない場合に限られます。 ＃＃＃＃＃＃それで＃＃＃
3 ノードのクラスターは 1 つのノードを強制終了できます (リーダーは 2 票を獲得できます > 1.5)
2 ノードのクラスターはどのノードも強制終了できません (リーダーは 1 票を獲得できます
zk のロード バランシングは制御できますが、nginx は制御できます。重みの調整のみで、その他制御が必要な部分は自分で記述する必要がありますが、nginx のスループットは zk よりもはるかに優れており、業務に応じてどちらの方法を使用するかを選択する必要があると言えます。 。
Zookeeper には 3 つの展開モードがあります:
クラスタ ルールは 2N 1 ユニット、N>0、つまり 3 ユニットです。サーバーの半分以上がダウンしていない限り、奇数番号のサーバーを引き続き使用できます。
実は水平展開なのですが、Zookeeperはこの点があまり得意ではありません。 2 つの方法:
#すべて再起動: すべての Zookeeper サービスをシャットダウンし、構成を変更してから開始します。以前のクライアント セッションには影響しません。
1 台ずつ再起動する: マシンの半分以上が稼働しており利用可能であるという原則に基づいて、1 台のマシンを再起動してもクラスタ全体の外部サービスには影響しません。これはより一般的に使用される方法です。
#3.5 バージョンでは、動的拡張のサポートが開始されます。
#24. Zookeeper の Java クライアントとは何ですか?
同じ点:
(1) どちらもリーダー プロセスと同様の役割を持ち、複数のフォロワー プロセスの実行を調整する責任があります
(2) リーダー プロセスは、プロポーザルを送信する前に、フォロワーの半数以上が正しいフィードバックを提供するのを待ちます。
(3) ZAB プロトコルでは、各プロポーザルには、エポック値が含まれています。現在のリーダー サイクル。Paxos での名前は Ballot
です。違い:
ZAB は、高可用性の分散データ マスターおよびバックアップ システム (Zookeeper) を構築するために使用されます。Paxos は、分散型一貫性のあるステート マシン システム。
Zookeeper は、分散データの典型的なパブリッシュ/サブスクライブ モデルです。開発者が分散データを公開およびサブスクライブするために使用できる調整フレームワーク。
Zookeeper の豊富なデータ ノードを相互利用し、Watcher イベント通知メカニズムと連携することにより、分散アプリケーションに関与する次のような一連のコア機能を構築するのに非常に便利です。
(1) データ公開・サブスクリプション#(2) ロードバランシング
#(3) ネーミングサービス#(4) 分散連携・通知
( 5) クラスタ管理
(6)マスター選出
(7)分散ロック
(8)分散キュー
クラスター管理: ノードの生存ステータス、実行中のリクエストなどを監視します;
マスター ノードの選択: マスター ノードがハングアップした後、バックアップ ノードからの新しいもの マスター選出の 1 ラウンド、マスター ノード選出はこの選出プロセスに関するもので、Zookeeper を使用すると、このプロセスの完了を支援できます;
分散ロック: Zookeeper は、排他ロックとロックの 2 種類のロックを提供します。共有ロック。排他ロックは、一度に 1 つのスレッドだけがリソースを使用できることを意味します。共有ロックは、読み取りロックが共有され、読み取りと書き込みが相互に排他的であること、つまり、複数のスレッドが同じリソースを同時に読み取ることができることを意味します。書き込みロックが使用されている場合、それを使用できるのは 1 つのスレッドだけです。 Zookeeper は分散ロックを制御できます。
ネーミング サービス: 分散システムでは、ネーミング サービスを使用することにより、クライアント アプリケーションは、指定された名前に基づいてリソースまたはサービスのアドレス、プロバイダー、およびその他の情報を取得できます。
クライアントは、特定の znode のウォッチャー イベントを作成します。znode が変更されると、これらのクライアントは zk 通知を受け取り、クライアントは znode の変更に基づいて応答できます。 . 業務変更などを行う。
注意這裡的dubbo只是一個框架，至於你架子上放什麼是完全取決於你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成調度必須要有一個分散式的註冊中心，儲存所有服務的元數據，你可以用zk，也可以用別的，只是大家都用zk。
Dubbo 的將註冊中心進行抽象，它可以外接不同的儲存媒介給註冊中心提供服務，有ZooKeeper，Memcached，Redis 等。
引進了 ZooKeeper 作為儲存媒介，也就把 ZooKeeper 的特性引進來。首先是負載平衡，單註冊中心的承載能力是有限的，在流量達到一定程度的時候就需要分流，負載平衡就是為了分流而存在的，一個ZooKeeper 群配合相應的Web 應用就可以很容易達到負載平衡；資源同步，單單有負載平衡還不夠，節點之間的資料和資源需要同步，ZooKeeper 叢集就天然具備有這樣的功能；命名服務，將樹狀結構用於維護全域的服務地址列表，服務提供者在啟動的時候，向ZooKeeper 上的指定節點/dubbo/${serviceName}/providers 目錄下寫入自己的URL 位址，這個操作就完成了服務的發佈。其他特色還有 Mast 選舉，分散式鎖等。
以上が【おすすめ作品集】魂責め！動物園飼育員の 31 発の大砲の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
