问题引入

zookeeper新引入的角色observer是不参与投票的，通过增加observer节点，可以在提高zk系统读吞吐量时，不影响写吞吐量。

那么问题来了

  1. Zookeeper系统节点如果超过半数宕机，就没法正常提高服务，这里的节点是否包含observer节点？

  2. observer节点是否能提供写操作？还是只是充当“数据视图”的角色？

  3. 在跨机房中，如何更好的利用observer这个角色？

为了解决这些问题，我们在docker里搭建一套zookeeper环境（文末附上docker-compose配置文件zk.yml）。该zookeeper包含：1个leader节点，2个follower节点，2个observer节点。如下zk4，zk5为observer节点

➜  docker COMPOSE_PROJECT_NAME=zktest docker-compose -f zk.yml up

➜  docker COMPOSE_PROJECT_NAME=zktest docker-compose -f zk.yml ps

Name              Command               State                     Ports

------------------------------------------------------------------------------------------

zk1    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2881->2181/tcp, 2888/tcp, 3888/tcp

zk2    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2882->2181/tcp, 2888/tcp, 3888/tcp

zk3    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2883->2181/tcp, 2888/tcp, 3888/tcp

zk4    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2884->2181/tcp, 2888/tcp, 3888/tcp

zk5    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2885->2181/tcp, 2888/tcp, 3888/tcp

1、Zookeeper系统节点如果超过半数宕机，就没法正常提高服务，这里的节点是否包含observer节点？

测试1：将2个observer节点和1个follower或者leader节点删掉

➜  docker docker rm -f zk3 zk4 zk5

zk3

zk4

zk5

➜  docker COMPOSE_PROJECT_NAME=zktest docker-compose -f zk.yml ps

Name              Command               State                     Ports

------------------------------------------------------------------------------------------

zk1    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2881->2181/tcp, 2888/tcp, 3888/tcp

zk2    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2882->2181/tcp, 2888/tcp, 3888/tcp

测试下zookeeper系统是否正常提高服务

➜  docker echo stat | nc localhost 2881

Zookeeper version: 3.4.12-e5259e437540f349646870ea94dc2658c4e44b3b, built on 03/27/2018 03:55 GMT

Clients:

Latency min/avg/max: 0/0/0

Received: 2

Sent: 1

Connections: 1

Outstanding: 0

Zxid: 0x300000000

Mode: leader

Node count: 6

如上zookeeper可以正常提供服务。此时zookeeper系统节点包含：1个leader节点，1个follower节点。

假如zookeeper系统超过半数节点宕机则无法提供服务，这里的节点包括observer，那么一个拥有5个节点的机子，宕机了3个，理论上是没法提供服务的，与上面结果不符。显然假设不成立。

所以，zookeeper系统超过半数节点宕机则无法提供服务，这里的节点不包括observer。

接下来将zk2也删除，zookeeper系统没法正常提供服务。

➜  docker docker rm -f zk2

zk2

➜  docker echo stat | nc localhost 2881

This ZooKeeper instance is not currently serving requests

测试2：将2个leader或者follower节点删除

重启zookeeper系统

➜  docker COMPOSE_PROJECT_NAME=zktest docker-compose -f zk.yml up

➜  docker COMPOSE_PROJECT_NAME=zktest docker-compose -f zk.yml ps

Name              Command               State                     Ports

------------------------------------------------------------------------------------------

zk1    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2881->2181/tcp, 2888/tcp, 3888/tcp

zk2    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2882->2181/tcp, 2888/tcp, 3888/tcp

zk3    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2883->2181/tcp, 2888/tcp, 3888/tcp

zk4    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2884->2181/tcp, 2888/tcp, 3888/tcp

zk5    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2885->2181/tcp, 2888/tcp, 3888/tcp

删除2个leader或者follower节点

➜  docker docker rm -f zk1 zk2

zk1

zk2

➜  docker COMPOSE_PROJECT_NAME=zktest docker-compose -f zk.yml ps

Name              Command               State                     Ports

------------------------------------------------------------------------------------------

zk3    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2883->2181/tcp, 2888/tcp, 3888/tcp

zk4    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2884->2181/tcp, 2888/tcp, 3888/tcp

zk5    /docker-entrypoint.sh zkSe ...   Up      0.0.0.0:2885->2181/tcp, 2888/tcp, 3888/tcp

测试zookeeper是否正常提供服务

➜  docker echo stat | nc localhost 2883

This ZooKeeper instance is not currently serving requests

结果显示，无法正常提供服务。由此进一步验证上面的结论。

结论

zookeeper系统超过半数节点宕机则无法提供服务，这里的节点不包括observer。所以，准确的应该说，zookeeper系统超过半数的follower或者leader节点宕机，则无法提供服务。

  • zookeeper节点间心跳检测时，leader会判断收集到的成功响应节点中，follower节点是否过半，如果不是则断定当前系统已经宕机
  • 用户往zookeeper写数据时，leader将提交请求转发给各个follower节点，并判断是否过半节点成功响应。如果成功响应，则将数据提交写入，observer直接共享提交后的数据结果

2、observer节点是否能提供写操作？还是只是充当“数据视图”的角色？

进入observer节点，创建节点

➜  docker zkCli -server localhost:2885

Connecting to localhost:2885

Welcome to ZooKeeper!

JLine support is enabled

[zk: localhost:2885(CONNECTING) 0] ls

WATCHER::

WatchedEvent state:SyncConnected type:None path:null

[zk: localhost:2885(CONNECTED) 1] ls /

[zookeeper]

[zk: localhost:2885(CONNECTED) 2] create /test test

Created /test

[zk: localhost:2885(CONNECTED) 3] get /test

test

cZxid = 0x500000002

ctime = Fri Jun 15 12:04:43 CST 2018

mZxid = 0x500000002

mtime = Fri Jun 15 12:04:43 CST 2018

pZxid = 0x500000002

cversion = 0

dataVersion = 0

aclVersion = 0

ephemeralOwner = 0x0

dataLength = 4

numChildren = 0

[zk: localhost:2885(CONNECTED) 4]

结论

由上可知，observer和其他follower节点一样，支持写操作。也就是用户连接到observer节点后，发起写操作请求时，observer节点会将写请求转发给leader，该过程和follower一样。不同的时，leader将写操作分发到各个节点时，并不会分发给observer，由此来保证在增加observer节点时，不会影响写吞吐量。

3、在跨机房中，如何更好的利用observer这个角色？

假如有两个机房，一个在中国青岛，一个美国纽约。那么在架构部署时，可以将leader/follower节点集中部署在中国青岛或者美国纽约，从而避免应跨机房导致的网络通讯开销。因为所有的follower都会参与投票。另一个机房则动态增加observer节点，来提高系统的读吞吐量。

zookeeper集群系统docker-compose配置文件 zk.yml

version: '2'

services:

    zk1:

        image: zookeeper

        restart: always

        container_name: zk1

        ports:

            - "2881:2181"

        environment:

            ZOO_MY_ID: 1

            ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888 server.4=zk4:2888:3888:observer server.5=zk5:2888:3888:observer

    zk2:

        image: zookeeper

        restart: always

        container_name: zk2

        ports:

            - "2882:2181"

        environment:

            ZOO_MY_ID: 2

            ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888 server.4=zk4:2888:3888:observer server.5=zk5:2888:3888:observer

    zk3:

        image: zookeeper

        restart: always

        container_name: zk3

        ports:

            - "2883:2181"

        environment:

            ZOO_MY_ID: 3

            ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888 server.4=zk4:2888:3888:observer server.5=zk5:2888:3888:observer

    zk4:

        image: zookeeper

        restart: always

        container_name: zk4

        ports:

            - "2884:2181"

        environment:

            ZOO_MY_ID: 4

            PEER_TYPE: observer

            ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888 server.4=zk4:2888:3888:observer server.5=zk5:2888:3888:observer

    zk5:

        image: zookeeper

        restart: always

        container_name: zk5

        ports:

            - "2885:2181"

        environment:

            ZOO_MY_ID: 5

            PEER_TYPE: observer

            ZOO_SERVERS: server.1=zk1:2888:3888 server.2=zk2:2888:3888 server.3=zk3:2888:3888 server.5=zk4:2888:3888:observer server.5=zk5:2888:3888:observer

最新文章

  1. [翻译]Telnet简单介绍及在windows 7中开启Telnet客户端
  2. 编写一个基本的连接池来实现连接的复用&一些工程细节上的优化
  3. jQuery判断一个字符串中是否包含一个字符串（一）
  4. [转]大数据hadoop集群硬件选择
  5. 11款样式新颖的 jQuery/CSS3 网页菜单
  6. C# Window Form播放音乐的4种方式
  7. Redis的初步安装
  8. 14个最受欢迎的Python开源框架
  9. java解析属性文件
  10. 排队论的C实现
  11. poj1969---找规律
  12. STL中主要的算法(一)
  13. 实时音视频互动系列（下）：基于 WebRTC 技术的实战解析
  14. 【Android Studio安装部署系列】十二、Android studio代码混淆
  15. django之注册登录
  16. 厘摩（centimorgan，cM）到底是啥鬼
  17. Java设计模式之四 ----- 适配器模式和桥接模式
  18. C++ 作业 （循环链表构建队列）
  19. Java实现选择排序以及冒泡排序
  20. OpenEXR的读取机制

热门文章

  1. Java面试题系列（六）优化tomcat配置
  2. #424 Div2 Problem C Jury Marks (二分 && 暴力 && std::unique && 思维)
  3. 【CF1250G】Discarding Game（DP)
  4. PCL智能指针疑云 <一>
  5. CSV文件在Python中的几种处理方式
  6. Android应用源码航空订票软件客户端
  7. sqli-labs(29)
  8. HTTPS协议详解(一)：HTTPS基础知识
  9. Oracle JET mobile 入门使用
  10. zabbix监控惠普打印机