zookeeper 客户端配置_zookeeper手把手教程一

1.zookeeper作用以及集群配置

zookeeper作用

数据的发布/订阅(配置中心:disconf) 、 负载均衡(dubbo利用了zookeeper机制实现负载均衡) 、命名服务、 master选举(kafka、hadoop、hbase)、分布式队列、分布式锁

zookeeper特性

• 顺序一致性 从同一个客户端发起的事务请求，最终会严格按照顺序被应用到zookeeper中
• 原子性 所有的事务请求的处理结果在整个集群中的所有机器上的应用情况是一致的，也就是说，要么整个集群中的所有机器都成功应用了某一事务、 要么全都不应用
• 可靠性 一旦服务器成功应用了某一个事务数据，并且对客户端做了响应，那么这个数据在整个集群中一定是同步并且保留下来的
• 实时性 一旦一个事务被成功应用，客户端就能够立即从服务器端读取到事务变更后的最新数据状态；(zookeeper仅仅保证在一定时间内，近实时)

zookeeper集群配置

需要jdk 省略。三台虚拟机：192.168.202.133；192.168.202.134；192.168.202.135

0. 下载zookeeper的安装包 http://apache.fayea.com/zookeeper/stable/zookeeper-3.4.8.tar.gz
1. 解压zookeeper

• cd /usr/local
• mkdir zookeeper
• cd zookeeper
• tar -zxvf zookeeper-3.4.8.tar.gz 3.配置zoo.cfg
• pwd /usr/local/zookeeper/zookeeper-3.4.8
• cd conf
• cp zoo_sample.cfg zoo.cfg 修改如图所示的dataDir; 如上操作3台服务器都需要操作一次； 然后切换到133到dataDir目录下
• cd /usr/local/zookeeper/zookeeper-3.4.8/data
• touch myid
• vim myid 写入1

每台服务器对应的myid和server后面的数字有关;以此类推

133 myid 1134 myid 2135 myid 3

2181是客户端连接zookeeper服务的端口，这是一个TCP port。 2888是zookeeper的端口 3888是leader选举的端口

分别启动三台服务器，bin下面有错误日志,zookeeper.out.

• /usr/local/zookeeper/zookeeper-3.4.8/bin
• ./zkServer.sh start
• ./zkServer.sh status #查看zookeeper的启动状态

报错链接异常，有可能是防火墙问题

• systemctl stop firewalld.service #停止firewall
• systemctl disable firewalld.service #禁止firewall开机启动
• firewall-cmd --state #查看默认防火墙状态(关闭后显示notrunning，开启后显示running)

2. zookeeper的三种角色

• Leader：接受所有Follower的提案请求并统一协调发起投票的提案，负责与所有Follower进行内部数据交换(同步)
• Follower：直接为客户端服务，并参与提案的投票，同时与Leader进行数据交换(同步)
• Observer: 直接为客户端服务，但不参与提案的投票，同时也与Leader进行数据交换(同步)

举个例子其实很简单理解这三种关系： Leader是项目经理，Follower是公司员工，Observer是外包员工；Leader 出事之后，只有内部员工Follower才有选举权利。作为外包，钱多活少没人权

3. Observer作用以及配置方法

Observer作用

• Observers：在不伤害写性能的情况下扩展Zookeeper
• 尽管通过Client直接连接到Zookeeper集群的性能已经非常好了，但是这种架构如果要承受超大规模的Client，就必须增加Zookeeper集群的Server数量，随着Server的增加，Zookeeper集群的写性能必定下降，我们知道Zookeeper的Znode变更是要过半数投票通过，随着机器的增加，由于网络消耗等原因必然导致投票成本增加，从而导致写性能的下降。
• Observer是一种新型的Zookeeper节点，可以帮助解决上述问题，提供Zookeeper的可扩展性。Observer不参与投票，只是简单的接收投票结果，因此我们增加再多的Observer，也不会影响集群的写性能。除了这个差别，其他的和Follower基本上完全一样。例如：Client都可以连接到他们，并且都可以发送读写请求给他们，收到写请求都会上报到Leader。
• Observer有另外一个优势，因为它不参与投票，所以他们不属于Zookeeper集群的关键部位，即使他们Failed，或者从集群中断开，也不会影响集群的可用性。根据Observer的特点，我们可以使用Observer做跨数据中心部署。如果把Leader和Follower分散到多个数据中心的话，因为数据中心之间的网络的延迟，势必会导致集群性能的大幅度下降。使用Observer的话，将Observer跨机房部署，而Leader和Follower部署在单独的数据中心，这样更新操作会在同一个数据中心来处理，并将数据发送的其他数据中心(包含Observer的)，然后Client就可以在其他数据中心查询数据了。但是使用了Observer并非就能完全消除数据中心之间的延迟，因为Observer还得接收Leader的同步结果合Observer有更新请求也必须转发到Leader，所以在网络延迟很大的情况下还是会有影响的，它的优势就为了本地读请求的快速响应。

配置方法

我将第一台服务器作为Observer：192.168.202.133

• vim zoo.cfg
• 133 服务器的zoo.cfg

peerType=observerserver.1=192.168.202.133:2888:3888:observerserver.2=192.168.202.134:2888:3888server.3=192.168.202.135:2888:388

• 134 服务器的zoo.cfg

server.1=192.168.202.133:2888:3888:observerserver.2=192.168.202.134:2888:3888server.3=192.168.202.135:2888:388

• 135 服务器的zoo.cfg

server.1=192.168.202.133:2888:3888:observerserver.2=192.168.202.134:2888:3888server.3=192.168.202.135:2888:388

验证： 进入zookeeper的bin目录

133服务器：

134服务器:

135服务器:

zk客户端监控工具使用zkui

ZooKeeper 可视化监控 zkui

---

【黑白】 2017-08-03 0:37