Xiaobaiスタートガイド| Zookeeperクイックスタート

Zookeeperの使用を開始する

概要概要

分散アプリケーション用のオープンソースの分散型Apacheプロジェクト

動作メカニズム

Zookeeperは、設計パターンの観点から理解します。これは、オブザーバーパターンに基づいて設計された分散サービス管理フレームワークです。ストレージの管理と、誰もが気にするデータの管理を担当し、オブザーバーの登録を受け入れます。データの変更、zookeeperは、zookeeperに登録したオブザーバーに対応するよう通知する責任があります

特性

  • グローバルデータの整合性
  • 信頼性
  • 一連の
  • データ更新の原子性
  • リアルタイム

Zookeeperの役割

  • 盟主

Zookeeperクラスターのコアは、
トランザクション要求(書き込み操作)の唯一のスケジューラーおよびプロセッサーであり、
クラスター内のトランザクションのシーケンス、つまりクラスター内の各サーバーのスケジューラーを保証します。
create、setData、delete、およびその他の書き込み要求の場合、処理のためにリーダーに転送する必要があります。リーダーは番号を判別して操作を実行する必要があります。このプロセスはトランザクションと呼ばれます。

  • フォロワー

クライアントの非トランザクション要求を処理し、トランザクション要求をリーダーに転送
します。クラスターリーダーの選出に参加します。

  • 観察者

オブザーバーの役割、zookeeperクラスターの最新の状態変化を観察し、これらの状態を同期します。非トランザクションリクエストを個別に処理し、トランザクションリクエストをリーダーに転送して処理できます。
投票には参加せず、提供するだけです。非トランザクションサービス。

Zookeeperクラスターの構築

ビルド手順

  • ホスト名からIPアドレスへのマッピングを構成する
  • zookeeper構成ファイルを変更します
  • インストールファイルをリモートでコピーして配布する
  • myidを設定する
  • Zookeeperクラスターを開始します

ビルドプロセス

1. zookeeper wgethttp://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.13/zookeeper-3.4.13.tar.gzをダウンロードします。2。tarの
下の/ usr / local / srcに解凍します- xvzf飼育係-3.4.13.tar.gz
3.改名MV飼育係-3.4.13飼育係
4. confディレクトリに入ります
zoo_sample.cfgの5コピー3つのコピーをし、それらを名前としてzoo_1.cfg zoo_2.cfg zoo_3.cfg
6 。変更zoo_1.cfgの内容は次のとおりです

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/data/zk1/data
clientPort=2181
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

7.zoo_2.cfgの内容を次のように変更します

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/data/zk1/data
clientPort=2182
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

8.zoo_3.cfgの内容を次のように変更します

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/usr/local/data/zk1/data
clientPort=2183
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

9.コマンドを実行して、フォルダーとmyidを作成します

mkdir -p /usr/local/data/zk1/data
mkdir -p /usr/local/data/zk2/data
mkdir -p /usr/local/data/zk3/data
echo "1" > /usr/local/data/zk1/data/myid
echo "2" > /usr/local/data/zk2/data/myid
echo "3" > /usr/local/data/zk3/data/myid

10. binディレクトリで次のコマンドを実行して、zookeepeクラスターを開始します

zkServer status ../conf/zoo_1.cfg
zkServer status ../conf/zoo_2.cfg
zkServer status ../conf/zoo_3.cfg

11. binディレクトリで次のコマンドを実行して、各ノードのステータスを表示します

zkServer.sh status ../conf/zoo_1.cfg
zkServer.sh status ../conf/zoo_2.cfg
zkServer.sh status ../conf/zoo_3.cfg

zookeeperデータモデル

  • Znodeにはファイル機能とディレクトリ機能の両方があります
  •   即像文件一样维护着数据又像目录一样可作为路径标识的一部分
    
  • Znodeにはアトミック操作があります
  • Znodeストレージにはkbレベルの制限があります
  • Znodeはパスによって参照され、パスは絶対パスである必要があります
  • Znoe構成
    1. Znodeのバージョンと許可情報を説明する統計ステータス情報
    2. dataZnodeに関連付けられたデータ
    3. 子Znodeの下の子ノード
  • ノードタイプ
    1. 一時ノードのセッションが終了し、一時ノードが自動的に削除され、一時ノードに子ノードを含めることはできません。
    2. 永続ノードは手動で削除しない限り消え、一時ノードに変更することはできません
    3. ノードをシリアル化
  • ノード属性
    1. dataversionは、各セットの後にdataversionを変更します
    2. cversionの子ノードが変更された後、Cversionが更新されます
    3. Znodeによって作成されたczxidトランザクションID
    4. mzxid変更されたトランザクションID
    5. ctimeノードの作成時間
    6. mtimeノードの更新時間
    7. ephemeralOwnerノードが一時ノードの場合、値はノードにバインドされているセッションIDを識別し、そうでない場合は0です。

zookeeperコマンド

  • 接続を作成する
zkCli.sh -p host:port
  • ノードを作成します
create [-e] [-s] path acl
-e 创建临时节点 -s 创建序列化节点
  • ノードを削除します
delete path
不能删除有子节点的节点,除非子节点内容为空
  • ノードを再帰的に削除します
rmr path
  • ノード制限
setquota -n | -b val path
n 标识子节点个数 -b 表示数据大小
listquota 查看设置信息
delquota -n | -b path 删除设置信息
  • 履歴コマンド
history 查看历史命令
redo num 重新执行某条命令   

Zookeeper Watcher

Zookeeperは、分散データのパブリッシュ/サブスクライブ機能を提供します。Zookeeperは、この分散通知機能を実現するためのウォッチャーメカニズムを導入します。Zookeeperを使用すると、クライアントはウォッチャーをサーバーに登録できます。サーバー上の一部のイベントがウォッチャーをトリガーすると、クライアントに送信を要求します。通知。
トリガーイベントのタイプ:ノードの削除、ノードの変更、子ノードの変更など。
一般に、ウォッチャーは次の3つのプロセスに要約されます。クライアントはウォッチャーをサーバーに登録し、サーバーイベントはウォッチャーをトリガーし、クライアントはウォッチャーをコールバックしてトリガーイベントのコンテンツを取得します。

トリガーメカニズムの特性

  • ワンタイムトリガー
  • イベントのカプセル化
  •   传递watchedevent,包括通知状态,事件类型,节点路径。
    
  • 非同期イベント送信
  • 最初に登録してからトリガーします

シェルオペレーションウォッチャー

help 查看所有命令,后面带有watcher的都可以实现监听

	stat path [watch]
	ls path [watch]
	ls2 path [watch]
	get path [watch]

Zookeeper java api

  • 依存関係を導入する
    <dependency>
      <groupId>org.apache.zookeeper</groupId>
      <artifactId>zookeeper</artifactId>
      <version>3.4.14</version>
    </dependency>
  • サンプルコード
    public static void main(String[] args) throws Exception{
        ZooKeeper zooKeeper = new ZooKeeper("192.168.195.100:2181,192.168.195.100:2182", 30000, new Watcher() {
            @Override
            public void process(WatchedEvent watchedEvent) {
                System.out.println("回调通知");
                System.out.println(watchedEvent.getPath());
                System.out.println(watchedEvent.getState());
                System.out.println(watchedEvent.getType());
            }
        });
//        zooKeeper.create("/magicbook","充满魔力的book".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT_SEQUENTIAL);
        zooKeeper.getData("/magicbook0000000007",true,null);
        zooKeeper.setData("/magicbook0000000007","少时诵诗书".getBytes(),-1);
        zooKeeper.delete("/magicbook0000000007",-1);
        //        zooKeeper.close();
    }

Zookeeperの選出メカニズム

動物園の飼育係のデフォルトの選挙アルゴリズムはfastleaderelectionであり、投票の半分以上を使用して勝ちます

概念

  • サーバーID
  •   id越大,在选举算法中权重越大
    
  • 選挙状況
    1. キャンペーンステータスLOCKING
    2. フォロワーステータスFOLOWINGリーダーステータスを同期して投票に参加します
    3. 監視ステータスOBSERVER同期リーダーステータスは投票に参加しません
    4. リーダーのステータス
  • データID
    サーバーに保存されている最新のデータのバージョンが大きいほど、データは新しくなります。

新しいクラスター選挙

  • すべてのマシンが自分自身に投票しますLOCKING
  • サーバーの大きなIDが小さなIDの投票に勝つことができます
  • 投票の半分以上が終わった
  • 現時点で、より大きなサーバーIDが選出される場合は、申し訳ありません。投票は終わりました

新しいクラスターではない

正常に実行されている飼育係クラスターの場合、途中でマシンのダウンタイムが発生し、選出を再選出する必要があります。データID、サーバーID、および論理クロックを選出プロセスに追加する必要があります。

  • データID:データの新しいバージョンはより大きく、データは毎回バージョンを更新します
  • サーバーID:構成したmyidです
  • この値は0から始まり、各選択は値に対応します。同じ選択の場合、これは同じです。
  • 選挙のプロセス
    1.論理クロックは無視され、投票が再投票されます。
    2.論理クロックを統合した後、データIDが優先されます。
    3.同じデータIDの場合、IDが大きいサーバーが優先されます。
    4.最後にリーダーを選択します

典型的なアプリケーション

データの公開とサブスクリプション

ノード変更イベントを繰り返し監視し、ウォッチャーを使用して監視し、データの公開とサブスクリプションを実現します

分散ロック

1.各クライアントは一時的に順序付けられたノードを作成します
。2。クライアントはノードリストを取得し、それがリストの最初のノードであるかどうかを判断します。リストの最初のノードである場合はロックを取得します。そうでない場合はロックを取得します。前のノードを監視し、前のノードが削除されるのを待ちます。
3.ロックが取得されると、通常のビジネスプロセスが実行され、実行後にロックが解放されます。
上記のステップ2で、ノードが最小のシーケンスを持つノードではないことを検出した場合、リスナーを追加する準備ができているが、この時点で前のノードが削除されているのではないかと心配する人もいるかもしれません。今回は機能しません。実際、zk APIは、リスナーの読み取りと追加がアトミック操作であることを保証できます。
すべてのノードではなく、前のノードをリッスンするのはなぜですか?これは、すべての子ノードを監視すると、子ノードのステータスが変化し、他のすべての子ノードが通知を受信し(群集効果)、次の子ノードのみが通知を受信するようにするためです。

おすすめ

転載: blog.csdn.net/weixin_34311210/article/details/106109440