Zookeeper:
管理分布式环境下多种多样的服务
Apache ZooKeeper的系统为分布式协调是构建分布式应用的高性能服务。
zooKeeper本质上是一个分布式的小文件存储系统.提供基于类似于文件系统的目录树方式的数据存储,可以对树中的节点进行有效的管理.可以维护和监控存储的数据的状态变化.通过对这些数据状态的变化从而达到基于数据集群管理
适用于存储和协同相关的关键数据,不使用与大数据量存储
集中式系统:
整个项目就是一个独立的应用,整个应用就是整个项目,所有的东西都在一个应用里面,部署到一个服务器上
分布式:
例如: 单独的一个系统处理订单,一个处理登录,一个处理后台,每一个模块都是单独在一个tomcat中跑,合起来就是一个完整的大项目
总结:
- 多台计算机构成
- 计算机之间通过网络进行通信
- 彼此进行交互
- 共同目标
应用场景:
- 注册中心:
分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构。通过调用Zookeeper提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。 阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表。
- 配置中心
数据发布/订阅即所谓的配置中心：发布者将数据发布到ZooKeeper一系列节点上面，订阅者进行数据订阅，当数据有变化时，可以及时得到数据的变化通知，达到动态获取数据的目的。
ZooKeeper 采用的是推拉结合的方式。
1、推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知
2、拉: 客户端获得通知后，然后主动到服务端拉取最新的数据
负载均衡:
通过负载均衡算法,将某种资源的访问分摊给不同的设备,从而减轻单点的压力.
Zookeeper数据结构:
使用文件系统模型
- 文件系统模型的树形结构便于表达数据之间的层次关系
- 便于为不同的应用分配独立的命名空间
Zookeeper的层次模型称为data tree
Datatree的每个节点叫做znode, 不同文件系统,每个节点都可以保存数据.每个节点都有一个版本,版本从0开始计数
节点的分类:
Znode分为持久性和临时性
- 持久性: PERSISTENT,一但创建不会丢失,永久性存在,无论是zookeeper宕机还是dlient宕机
- 临时性: EPHEMERAL, 如果zookeeper宕机,或者client在指定的时间内没有连接servier,都会被认为丢失
Znode可以是顺序性的,每个顺序性的znode关联一个唯一的单调递增整数,这个单调递增整数是znode名字的后缀
Znode的名称具备顺序性
- 持久顺序性znode(PERSISTENT_SEQUENTIAL),znode 处理具备持久性的znode的特点
- 临时顺序性的znode(EPHEMERAL_SEQUENTIAL):znode处理具备临时性的znode特点
Zookeeper相关命令: 客户端 (znode翻译: 数据节点|文件)
help ----> 查询所有zookeeper所有命令
Ls ----> 查询根路径下的节点
Ls /zookeeper ----> 查找zookeeper节点下的节点
create [-s] [-e] [-c] [-t ttl] path [data] [acl]
create /节点名 “文件内容” ----> 创建普通永久节点
create -s /节点名 “文件内容” ----> 创建带序号的永久节点
-s ----> 创建带序号的节点
-e ----> 创建临时节点
-s -e ----> 创建临时且带序号的节点
path ----> 表示节点名,前面需要加/
data--->表示修改的数据,需要用 ” ”
get [-s] [-w] path 查询节点数据
set [-s] [-v version] path data 修改节点数据
delete [-v version] path 删除节点
delete path 在执行一次rmr path ----> 递归删除
查看节点状态:
stat path -----> 查看节点状态
节点的状态又称为stat结构体
Watch机制:
Zookeeper订阅-发布功能: 就是观察者模式
zookeeper的订阅发布也就是watch机制，是一个轻量级的设计。因为它采用了一种推拉结合的模式。一旦服务端感知主题变了，那么只会发送一个事件类型和节点信息给关注的客户端，而不会包括具体的变更内容，所以事件本身是轻量级的，这就是所谓的“推”部分。然后，收到变更通知的客户端需要自己去拉变更的数据，这就是“拉”部分。watche机制分为添加数据和监听节点。
Curator在这方面做了优化，Curator引入了Cache的概念用来实现对ZooKeeper服务器端进行事件监听。
Curator中的cache共有三种:
NodeCache（监听和缓存根节点变化）
PathChildrenCache（监听和缓存子节点变化）
TreeCache（监听和缓存根节点变化和子节点变化）
zookeeper集群模式：
Zookeeper 集群搭建指的是 ZooKeeper 分布式模式安装。 通常由 2n+1台 servers 组成。 这是因为为了保证 Leader 选举（基于 Paxos 算法的实现） 能或得到多数的支持，所以 ZooKeeper 集群的数量一般为奇数。
伪分布式集群搭建：
所谓伪分布式集群搭建ZooKeeper集群其实就是在一台机器上启动多个ZooKeeper，在启动每个ZooKeeper时分别使用不同的配置文件zoo.cfg来启动,每个配置文件使用不同的配置参数(clientPort端口号、dataDir数据目录.
在zoo.cfg中配置多个server.id，其中ip都是当前机器，而端口各不相同，启动时就是伪集群模式了。
这种模式和单机模式产生的问题是一样的。也是用在测试环境中使用。
完全分布式集群模式:
多台机器各自配置zoo.cfg文件，将各自互相加入服务器列表，每个节点占用一台机器
Leader:Zookeeper(领导者):集群工作的核心
事务请求（写操作） 的唯一调度和处理者，保证集群事务处理的顺序性； 集群内部各个服务器的调度者。 对于 create， setData， delete 等有写操作的请求，则需要统一转发给leader 处理， leader 需要决定编号、执行操作，这个过程称为一个事务。
Follower（跟随者）
处理客户端非事务（读操作） 请求，转发事务请求给 Leader；参与集群 Leader 选举投票 2n-1台可以做集群投票。
Observer:观察者角色
针对访问量比较大的 zookeeper 集群， 还可新增观察者角色。观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader服务器进行处理。 不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。
