Apache ZooKeeper是由Apache Hadoop的子项目发展而来,于2010年11月正式成为了Apache的顶级项目。ZooKeeper为分布式应用提供了高效且可靠的分布式协调服务,提供了诸如统一命名服务
、配置管理
和分布式锁
等分布式的基础服务。在解决分布式一致性方面,ZooKeeper并没有直接采用Paxos算法,而是采用了一种被称为ZAB(ZooKeeper Atomic Broadcast)的一致性协议。
ZooKeeper是一个开放源代码的分布式协调服务,由知名互联网公司雅虎创建,是Google Chubby的开源实现。ZooKeeper的涉及目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一些列简单易用的接口提供给用户使用。
ZooKeeper在大型分布式系统中的应用案例:
- Hadoop
- HBase
- Kafka
- Alibaba 消息中间件 Metamorphosis(MetaQ)
- Alibaba RPC服务框架 Dubbo
- Alibaba 实时计算引擎 JStorm
ZooKeeper是一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它实现诸如数据发布/订阅
、负载均衡
、命名服务
、分布式协调/通知
、集群管理
、Master选举
、分布式锁
、分布式队列
和分布式Barrier
等功能。
ZooKeeper可以保证如下分布式一致特性
顺序一致性
从同一个客户端发起的事物请求,最终会严格按照其发起的顺序被应用到ZooKeeper中去。
原子性
所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致,也就是说,要么整个集群所有机器都成功应用了某一个事物,要么都没有应用,一定不会出现集群中部分机器应用了该事物,而另一部分没有应用的情况。
单一视图(Single System Image)
无论客户端连接的是那个ZooKeeper服务器,其看到的服务端数据模型都是一致的。
可靠性
一旦服务端成功的应用了一个事物,并完成对客户端的响应,那么该事物所引起的服务端状态变更将会一直保留下来,除非有另一个事物又对其进行了变更。
实时性
通常人们看到实时性的第一反映是,一旦一个事物被成功应用,那么客户端能够立即从服务端上读取到这个事物变更后的最新数据状态。这里需要注意的是,ZooKeeper仅仅保证在一定的时间段内,客户端最终一定能够从服务端上读取到最新的数据状态(ZooKeeper是基于异步通知的)。
version: ‘3‘
services:
zk01:
image: zookeeper:3.3.6
container_name: zk01
expose:
- "2181"
- "2888"
- "3888"
ports:
- "2191:2181"
restart: always
environment:
ZOO_MY_ID: 1
ZOO_SERVERS: server.1=zk01:2888:3888 server.2=zk02:2888:3888 server.3=zk03:2888:3888 server.4=zk04:2888:3888 server.5=zk05:2888:3888
networks:
- zk_network
zk02:
image: zookeeper:3.3.6
container_name: zk02
expose:
- "2181"
- "2888"
- "3888"
ports:
- "2192:2181"
restart: always
environment:
ZOO_MY_ID: 2
ZOO_SERVERS: server.1=zk01:2888:3888 server.2=zk02:2888:3888 server.3=zk03:2888:3888 server.4=zk04:2888:3888 server.5=zk05:2888:3888
networks:
- zk_network
zk03:
image: zookeeper:3.3.6
container_name: zk03
expose:
- "2181"
- "2888"
- "3888"
ports:
- "2193:2181"
restart: always
environment:
ZOO_MY_ID: 3
ZOO_SERVERS: server.1=zk01:2888:3888 server.2=zk02:2888:3888 server.3=zk03:2888:3888 server.4=zk04:2888:3888 server.5=zk05:2888:3888
networks:
- zk_network
zk04:
image: zookeeper:3.3.6
container_name: zk04
expose:
- "2181"
- "2888"
- "3888"
ports:
- "2194:2181"
restart: always
environment:
ZOO_MY_ID: 4
ZOO_SERVERS: server.1=zk01:2888:3888 server.2=zk02:2888:3888 server.3=zk03:2888:3888 server.4=zk04:2888:3888 server.5=zk05:2888:3888
networks:
- zk_network
zk05:
image: zookeeper:3.3.6
container_name: zk05
expose:
- "2181"
- "2888"
- "3888"
ports:
- "2195:2181"
restart: always
environment:
ZOO_MY_ID: 5
ZOO_SERVERS: server.1=zk01:2888:3888 server.2=zk02:2888:3888 server.3=zk03:2888:3888 server.4=zk04:2888:3888 server.5=zk05:2888:3888
networks:
- zk_network
networks:
zk_network:
driver: bridge
Leader
Leader节点能够进行数据的读写
Follower
Follower节点只能进行数据的读,不能进行数据的写。Follower能参与Leader的选举。
Observer
Observer节点与Follower节点一样只能进行数据的读,与Follower节点的区别是,它不参与Leader的选举。
所需依赖:
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>${zookeeper.version}</version>
</dependency>
所需依赖:
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>${zookeeper.version}</version>
</dependency>
<dependency>
<groupId>com.github.sgroschupf</groupId>
<artifactId>zkclient</artifactId>
<version>${zkclient.version}</version>
</dependency>
所需依赖:
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>${zookeeper.version}</version>
</dependency>
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>${curator.version}</version>
</dependency>
另外,curator不仅为开发者提供了更为便利的API接口,而且还提供了一些典型场景的使用参考(Master选举、分布式锁、分布式计数器、分布式Barrier)以及一些工具类,极大的方便Java对ZooKeeper的操作,所需依赖:
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>${curator.recipes.version}</version>
</dependency>
配置中心,例如360的QConf、百度的Disconf(持久节点)。
分布式系统中的唯一ID,订单ID、商品ID等(持久顺序节点)。
原文:https://www.cnblogs.com/lonelyxmas/p/10336485.html