1.Zookeeperプロフィール
制服ネーミングサービス：飼育係は、主のような、多くの場合、分散アプリケーションに遭遇したデータ管理の問題の一部を解決するために使用され、今ではApacheの別々のトップレベルプロジェクトのApache Hadoopののサブプロジェクトにするために使用、分散サービス・フレームワーク、です、状態同期サービス、クラスタ管理、および分散アプリケーションの設定項目の管理。：分散に関する問題は、パートIのブログを参照してください分散システムの問題と解決策
2.設計目標
- ZooKeeperのシンプル。ZooKeeperの分散プロセスは、共有階層的な名前空間を介して相互に調整することができ、名前空間は、標準的なファイルシステムと同様に編成されます。ファイルやディレクトリに類似している（ZooKeeperのビューでは、と呼ばれるのznode）データレジスタによる名前空間。一般的なファイルとは、メモリ内の異なるシステム、ZooKeeperのデータが残って、ZooKeeperのは、高スループットと低遅延数を達成することができることを意味するの貯蔵のために設計されています。
ZooKeeperの機能は、厳格かつ整然とした高性能、高可用性を、含まれています。それは大規模な分散システムで使用することができるZooKeeperのパフォーマンス手段。それが単一障害点にならないことを信頼。あなたは、クライアント上の複雑な同期プリミティブを実装できることを厳密かつ秩序手段。
- ZooKeeperのは、コピーすることができます。分散プロセスのその配位のような、等、のZooKeeper自体は、コレクションと呼ばれるホストのグループに複製することができます。サーバーのZooKeeperサービスは、お互いを理解しなければなりません。彼らは、メモリ内の画像の状態だけでなく、トランザクションログとスナップショット永続ストレージを維持します。限り、ほとんどのサーバーが利用できるよう、ZooKeeperのサービスが利用できるようになります。ZooKeeperのは、単一のクライアント・サーバに接続されています。クライアントがリクエストを送信してTCP接続を維持、応答を取得し、取得のモニタイベントとハートビートを送信します。サーバーのTCP接続が失われた場合、クライアントは他のサーバーに接続します。
- 秩序のZooKeeper。ZooKeeperのZooKeeperのマークが付いたすべての数字は、トランザクションの順序各更新を反映しています。以降の操作は、このような同期プリミティブとして、抽象化のより高いレベルを達成するためにコマンドを使用することができます。
- すぐに飼育係。「読む最初の」ワークロードでは、特に高速です。1：ZooKeeperのアプリケーションでは、数千台のコンピュータ上で、読み出しは、最適なパフォーマンスのために、約10の比率を書くよりも一般的である場合に実行することができます。
詳細は、公式ドキュメントを参照してください。http://zookeeper.apache.org/doc/r3.6.0/zookeeperOver.html
3.飼育係のダウンロードとインストール
3.1をダウンロード
ダウンロード：http://zookeeper.apache.org/releases.html、リンクインターフェイス上でクリックすると、直接、最新のリリース版をダウンロードするかを選択することができます。
3.2自分の習慣へのパスを抽出
3.3コンフィギュレーションを変更します
confディレクトリに、zoo_sample.cfgにzoo.cfgコピー
# 这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每间隔 tickTime 时间就会发送一个心跳，单位毫秒。
tickTime=2000
# 这个配置项是用来配置 Zookeeper Leader接受Follower初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 10个心跳的时间（也就是 tickTime）长度后 Zookeeper Leader还没有收到Follower的返回信息，那么表明这个Follower连接失败。总的时间长度就是 10*2000=20 秒
initLimit=10
# 这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 5*2000=10秒
syncLimit=5
# 顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
dataDir=/FreeofInstallation/apache-zookeeper-3.6.0-bin/data
# 这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
clientPort=2181
#单个客户端与单台服务器之间的连接数的限制，是ip级别的，默认是60，如果设置为0，那么表明不作任何限制。请注意这个限制的使用范围，仅仅是单台客户端机器与单台ZK服务器之间的连接数限制，不是针对指定客户端IP，也不是ZK集群的连接数限制，也不是单台ZK对所有客户端的连接数限制。
#maxClientCnxns=60
#这个参数和下面的参数搭配使用，这个参数指定了需要保留的文件数目。默认是保留3个，也是3.4以后才有的。
#autopurge.snapRetainCount=3
#3.4.0及之后版本，ZK提供了自动清理事务日志和快照文件的功能，这个参数指定了清理频率，单位是小时，需要配置一个1或更大的整数，默认是0，表示不开启自动清理功能。
#autopurge.purgeInterval=1
3.4サービスの開始と停止
飼育係は、binディレクトリにパッケージを抽出し、またはそれはパス環境変数、使いやすい（接尾辞を使用して、Windows環境でスクリプトを.cmdファイル）に追加することができます。
サービス開始
./zkServer.sh start
#启动成功之后会显示如下信息
#Starting zookeeper ... STARTED
ストップサービス
./zkServer.sh stop
#停止服务后打印信息
#Stopping zookeeper ... STOPPED
クライアントを起動します
./zkCli.sh
#连接成功会进入shell终端
#[zk: localhost:2181(CONNECTED) 0]
飼育係を構築する4.スタンドアローンのクラスター
4.1ビルドクラスタ
confディレクトリを入力して、3つのプロファイルをコピーします
cp zoo.cfg zoo-1.cfg
cp zoo.cfg zoo-2.cfg
cp zoo.cfg zoo-3.cfg
データディレクトリを作成します。
mkdir /FreeofInstallation/zookeeper/data-1 -p
mkdir /FreeofInstallation/zookeeper/data-2 -p
mkdir /FreeofInstallation/zookeeper/data-3 -p
ログディレクトリを作成します。
mkdir /FreeofInstallation/zookeeper/log-1 -p
mkdir /FreeofInstallation/zookeeper/log-2 -p
mkdir /FreeofInstallation/zookeeper/log-3 -p
作成MYID
echo "1" > /FreeofInstallation/zookeeper/data-1/myid
echo "1" > /FreeofInstallation/zookeeper/data-2/myid
echo "1" > /FreeofInstallation/zookeeper/data-3/myid
3つの構成ファイルを変更します。動物園-1.cfg、動物園-2.cfg、動物園、3.cfg
tickTime=2000
initLimit=10
syncLimit=5
#数据路径
dataDir=/FreeofInstallation/zookeeper/data-1
#日志路径
dataLogDir=/FreeofInstallation/zookeeper/log-1
clientPort=2181
#server.x中的x要和刚设置的myid文件内容一致；
#前面的端口用于同步数据通信，后面的端口用于选举投票通信
server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
tickTime=2000
initLimit=10
syncLimit=5
#数据路径
dataDir=/FreeofInstallation/zookeeper/data-2
#日志路径
dataLogDir=/FreeofInstallation/zookeeper/log-2
clientPort=2182
#server.x中的x要和刚设置的myid文件内容一致；
#前面的端口用于同步数据通信，后面的端口用于选举投票通信
server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
tickTime=2000
initLimit=10
syncLimit=5
#数据路径
dataDir=/FreeofInstallation/zookeeper/data-3
#日志路径
dataLogDir=/FreeofInstallation/zookeeper/log-3
clientPort=2183
#server.x中的x要和刚设置的myid文件内容一致；
#前面的端口用于同步数据通信，后面的端口用于选举投票通信
server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
クラスタを起動
./zkServer.sh start ../conf/zoo-1.cfg
./zkServer.sh start ../conf/zoo-2.cfg
./zkServer.sh start ../conf/zoo-3.cfg
チェックノードステータス検証（2リーダー、1,3フォロワです）
./zkServer.sh status../conf/zoo-1.cfg
./zkServer.sh status../conf/zoo-2.cfg
./zkServer.sh status../conf/zoo-3.cfg
オブザーバーは、ノード増加
他のステップは同じであるが、コンフィギュレーション・ファイル（動物園-ob.cfg）は多少異なっています
tickTime=2000
initLimit=10
syncLimit=5
#数据路径
dataDir=/FreeofInstallation/zookeeper/data-4
#日志路径
dataLogDir=/FreeofInstallation/zookeeper/log-4
clientPort=2184
#指定是observer节点
peerType=observer
#server.x中的x要和刚设置的myid文件内容一致；
#前面的端口用于同步数据通信，后面的端口用于选举投票通信
server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.4=localhost:2886:3886:observer
同じ直接的な方法は、ノードを起動し、ノードのステータスを表示するには
4.2クラスタの役割
- 飼育係のリーダーは、クライアントの要求と最終的な解決を取り扱い、開始し、意思決定の投票を担当するクラスタのコアです。
- リーダー選挙に参加しながら、非トランザクション処理のクライアント要求をフォロワ、および転送投票事務リーダーサーバに要求。
- オブザーバーは、投票プロセスに参加しないのZooKeeperクラスタおよびオブザーバーでこれらの最新の変更状態状態に同期サーバーを観察しました。基本的には同じ観察者はフォロワーの役割で動作し、それがフォロワーの役割であり、唯一の違いは、観察者がリクエスト投票の選挙と提案の指導者というものを含め、あらゆる種類の投票に参加しないです。簡単に言えば、オブザーバーサーバは非事柄のみのサービス要求、ハンドル物事への非クラスタ化されたトランザクション処理能力に影響を与えることなく、クラスタを増強する能力で、通常は嘘を提供します。
- 学習者と指導者の同期サーバーの状態は、学習者と従動オブザーバーとして、すべての学習者の上に言及しました。
何をする5.飼育係
- サービス（ネームサービス）の命名
作成呼び出すことで、主に分散ネームサービスとしてノードAPI ZKグローバルにユニークなパスを作成することは非常に簡単では、このパスは名前として使用することができます。これらのpahtは、階層構造を持って理解し、管理することは非常に簡単です。 - 構成管理（構成管理）
構成管理は、このような同じアプリケーションを実行するために複数のサーバを必要として、分散アプリケーション環境では非常に一般的ですが、あなたはこれらの同じ設定項目を変更したい場合は、アプリケーション・システムの一部の構成は、同じです、その後、あなたはまた、システムのサーバーを実行する各コンピュータの設定を変更する必要があり、これは非常に面倒でエラーが発生しやすいです。
このような構成情報が飼育係に管理することができ、構成情報は、ノード飼育係に格納され、その後、すべての構成情報が変更されると、マシンステータス情報を監視し、アプリケーションの構成を変更するマシン上の各アプリケーションが必要になります飼育係に通知し、その後、飼育係から新しい構成情報を取得するシステムに適用されます。 - クラスタ管理（グループメンバーシップ）
のZooKeeperクラスタ管理主に二つの点について：クラスタ監視マシンが終了し、選挙のマスターに参加があるかどうか。
最初のポイントでは、過去の練習は通常、次のとおりです。監視システムに各マシンのタイミングや各マシン独自の定期的な報告を検出する（pingなど）何らかの手段による監視システム、「私は生きているんです。」このアプローチは動作しますが、2つの明らかな問題があります：1）は、タイムマシンは、より多くの関与を修飾するものは、クラスタの変更であります。2）一定の遅延。
すべてのマシンが、その後、親ディレクトリ（例えば/ GROUPMEMBERS）で一時ディレクトリノードを作成することに同意した親ディレクトリノード変更メッセージの子ノードをリッスン：使用ZooKeeperのは、それが別のクラスタリアルタイム機械監視システムの存続可能な2つの特徴を持ちます。マシンがハングアップしたら、マシンは飼育係のオフに接続され、それが他のすべてのマシンに通知している、一時的なディレクトリノードが削除されて作成されます。ディレクトリが削除され、マシンがハングアップしているという。新しいマシンが参加することと似ています。
第二の点のために、分散環境では、異なるマシン上に分散同じビジネスアプリケーションは、いくつかのビジネスロジック（例えば、時間のかかる計算、ネットワークI / O処理の数）は、多くの場合のみクラスタ全体を作ります実行マシンは、マシンが大幅に重複を削減し、パフォーマンスを向上させることができ、この結果、の残りの部分を共有することができますので、この選挙は、このシナリオで発生した主な問題のマスターです。・/ currentMasterノード、成功を作成するために、最終的にのみ、特定のクライアント要求を作成するために、複数のクライアント要求があります。ZooKeeperの高い同時実行の下に作成されたノードは、すなわち、グローバル一意性を保証するために、分散、強い整合性を使用しています。この機能を使用して、それが簡単に分散環境でクラスタを選択することができます。 - ロック分散
DLM：一貫性を確保するために、相互に排他的なアクセスを実現するために、分散環境では、クロスプロセス、クロスホストの保護は、ネットワーク経由でリソースを共有することをロック手段を分散。長いユーザーが完全に同じのznodeは、クラスタ（ZKサーバー）内の任意のノードをZK上のすべての時間は、データは必ずしも同じであることを確信してと、私たちは、データの一貫性を確保するためにZooKeeperのが主な原因のロックを分散。
：より詳細な使用シナリオやアイデアは、を参照してくださいZooKeeperのは何のZooKeeper（b）は？
ボーエンに関連するパートIIオペレーション：飼育係のクライアントノードおよび基本操作
