Zookeeper基础知识-01

目录

一、Zookeeper概念

二、Zookeeper的数据模型

三、Zookeeper安装与部署

四、Zookeeper的常见客户端shell

五、Zookeeper的acl（access control list）权限控制

六、Zookeeper的zab协议

七、Zookeeper的leader选举（面试重点）

八、Zookeeper的observer角色及其配置

九、zookeeper的图形化管理工具Zoolnspector（windows）

十、zookeeper的图形化监控管理工具taokeeper（linux系统）

十一、zookeeper脚本编写

面试真题：

---

一、Zookeeper概念

        1、Zookeeper字面意思为动物园管理员，它用于管理大数据生态系统各组件如Hadoop（大象），Hive（蜜蜂）...，简称zk。Zookeeper是一个经典的分布式数据一致性解决方案，致力于为分布式应用提供一个高性能，高可用，且具有严格顺序访问控制能力的分布式协调存储服务。

        2、Zookeeper提供的主要功能包括（应用场景）：

                配置管理（配置中心搭建）

                分布式锁

                集群管理

        配置管理：假设现在存在51台服务器（01号,...,51号），51号服务器有MySQL数据库，现要求其余50台服务器都要连接51号服务器的MySQL数据库，那么每台服务器上都会有相应的连接MySQL的配置文件，共50份配置文件（由于连接的MySQL为同一个，50份配置文件都一样）。显然很有可能51号服务器在未来某些信息会变更，例如MySQL的登录密码或需要连接52号服务器的MySQL了，那么其余服务器想要再次连接到MySQL需要修改50份配置文件，这很麻烦，而且在修改的过程中很有可能会出现错误导致配置信息不一致。因此需要构建一个配置中心存放公有的配置信息，这样在每台服务器上就不用写这些配置信息了，用的时候去配置中心取即可，而且需要更改配置文件时，只需要修改配置中心的1份文件即可，很方便大大减少开销，Zookeeper提供了配置中心的功能。有了配置中心可以实现配置服务的高可用以及各台服务器上配置数据的一致性。

        Zookeeper提供了监听机制watch，一旦配置中心的信息被更改，Zookeeper通过watch机制通知每一台服务器，便于服务器主动的去配置中心拉取最新的配置信息。

        分布式锁：避免同一时刻多台服务器对用一数据进行操作，而导致的数据不一致。假设同一时刻01服务器对MySQL中的test表进行查询操作，02对test表进行修改操作，03对test表进行删除操作，如果允许它们同时进行，那就乱套了。因此需要构建一个分布式锁，当01访问test表时首先向分布式锁申请访问权限，分布式锁看到目前test表没有人操作则允许01访问test表，并对test表上锁，同一时刻当02想对test表修改时首先向分布式锁申请权限，此时分布式锁发现test表正在被01所访问，且01并没有释放锁，因此不允许02访问，同理03申请也不允许，02、03需要等待01操作完才可访问test，保证了数据的一致性。

         集群管理：由于在分布式架构下，服务越来越多，服务之间的依赖关系越来越复杂，且对服务的调用也逐步扩大，服务提供方单靠人工来管理和维护这些服务以及捋清楚服务之间的依赖关系变得十分困难，会给服务提供方带来巨大的负荷。因此注册中心就产生了，有了注册中心后，每当服务启动时，服务提供方将服务的相关信息（服务名称，服务器地址）注册到注册中心，由注册中心统一管理和维护这些服务，然后通过watch机制通知服务消费方（服务列表），服务消费方通过注册中心来订阅服务的服务器地址，这样可以使得服务消费方与服务提供方之间达到解耦，大大缓解服务提供方的压力的同时，还能实现服务的统一管理。当服务器宕机或下线时，相应的信息需要在注册中心移除，watch机制可以监听到信息的变更并通知服务消费方，这样服务消费方可以减少调用失效服务的错误。服务消费方在第一次调用服务时，将服务列表缓存在本地，后面调用直接在本地获取，直到注册中心服务列表发生变更被watch机制监听到，主动通知服务消费方让其重新访问注册中心，更新服务列表信息。Zookeeper提供了注册中心的功能。

       zookeeper = 文件系统+通知机制

        3、Zookeeper的设计目标

        高性能：Zookeeper数据的存储直接存储到内存中。因此服务器访问各种配置信息，服务信息会很快。

        高可用：在生产环境中Zookeeper与Hadoop一样是分布式部署的，会存在一个Zookeeper集群。

        严格顺序访问：客户端对Zookeeper的每一次请求，Zookeeper都会生成一个唯一的事务编号，它会严格按照编号的顺序来执行。

二、Zookeeper的数据模型

        Zookeeper与Linux文件系统类似，都是树形结构，树中的各节点被称为znode（zookeeper node）。想要描述一个znode有3个部分：节点的数据（znode date，节点路径与节点数据类似于k-v关系，节点数据不易过大默认<1MB）、节点的子节点、节点的状态stat也称元数据（用来描述当前节点的创建，修改等相关信息）

        在配置好Zookeeper，并打开Zookeeper后可以利用get命令获取相应节点的元数据 

        get 路径   ：  获取该节点的元数据（新版本get -s）

        在Zookeeper中，对节点数据的一系列写操作（节点的创建，节点数据的修改删除），都会导致Zookeeper自动开启一个事务，并维护一个事务ID。读取操作不会创建事务。Zookeeper中的数据节点与Linux中文件夹一样，都会有一个权限列表（dr_xr_xr_x）,aclVersion表示当前节点权限列表被修改的次数。

        Zookeeper中的数据节点有两类：临时节点与持久化节点，临时节点只在当前会话里有效，退出Session临时节点会被删除。

三、Zookeeper安装与部署

        同样Zookeeper的安装依赖jdk环境，这里使用jdk-8u131-linux-x64.tar.gz与zookeeper-3.4.10.tar.gz。

        在node11，22，33上执行：

        useradd zookeeper

        passwd zookeeper   # 密码也是123456

        # jdk

        tar -xzvf jdk-8u131-linux-x64.tar.gz -C /export/server/

        ln -s /export/server/jdk1.8.0_131 /export/server/jdk

        vim /etc/profile

        export JAVA_HOME=/export/server/jdk

        export PATH=$PATH:$JAVA_HOME/bin

        source /etc/profile

        rm -f /usr/bin/java

        ln -s /export/server/jdk/bin/java /usr/bin/java

        java -version

        javac -version

        # 除了jdk之外请确保主机名映射，SSH，关闭防火墙selinux等前置工作以完成。

        # zookeeper

        在node11上执行

        tar -zxvf zookeeper-3.4.10.tar.gz -C /export/server/

        ln -s /export/server/zookeeper-3.4.10 /export/server/zookeeper

        vim /export/server/zookeeper/conf/zoo.cfg

                tickTime=2000         # 通信心跳时间2s，及客户端与服务器端或服务器端与服务器端每

                                                  2s通信一次。客户端与服务器端会话超时时间为2*tickTime=4s

                dataDir=/export/server/zookeeper/data

                clientPort=2181

                initLimit=5               # 开启zk集群leader与follower首次建立连接时间最多5个

                                                 tickTime=10s

                syncLimit=2            # leader与follower首次建立连接后，后续通信时限为4s

                server.1=node11:2888:3888   # server.服务器的myid=ip:zookeeper集群通信的端

                                                                  口:leader选举端口

                server.2=node22:2888:3888

                server.3=node33:2888:3888

        mkdir /export/server/zookeeper/data

        vim /export/server/zookeeper/data/myid

                1

        cd /export/server

        scp -r zookeeper-3.4.10 node22:`pwd`/

        scp -r zookeeper-3.4.10 node33:`pwd`/

        在node22，33上执行

        ln -s /export/server/zookeeper-3.4.10 /export/server/zookeeper

        vim /export/server/zookeeper/data/myid

                2/3

        在node11，22，33上启动zookeeper服务器（提前配置好环境变量vim /etc/profile，root用户下配置软件，zookeeper用户下启动）

        chown -R zookeeper:zookeeper /export

        su - zookeeper

        zkServer.sh start

        jps   # 出现QuorumPeerMain进程即可

        jps -l   # 不仅显示进程名与端口号还会显示更多信息

        在node11上执行：

        zkCli.sh

        ls /     # 看到zookeeper目录说明成功配置好zookeeper，并成功登录到zookeeper客户端

        quit

        至此zookeeper安装完成

四、Zookeeper的常见客户端shell

        help                                         # 查看支持的命令

        # 新增节点

        create  [-s]  [-e]  path  data   # -s 为有序节点，-e为临时节点

        create /hadoop "123456"        # 创建持久化节点并写入数据,可以不加“”

        # 创建持久化有序节点，此时创建的节点名为指定节点名+自增序号，用于生成分布式唯一ID

        create -s /a "aaa"

        create -s /b "bbb"

        create -s /c "ccc"

        create -e /tmp "tmp"                # 创建临时节点，在会话结束后被删除

        # 创建临时有序节点，主要用于分布式锁

        create -s -e /aa "aaa"

        create -s -e /bb "bbb"

        create -s -e /cc "ccc"

        # 查看节点的数据

        get 路径    # 可直接查看节点的数据与元数据，在新版本中get 路径只获取数据，get -s 路径

                         获取数据+元数据

        stat 路径   # 只能查看节点的元数据

        # 查看节点的子节点

        ls 路径

        ls2 路径    # 是ls命令的扩展，不仅可以查看指定路径下的所有子节点，而且可以查看当前节

点的元数据，ls2在新版本中被替换为 ls -s 路径

        # 更新节点

        用法一：set   节点路径   新数据

        set /hadoop "345"

        用法二：set  节点路径   新数据   dataVersion（新版本中无效）

        set /hadoop "45" 1   # 这里输入的节点版本号必须与当前版本号一致才可修改

        新版本中变更为：set  [-v version]  节点路径   新数据

        # 删除节点

        delete path [dataVersion]     # 只能删除没有子节点的节点，新版本为：

        delete [-v version] path

        rmr path                               # 删除该节点及其所有子节点，新版本为deleteall path

        # 监听器get path [watch]

        加入watch选项，相当于在zookeeper的客户端与服务器端注册一个监听器，通过监听器可以监听指定节点的数据变化，当节点数据发生变化时zookeeper会及时给客户端进行反馈。watch是一次性的，触发一次后立即失效。

        在node22上开启监听/hadoop

         在node11上修改/hadoop的数据

         在node22上可以看到已经监听到数据比变化了：

        正是这种监听机制使得zookeeper可以作为配置中心，一但监听器监听到配置文件发生了变化，会及时提醒客户端，以便客户端及时读取最新配置信息。

        在node22上开启/hadoop监听

         在node11上创建/hadoop/node1                

         node22上没有反馈。

        # 监听器stat path [watch]       同get监听器一样

        节点被删除也可以监听到，type为NodeDeleted

        # 监听器ls|ls2 path [watch]

        通过ls|ls2注册的监听器可以监听该节点下所有子节点的增加与删除操作，该节点本身数据的变化监听不到。上述所有的watch新版本中由-w选项替换：命令 -w path

        # 初始化zookeeper

        只需要删除/export/server/zookeeper/data/目录下除myid文件之外的所有文件即可。

五、Zookeeper的acl（access control list）权限控制

        前面我们在client上可以创建节点，更新节点，删除节点，那么如何做到节点的权限控制呢。

        acl权限控制，使用scheme:id:permission来标识：

                scheme：权限模式

                id：授权的对象

                permission：授予的权限

        zookeeper的权限控制是基于每个znode节点的，需要对每个节点设置权限；每个znode节点支持设置多种权限控制方案和多个权限；子节点不会继承父节点的权限，客户端无权访问某节点，但可以访问它的子节点。总结：节点的权限是独立的。

        （1）scheme

       默认权限为world:anyone:cdrwa。

         （2）id

        world模式下：anyone

        ip模式下：IP地址

        auth和digest模式下：认证用户

        （3）permission

         （4）命令

        getAcl path # 读取当前节点权限列表

        setAcl path scheme:id:permission，scheme:id:permission,....

        # 将/hadoop节点以ip模式为192.168.11.143客户端授予增、删、改、查、管理权限

        setAcl /hadoop ip:192.168.11.143:cdrwa

        addauth digest <user>:<password>  # 添加认证用户，auth和digest权限模式下使用

        # world授权模式  （在新版本下进行的setAcl，set不会自动输出元数据）

在新版本下：利用deleteall删除没有权限的节点，不会提示没有权限，而是提示 Failed to delete some node(s) in the subtree!，利用get读取没有r权限的节点时，不会提示Authentication is not valid而是报没有权限异常：org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /node1

         # ip授权模式

        远程登录zookeeper命令：zkCli.sh -server ip地址。在ip授权模式中，例如在192.168.11.141节点上开启zookeeper，创建/node2节点，授权192.168.11.143客户端对/node2的cdrwa操作，此时必须在192.168.11.143服务器上通过远程登录zookeeper命令登录192.168.11.141的zookeeper才能操作。在192.168.11.143利用zkCli.sh直接登录也无权访问。

        在node11上执行：（在新版本中getAcl /node2也无权访问）

         在node33上执行：        

        可以同时授权node11，node22，node33权限，用"，"隔开：

        setAcl /node2 ip:192.168.11.141:cdrwa,ip:192.168.11.142:cdrwa,ip:192.168.11.143:cdrwa

         # auth授权模式

        auth授权模式下，必须先提前添加授权用户，然后才可以为该用户授权，否则出错。

        在node11上执行：

        在node22上执行，在node22上并没有添加itcast认证用户，因此node22无权操作/node3，

在node22上添加itcast认证用户后，可以操作/node3了（注意addauth digest命令添加的认证用户

只在会话session中有效，退出zookeeper重新进入就没了）

        # digest授权模式

        在digest授权模式下，不用先进行授权用户的添加，且在进行授权过程中需要提供加密之后的

密码。

        setAcl path digest:user:password(加密后的密码):permission

        echo -n <user>:<password> | openssl dgst -binary -sha1 | openssl base64  # 获取加密

密码，在linux下执行

        digest授权模式只是与auth模式的授权方式不同，结果是相同的，只有拥有指定认证用户的客

户端允许访问相关节点。

        注意：本人在测试过程中一直出现添加了授权用户后，仍然没有权限的问题，经过仔细探索发现一模一样的命令产生的密码却不同：（下面的密文0sxEug2Dpm/NpzMPieOlFREd9Ao=是正确的）

         从上图可以看出命名完全一样但结果不同，故猜想一定是空格的问题，经过一轮测试发下将下面标红位置的空格去掉在重新输入空格后生成的密码变为正确，此时我真特码想骂人！

        # 单个节点支持多种授权模式

        # 超级管理员

        zk的权限管理有一种叫super的用户，该用户是zk的超级管理员可以访问任意权限的节点，这里需要打开zkServer.sh脚本文件，在该文件中设置超级管理员。设置好后，后续只要将super用户添加至认证用户，那么当前客户端就具有的超级管理员权限。

        假设这里我们设super:admin为超级管理员，首先获取密文密码：

        echo -n super:admin | openssl dgst -binary -sha1 | openssl base64

        vim zkServer.sh

        找到下面内容：

         添加配置信息：

        "-Dzookeeper.DigestAuthenticationProvider.superDigest=super:xQJmxLMiHGwaqBv
st5y6rkB6HQs="

        在node11，22，33都设置好后，重启zookeeper使配置生效，后续想使用super权限addauth digest super:admin即可

六、Zookeeper的zab协议

        zab协议全程Zookeeper Atomic Broadcast（Zookeeper原子广播）,在上文中我们在三台服务器上搭建了zookeeper集群，在每台服务器上都可以对数据节点进行相应的写操作，zookeeper是如何保证数据在集群中的最终一致性呢？（即在node11服务器上对节点的任何修改在其他任何服务器上都可以同步过去，保证数据一致性）zab协议解决了该问题。

        基于zab协议，zookeeper集群共有三种角色： 

         观察者角色在后文讲解，在集群中领导者只有一个，跟随者可以有多个，是一种主从模式。

        针对于在集群中的读操作，在任意一个服务器上都会保存zookeeper集群数据的一个副本，因此在任意一个服务器上开启客户端都能进行读操作。不依靠leader

        针对于在集群中的写操作，只能由leader发起，即使客户端连接的是follower，在follower上进行的任意写操作都需要先向leader申请，然后由leader广播，最后进行统一写操作。

        zab广播的原理是：

        （1）leader从客户端收到一个写请求

        （2）leader生成一个新的事务并为这个事务生成一个唯一的id

        （3）leader将这个事务提议（propose包含写请求的事务id和具体的操作）发送给所有的

                  follows节点（广播）

        （4）follower节点将收到的事务请求加入到历史队列中，并发送ack给leader

        （5）当leader收到大多数follower（半数以上节点）的ack消息后，leader会发送commit请求

        （6）当follow收到commit请求时，从历史队列中将事务请求commit提交（统一写操作）

        至此就实现了数据的最终一致性

七、Zookeeper的leader选举（面试重点）

        1、服务器状态

        looking:寻找leader状态。当服务器处于该状态时，它会认为当前集群中没有leader，因此需要进入leader选举状态

        leading：领导者状态，表明当前服务器角色是leader

        following：跟随者状态，表明当前服务器角色是follower

        observing：观察者状态，表明当前服务器角色是observer

        2、leader选举

        在刚开始启动zookeeper时（或集群在运行过程中leader宕机挂掉时），由于集群还没有leader（整个集群又变的没有leader了），此时各服务器都处于looking状态，会按照特定的选举流程进行leader选举，当选举完成后，leader变为leading状态，follower变为following状态，observer变为observing状态。

        （1）服务器启动时期的leader选举

        zxid：当前服务器所产生的最大事务id

    6、此时server2变为leader，server1变为follower，server2共计两票，此时很有可能server3会加入进来，给自己投一篇，由于server1，2已经不是looking状态，因此server1，2不会更改选票信息，交换信息之后server2有两票，server3有1票，此时server3服从多数，更改选票信息为2，并更改状态为following。

因此这也是为什么每次启动zookeeper后leader不一样的原因。

        （2）服务器运行时期的leader选举

        注意：当leader宕机后且剩余服务器数量超过半数以上（不包括半数）时，整个集群会重新进行leader选举，选举后重新对外提供服务。集群中只要有半数以上节点存活，zookeeper集群就能正常服务。因此zookeeper适合安装在奇数台服务器上，例如，zookeeper集群当前有5台服务器挂掉3台，集群无法提供服务，当zookeeper集群有6台服务器时挂掉3台同样集群无法提供服务，言外之意就是添加一台服务器并没有带来可靠性的提升，同时添加1台服务器成本很贵。

        问题：为什么在leader选举时事务id大的会被选为leader呢？

        回答：假设当前服务器node11，node22，node33为初始状态（即事务id初始为0）。node22为leader此时在node11的客户端进行了一个写操作，node22收到了写操作的请求进行广播，node11收到了广播信息并给node22提供ack确认，但是node22还没有收到node33的ack确认，此时node22宕机，显然在这个时候node11的事务id大于node33的事务id，重新选举leader时node11变为leader。将事务id最大的服务器选举为leader可以保留原leader宕机时最后一条事务信息不被丢失，并继续完成此事务。node11变为leader后，node11是知道原leader的事务提议的，此时node11会将此提议分发给node33并commit，这样可以使得原leader宕机时的最后一条事务也顺利执行成功。

八、Zookeeper的observer角色及其配置

        observer角色的配置：

                将想要变成oberver角色的服务器的配置文件中添加配置项：peerType=observer

                其次修改所有服务器的配置文件，指明谁是observer

                server.1=node11:2888:3888

                server.2=node22:2888:3888

                server.3=node33:2888:3888:observer

        observer角色不参与集群的leader选举，不参与集群中写数据的ack反馈。observer用于转发事务请求给leader（写），并处理客户端非事务请求（读），observer主要用于减轻zookeeper集群的负担，提高读速度。具体来讲observer主要用于分担follower的工作。所以一般客户端都在observer上开启。

九、zookeeper的图形化管理工具Zoolnspector（windows）

https://issues.apache.org/jira/secure/attachment/12436620/ZooInspector.zip  # 下载

下载好后解压，进入到build目录下，cmd运行zookeeper-dev.ZooInspector.jar

        java -jar zookeeper-dev-ZooInspector.jar

十、zookeeper的图形化监控管理工具taokeeper（linux系统）

        taokeeper工具的使用依赖于数据库，我们选择MySQL，taokeeper会将监控到的信息保存到MySQL数据库的相应表中，因此首先需要安装MySQL数据库，并在MySQL上创建相应的数据库和表。

        a.sql文件：放到/root/文件下

USE taokeeper;

-- ----------------------------
-- Table: alarm_settings
-- ----------------------------
DROP TABLE IF EXISTS `alarm_settings`;
CREATE TABLE `alarm_settings` (
  `alarm_settings_id` int(11) NOT NULL AUTO_INCREMENT,
  `cluster_id` int(11) NOT NULL,
  `wangwang_list` varchar(255) DEFAULT NULL,
  `phone_list` varchar(255) DEFAULT NULL,
  `email_list` varchar(255) DEFAULT NULL,
  `max_delay_of_check` varchar(255) DEFAULT NULL,
  `max_cpu_usage` varchar(255) DEFAULT NULL,
  `max_memory_usage` varchar(255) DEFAULT NULL,
  `max_load` varchar(255) DEFAULT NULL,
  `max_connection_per_ip` varchar(255) DEFAULT NULL,
  `max_watch_per_ip` varchar(255) DEFAULT NULL,
  `data_dir` varchar(255) DEFAULT NULL,
  `data_log_dir` varchar(255) DEFAULT NULL,
  `max_disk_usage` varchar(255) DEFAULT NULL,
  `node_path_check_rule` text,
  PRIMARY KEY (`alarm_settings_id`),
  UNIQUE KEY `uk_alarm_settings_cid` (`cluster_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=gbk;

-- ----------------------------
-- Table taokeeper_settings
-- ----------------------------
DROP TABLE IF EXISTS `taokeeper_settings`;
CREATE TABLE `taokeeper_settings` (
  `settings_id` int(11) NOT NULL auto_increment,
  `env_name` varchar(20) default NULL,
  `max_threads_of_zookeeper_check` int(5) default NULL,
  `description` varchar(255) default NULL,
  PRIMARY KEY  (`settings_id`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;

-- ----------------------------
-- Table: taokeeper_stat
-- ----------------------------
DROP TABLE IF EXISTS `taokeeper_stat`;
CREATE TABLE `taokeeper_stat` (
  `cluster_id` int(11) NOT NULL,
  `server` varchar(30) NOT NULL COMMENT '127.0.0.1:2181',
  `stat_date_time` datetime NOT NULL COMMENT '统计时间 2012-01-05 14:56:20',
  `stat_date` date NOT NULL,
  `connections` int(11) DEFAULT NULL,
  `watches` int(11) DEFAULT NULL COMMENT '订阅者数目',
  `send_times` bigint(20) unsigned DEFAULT 0,
  `receive_times` bigint(20) unsigned DEFAULT 0,
  `node_count` int(11) DEFAULT 0,
  PRIMARY KEY (`cluster_id`,`server`,`stat_date_time`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;

-- ----------------------------
-- Table: zookeeper_cluster
-- ----------------------------
DROP TABLE IF EXISTS `zookeeper_cluster`;
CREATE TABLE `zookeeper_cluster` (
  `cluster_id` int(11) NOT NULL auto_increment,
  `cluster_name` varchar(255) NOT NULL,
  `server_list` varchar(255) NOT NULL,
  `description` varchar(255) default NULL,
  PRIMARY KEY  (`cluster_id`)
) ENGINE=InnoDB DEFAULT CHARSET=gbk;

        在node11上安装MySQL

        export MYSQL_PWD=123456

        mysql -uroot -e "CREATE DATABASE taokeeper;"

        mysql -uroot taokeeper < /root/a.sql

        下载taokeeper工具并解压至/export/server/，然后配置相关文件

        cd /export/server/taokeeper-monitor-tomcat/webapps/ROOT/conf

        vim taokeeper-monitor-config.properties

        cd /export/server/taokeeper-monitor-tomcat/webapps/ROOT/WEB-INF/classes

        vim log4j.properties  # 修改好自己的路径

        mkdir /export/server/zookeeper/taokeeperdata

        cd /export/server/zookeeper/taokeeperdata

        mkdir log

        mkdir ZooKeeperClientThroughputStat

        cd /export/server/taokeeper-monitor-tomcat/bin

        chmod 750 *

        vim catalina.sh

        添加JAVA_OPTS=-DconfigFilePath="/export/server/taokeeper-monitor-
tomcat/webapps/ROOT/conf/taokeeper-monitor-config.properties"

        ./startup.sh

        cd /export/server/taokeeper-monitor-tomcat/logs

        less catalina.out  # 查看文件less类似于more命令，看到success

        至此taokeeper安装完成并启动成功

        在浏览器中输入http://192.168.11.141:8080

十一、zookeeper脚本编写

        1、zookeeper集群一键启停脚本

        前面也可以体会到想要启动zookeeper集群，需要在每台服务器上zkServer.start/stop/status，如果zookeeper集群有100台呢，显然很麻烦，这里我们编写一键启停脚本，一条命令即可启动整个zookeeper集群。由于该脚本的编写用到ssh命令，请确保node11，22，33在zookeeper用户上已设置好免密登录。

        # ssh命令

        ssh 服务器地址 程序路径   # 远程登录到指定服务器执行指定的程序

        # 在node33上执行（在那台服务器上执行都可以）

        cd /export/server1/zookeeper/bin/   （在任意命令下都可以，确保可以从PATH中找到）

        vim zk.sh

        chmod 755 zk.sh

        zk.sh start/stop/status/restart

        2、一键查看jps脚本

                cd /home/zookeeper/bin   # 已在PATH中

                vim jpsall

                chmod 755 jpsall

                jpsall

        上述脚本大家灵活应用即可。 

面试真题：

        问题：生产环境下不同的服务器数应当安装多少个zk合适呢？

        zookeeper集群的适合安装在奇数台服务器上，具体来讲生产经验为：

                10台服务器：  3台zk；

                20台服务器：  5台zk；

                100台服务器：11台zk；

                200台服务器：11台zk；

        安装zk服务器的台数越多，可靠性越好，但提高了通信延时

        注意本人没有接触过java的相关知识，而zookeeper的底层是java，因此想要深入学习zookeeper需要掌握java的基础，后续会补充进来。