zookeeper

概述

1. 分布式应用程序协调服务系统，是大数据生态圈的重要组件。分布式开源系统如Hadoop,Hbase，Kafka等依赖zookeeper提供一致协调服务。
2. 分布式应用程序可以基于Zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
3. zk集群部署模式：单机模式、伪集群模式、集群模式，集群规则至少2N+1台服务器
4. java客户端：zk自带的zkclient及Apache开源的Curator
5.  
6. Eureka保证分布式系统的AP，zookeeper保证的CP
7. zookeeper中所有的更新都是全局有序的，每个更新都有一个唯一的时间戳
8. 常用命令：ls get set create delete

功能

1、文件系统
2、通知机制

zk文件系统提供一个多层级的节点命名空间（节点为znode）。这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行

4种节点类型Znode

PERSISTENT-持久节点：除非手动删除，否则节点一直存在于Zookeeper上

EPHEMERAL-临时节点：临时节点的生命周期与客户端会话绑定，一旦客户端会话失效，该客户端创建的所有临时节点都会被移除

PERSISTENT_SEQUENTIAL-持久顺序节点：同持久化节点特性，增加了顺序特性

EPHEMERAL_SEQUENTIAL-临时顺序节点：同临时节点特性，增加了顺序特性

 

zookeeper数据变更通知

工作机制：

• 客户端注册watcher：调用getData()/getChildren()/exist()三个API，传入Watcher对象
• 服务端处理watcher
• 客户端回调watcher：客户端的Watcher机制是一次性的，一旦被触发后，该Watcher就失

服务器角色:

leader:务请求的唯一调度和处理者，保证集群事务处理的顺序性;集群内部各服务的调度者

follower:

• 处理客户端的非事务请求，转发事务请求给Leader服务器
• 参与Leader选举投票,
• 参与事务请求Proposal的投票

observer:V3.3.0之后引入的，处理客户端的非事务请求，转发事务请求给Leader服务器，不参与投票

状态：LOOKING、FOLLOWING、LEADING、OBSERVING

 

Leader选举

当集群的一台服务器出现：服务器初始化启动或服务器运行期间无法和Leader保持连接。出现两种情况之一，就会Leader选举

1. 服务器启动时期的Leader选举过程（集群中至少需要2台服务器）：

    每个Server发出一个投票 ----> 接受来自各个服务器的投票 ---> 处理投票:(myid,zxid)，首先比较zxid，较大的作为leader，否则，比较myid，较大的作为leader ---> 统计投票 ---> 改变服务器状态：leader节点改为LEADING，follower节点改为FOLLOWING

2. 服务器运行时期的Leader选举

运行期间一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致

 

数据同步流程

同步流程：（均以消息传递的方式进行）

i. 非leader节点向Leader注册

ii. 数据同步

iii. 同步确认

zookeeper采用了全局递增的事务Id来保证事务的顺序一致性

 

zk节点宕机：ZK集群的机制是只要超过半数的节点正常，集群就能正常提供服务

负载均衡zk和Nginx:

zk的负载均衡是可以调控,nginx只是能调权重；

nginx的吞吐量比zk大；

 

zab和paxos:

相同点：两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行

不同点：ZAB用来构建高可用的分布式数据主备系统，Paxos是用来构建分布式一致性状态机系统

 

应用场景：

通过对Zookeeper中丰富的数据节点进行交叉使用，配合Watcher事件通知机制，可以实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。