[b][color=olive][size=large]Zookeeper最早是Hadoop的一个子项目,主要为Hadoop生态系统中一些列组件提供统一的分布式协作服务,在2010年10月升级成Apache Software
Foundation(ASF)顶级项目,它主要提供以下的四个功能:
[table]
|功能名|
|组管理服务|
|分布式配置服务|
|分布式同步服务|
|分布式命名服务|
[/table]
Zookeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户;
Zookeeper的架构图如下:
[/size][/color][/b]
[img]http://dl2.iteye.com/upload/attachment/0091/8360/2f9be92b-4e1b-3d9e-b79d-40cbfe6c77ad.jpg[/img]
[b][color=green][size=large]
Zookeeper的特点如下:
[table]
|特点|说明|
|最终一致性|为客户端展示同一个视图,这是zookeeper里面一个非常重要的功能|
|可靠性|如果消息被到一台服务器接受,那么它将被所有的服务器接受。|
|实时性|Zookeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。|
|独立性|各个Client之间互不干预|
|原子性|更新只能成功或者失败,没有中间状态。|
|顺序性|所有Server,同一消息发布顺序一致。
[/table]
[/size][/color][/b]
[b][color=olive][size=large]
zookeeper的工作原理,
1.每个Server在内存中存储了一份数据;
2.Zookeeper启动时,将从实例中选举一个leader(Paxos协议)
3.Leader负责处理数据更新等操作(Zab协议);
4.一个更新操作成功,当且仅当大多数Server在内存中成功修改数据。
[/size][/color][/b]
[b][color=green][size=large]
zookeeper中的几个重要角色:
[table]
|角色名|描述
|领导者(Leader)|领导者负责进行投票的发起和决议,更新系统状态,处理写请求
|跟随者(Follwer)|Follower用于接收客户端的读写请求并向客户端返回结果,在选主过程中参与投票
|观察者(Observer)|观察者可以接收客户端的读写请求,并将写请求转发给Leader,但Observer节点不参与投票过程,只同步leader状态,Observer的目的是为了,扩展系统,提高读取速度。
|客户端(Client)|执行读写请求的发起方
[/table]
[/size][/color][/b]
[b][color=olive][size=large]为什么,在3.3.0版本之后,引入Observer角色?
Zookeeper需保证高可用和强一致性;
为了支持更多的客户端,需要增加更多Server;
Server增多,投票阶段延迟增大,影响性能;
权衡伸缩性和高吞吐率,引入Observer
Observer不参与投票;
Observers接受客户端的连接,并将写请求转发给leader节点;
加入更多Observer节点,提高伸缩性,同时不影响吞吐率。
[/size][/color][/b]
[b][color=green][size=large]
为什么zookeeper集群的数目,一般为奇数个?
Leader选举算法采用了Paxos协议;
Paxos核心思想:当多数Server写成功,则任务数据写成功
如果有3个Server,则两个写成功即可;
如果有4或5个Server,则三个写成功即可。
Server数目一般为奇数(3、5、7)
如果有3个Server,则最多允许1个Server挂掉;
如果有4个Server,则同样最多允许1个Server挂掉
由此,我们看出3台服务器和4台服务器的的容灾能力是一样的,所以
为了节省服务器资源,一般我们采用奇数个数,作为服务器部署个数。
[/size][/color][/b]
[b][color=olive][size=large]
zookeeper的数据模型:
基于树形结构的命名空间,与文件系统类似
节点(znode)都可以存数据,可以有子节点
节点不支持重命名
数据大小不超过1MB(可配置)
数据读写要保证完整性
层次化的目录结构,命名符合常规文件系统规范;
每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识;
节点Znode可以包含数据和子节点(EPHEMERAL类型的节点不能有子节点);
Znode中的数据可以有多个版本,比如某一个路径下存有多个数据版本,那么查询这个路径下的数据需带上版本;
客户端应用可以在节点上设置监视器(Watcher);
节点不支持部分读写,而是一次性完整读写。
Znode有两种类型,短暂的(ephemeral)和持久的(persistent);
Znode的类型在创建时确定并且之后不能再修改;
短暂znode的客户端会话结束时,zookeeper会将该短暂znode删除,短暂znode不可以有子节点;
持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除;
Znode有四种形式的目录节点,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL。
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景一(统一命名服务)
分布式环境下,经常需要对应用/服务进行统一命名,便于识别不同服务;
类似于域名与ip之间对应关系,域名容易记住;
通过名称来获取资源或服务的地址,提供者等信息
按照层次结构组织服务/应用名称
可将服务名称以及地址信息写到Zookeeper上,客户端通过Zookeeper获取可用服务列表类
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景二(配置管理)
分布式环境下,配置文件管理和同步是一个常见问题;
一个集群中,所有节点的配置信息是一致的,比如Hadoop;
对配置文件修改后,希望能够快速同步到各个节点上
配置管理可交由Zookeeper实现;
可将配置信息写入Zookeeper的一个znode上;
各个节点监听这个znode
一旦znode中的数据被修改,zookeeper将通知各个节点
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景三(集群管理)
分布式环境中,实时掌握每个节点的状态是必要的;
可根据节点实时状态作出一些调整;
可交由Zookeeper实现;
可将节点信息写入Zookeeper的一个znode上;
监听这个znode可获取它的实时状态变化
典型应用
Hbase中Master状态监控与选举
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景四(分布式通知和协调)
分布式环境中,经常存在一个服务需要知道它所管理的子服务的状态;
NameNode须知道各DataNode的状态
JobTracker须知道各TaskTracker的状态
心跳检测机制可通过Zookeeper实现;
信息推送可由Zookeeper实现(发布/订阅模式)
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景五(分布式锁)
Zookeeper是强一致的;
多个客户端同时在Zookeeper上创建相同znode,只有一个创建成功。
实现锁的独占性
多个客户端同时在Zookeeper上创建相同znode ,创建成功的那个客户端得到锁,其他客户端等待。
控制锁的时序
各个客户端在某个znode下创建临时znode (类型为CreateMode.EPHEMERAL_SEQUENTIAL),这样,该znode可掌握全局访问时序。
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景六(分布式队列)
两种队列;
当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列。
队列按照 FIFO 方式进行入队和出队操作,例如实现生产者和消费者模型。(可通过分布式锁实现)
同步队列
一个job由多个task组成,只有所有任务完成后,job才运行完成。
可为job创建一个/job目录,然后在该目录下,为每个完成的task创建一个临时znode,一旦临时节点数目达到task总数,则job运行完成。
[/size][/color][/b]
Foundation(ASF)顶级项目,它主要提供以下的四个功能:
[table]
|功能名|
|组管理服务|
|分布式配置服务|
|分布式同步服务|
|分布式命名服务|
[/table]
Zookeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户;
Zookeeper的架构图如下:
[/size][/color][/b]
[img]http://dl2.iteye.com/upload/attachment/0091/8360/2f9be92b-4e1b-3d9e-b79d-40cbfe6c77ad.jpg[/img]
[b][color=green][size=large]
Zookeeper的特点如下:
[table]
|特点|说明|
|最终一致性|为客户端展示同一个视图,这是zookeeper里面一个非常重要的功能|
|可靠性|如果消息被到一台服务器接受,那么它将被所有的服务器接受。|
|实时性|Zookeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。|
|独立性|各个Client之间互不干预|
|原子性|更新只能成功或者失败,没有中间状态。|
|顺序性|所有Server,同一消息发布顺序一致。
[/table]
[/size][/color][/b]
[b][color=olive][size=large]
zookeeper的工作原理,
1.每个Server在内存中存储了一份数据;
2.Zookeeper启动时,将从实例中选举一个leader(Paxos协议)
3.Leader负责处理数据更新等操作(Zab协议);
4.一个更新操作成功,当且仅当大多数Server在内存中成功修改数据。
[/size][/color][/b]
[b][color=green][size=large]
zookeeper中的几个重要角色:
[table]
|角色名|描述
|领导者(Leader)|领导者负责进行投票的发起和决议,更新系统状态,处理写请求
|跟随者(Follwer)|Follower用于接收客户端的读写请求并向客户端返回结果,在选主过程中参与投票
|观察者(Observer)|观察者可以接收客户端的读写请求,并将写请求转发给Leader,但Observer节点不参与投票过程,只同步leader状态,Observer的目的是为了,扩展系统,提高读取速度。
|客户端(Client)|执行读写请求的发起方
[/table]
[/size][/color][/b]
[b][color=olive][size=large]为什么,在3.3.0版本之后,引入Observer角色?
Zookeeper需保证高可用和强一致性;
为了支持更多的客户端,需要增加更多Server;
Server增多,投票阶段延迟增大,影响性能;
权衡伸缩性和高吞吐率,引入Observer
Observer不参与投票;
Observers接受客户端的连接,并将写请求转发给leader节点;
加入更多Observer节点,提高伸缩性,同时不影响吞吐率。
[/size][/color][/b]
[b][color=green][size=large]
为什么zookeeper集群的数目,一般为奇数个?
Leader选举算法采用了Paxos协议;
Paxos核心思想:当多数Server写成功,则任务数据写成功
如果有3个Server,则两个写成功即可;
如果有4或5个Server,则三个写成功即可。
Server数目一般为奇数(3、5、7)
如果有3个Server,则最多允许1个Server挂掉;
如果有4个Server,则同样最多允许1个Server挂掉
由此,我们看出3台服务器和4台服务器的的容灾能力是一样的,所以
为了节省服务器资源,一般我们采用奇数个数,作为服务器部署个数。
[/size][/color][/b]
[b][color=olive][size=large]
zookeeper的数据模型:
基于树形结构的命名空间,与文件系统类似
节点(znode)都可以存数据,可以有子节点
节点不支持重命名
数据大小不超过1MB(可配置)
数据读写要保证完整性
层次化的目录结构,命名符合常规文件系统规范;
每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识;
节点Znode可以包含数据和子节点(EPHEMERAL类型的节点不能有子节点);
Znode中的数据可以有多个版本,比如某一个路径下存有多个数据版本,那么查询这个路径下的数据需带上版本;
客户端应用可以在节点上设置监视器(Watcher);
节点不支持部分读写,而是一次性完整读写。
Znode有两种类型,短暂的(ephemeral)和持久的(persistent);
Znode的类型在创建时确定并且之后不能再修改;
短暂znode的客户端会话结束时,zookeeper会将该短暂znode删除,短暂znode不可以有子节点;
持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除;
Znode有四种形式的目录节点,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL。
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景一(统一命名服务)
分布式环境下,经常需要对应用/服务进行统一命名,便于识别不同服务;
类似于域名与ip之间对应关系,域名容易记住;
通过名称来获取资源或服务的地址,提供者等信息
按照层次结构组织服务/应用名称
可将服务名称以及地址信息写到Zookeeper上,客户端通过Zookeeper获取可用服务列表类
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景二(配置管理)
分布式环境下,配置文件管理和同步是一个常见问题;
一个集群中,所有节点的配置信息是一致的,比如Hadoop;
对配置文件修改后,希望能够快速同步到各个节点上
配置管理可交由Zookeeper实现;
可将配置信息写入Zookeeper的一个znode上;
各个节点监听这个znode
一旦znode中的数据被修改,zookeeper将通知各个节点
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景三(集群管理)
分布式环境中,实时掌握每个节点的状态是必要的;
可根据节点实时状态作出一些调整;
可交由Zookeeper实现;
可将节点信息写入Zookeeper的一个znode上;
监听这个znode可获取它的实时状态变化
典型应用
Hbase中Master状态监控与选举
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景四(分布式通知和协调)
分布式环境中,经常存在一个服务需要知道它所管理的子服务的状态;
NameNode须知道各DataNode的状态
JobTracker须知道各TaskTracker的状态
心跳检测机制可通过Zookeeper实现;
信息推送可由Zookeeper实现(发布/订阅模式)
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景五(分布式锁)
Zookeeper是强一致的;
多个客户端同时在Zookeeper上创建相同znode,只有一个创建成功。
实现锁的独占性
多个客户端同时在Zookeeper上创建相同znode ,创建成功的那个客户端得到锁,其他客户端等待。
控制锁的时序
各个客户端在某个znode下创建临时znode (类型为CreateMode.EPHEMERAL_SEQUENTIAL),这样,该znode可掌握全局访问时序。
[/size][/color][/b]
[b][color=green][size=large]Zookeeper的应用场景六(分布式队列)
两种队列;
当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列。
队列按照 FIFO 方式进行入队和出队操作,例如实现生产者和消费者模型。(可通过分布式锁实现)
同步队列
一个job由多个task组成,只有所有任务完成后,job才运行完成。
可为job创建一个/job目录,然后在该目录下,为每个完成的task创建一个临时znode,一旦临时节点数目达到task总数,则job运行完成。
[/size][/color][/b]