ZooKeeper浅入理解

1. ZooKeeper是什么

ZooKeeper是一款分布式资源协调框架,等同于Spring Eureka 在Spring Cloud的作用,一般配合Dubbo作为注册中心使用.(dobbu+zooKeeper是比较传统的分布式架构之一)
官网:https://zookeeper.apache.org/

2.Zookeeper的服务

1.分布式锁

1. 客户端A请求分布式锁,先判断是否为序位第一个,生成一个队列号(设为1)并且判断自己是否在第一位,
然后在去执行任务
2. 客户端B请求分布式锁.任判断是否为序位第一个,但是前面有一个了,
则生成一个队列号(设为2)并生成一个监听器,去监听前面一个的分布式锁(客户端A生成的1)
3. 当1执行完成之后释放(删除自己的队列号),当2监听1不在之后则开始进行给自己上锁
4. 整个过程类似于去医院挂号看病,谁先来谁先看的排队机制.当然也存在过号不补
(当客户端宕机以后,ZK感知到以后会自动把客户端的序列号给删除),后面的一次补上来

2.统一配置管理

1. 统一管理分布式服务的配置(后台设置到数据库中)
2. ZK(配置数据一般放到node中)从数据库中查询到配置并修改,
3. 子应用通过服务(一般为ZK的Watcher)监听到有修改,则不需要重启就可以同步修改
4. 应用场景一般为参数的配置如(FTP Server的端口,数据库地址账户密码等等)

3.负载均衡

3.Zookeeper的特性

1. 一致性:类似于堆栈,执行先进先出的原则
2. 原子性:所有事务的请求在集群服务器上面的结果是一致的,要么全部成功,要么全部失败
3. 单一性:无论连着到任一服务器,所能看到的结果都是一致的.
4. 可靠性:一旦服务端完成一个事务,那么它将被保存在内存当中,除非有其他事务将其改变
5. 实时性:ZK保证在一段时间里面,客户端将会获取到最新的数据.

4.集群

1. 一般ZK有多个服务器节点组成
2. 客户端可以通过任意一个节点请求到任何一个节点(Leader)
3. 服务器角色
		1) Leader(领导者):在ZK中只能有一个该角色,同过Follower选举出来.
		   主要责任:统一处理集群的事务性请求以及集群内各服务器的调度.
		 2) Follower(追随者):Leader之下的一个角色
		 	主要责任:选举Leader,处理非事务请求(查),并将事务请求(增删改)转发给Leader
		 3)Observer(观察者):类似Follower的一个角色,不参与选举

5.会话(session)

1. 在客户端与服务端通话的时候会建立一个TCP长链接,当在第一次请求时这个链接就已经开始了
2. 在会话当中,仍可以发送服务器的Watch事件通知
3. 假设当前链接的服务端由于某种原因发生宕机,在一定时间中链接到其他服务器仍可以继续会话

6.数据节点(Node)

1. 由服务器集群构成的节点为机器节点,数据构成的节点自然就是数据节点了
2. ZK的数据模型跟Tree结构相似,每个节点由"/"开始,每个节点都会有自己对应的数据
3. 节点类型
		1): PERSISTENT(持久型节点),不主动删除则会一直存在
		2): PERSISTENT_SEQUENTIAL(持久顺序型节点),在持久型特性上新增了顺序
		3): EPEMERAL(临时节点),在会话中产生的节点,会话失效节点消失,不能创建为子节点
		4): EPEMERAL_SEQUENTIAL(临时顺序型节点),在临时型特性上新增了顺序

7.事件监听器(watcher)

ZK允许客户端在节点上面注册watcher,当节点发生变化时,ZK将把变化的数据发给注册的客户端

总结

以上均为个人理解,理解不到位,多多见谅