Zookeeper的集群特性_zk 集群特性

目录

1 集群特性

2 选举机制

3 监听机制

3.1 监听节点值的变化

3.2 监听节点的子节点变化

 

---

    前面我们讲过zookeeper的安装，在安装过程中，我们看到当启动一个节点的时候，查看状态，提示信息是未启动，那么到底是怎么回事呢？下面我们介绍一下zookeeper的集群特性和选举的机制。

1 集群特性

    一个ZooKeeper集群中，有一个领导者Leader和多个跟随者Follower ，Leader负责进行投票的发起和决议，更新系统状 Follower用于接收客户端的请求并向客户端返回结果，在选举Leader过程中参与投票。

集群特性

• 半数机制

        集群中只要有半数以上节点存活，集群就能够正常工作，所以一般集群中的服务器个数都为奇数

• 全局数据一致

        集群中每台服务器保存一份相同的数据副本，不论客户端连接到哪个服务器，数据都是一致的

• 更新请求顺序执行

        来自同一个客户端的更新请求，按其发送顺序依次执行

• 数据更新的原子性

        一次数据更新，要么成功，要么失败

• 实时性

         在一定的时间范围内，客户端能读取到最新数据

2 选举机制

ZooKeeper在提供服务时会自动选举一个节点服务器作为Leader，其他都是Follower

选举流程：假设我们选取5台机器部署

1. Server1启动，给自己投票，然后发送投票信息，由于其它服务器都还没启动，所以它发现的消息收不到任何反馈，此时Server1为Looking状态
2. Server2启动，给自己投票，同时与Server1通信交换选举结果，由于Server2的id值较大，所以Server2胜出，但由于投票数没有过半，此时Server1和Server2都为Looking状态
3. Server3启动，给自己投票，同时与Server1和Server2通信交换选举结果，由于Server3的id值较大，所以Server3胜出，此时票数已经过半，所以Server3为Leader，Server1和Server2为Follower
4. Server4启动，给自己投票，同时与Server1、Server2、Server3通信交换选举结果，尽管Server4的id较大，但由于集群中已经存在Leader，所以Server4只能为Follower
5. Server5启动，同Server4类似，只能为Follower

总结：

• 每个服务器在启动时都会选择自己，然后将投票信息发送出去
• 服务器编号ID越大，在选择算法中的权重越大
• 投票数必须过半，才能选出Leader
• 谁是Leader：启动顺序的前 集群数/2+1 个服务器中，id值最大的会成为Leader

 

3 监听机制

3.1 监听节点值的变化

# 在集群的A服务器，监听某个节点值的变化
get /yyy watch
# 在集群的B服务器，修改对应节点的值
set /yyy myyyy
# 此时A服务器会收到事件NodeDataChanged
WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChanged path:/yyy

监听Watch事件是一个一次性的触发器，当数据改变时只会触发一次，如果以后这个数据再发生改变，则不会再次触发。

3.2 监听节点的子节点变化

# 在集群的A服务器，监听某个节点的子节点的变化
ls /yyy watch
# 在集群的B服务器，创建/修改/删除对应节点的子节点
create /yyy/hello hello
# 此时A服务器会收到事件NodeChildrenChanged
WATCHER::
WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/yyy