|
ZooKeeper介绍
ZooKeeper是一个分布式服务协调框架，主要用来解决分布式应用中的一些数据管理问题。
Zookeeper数据结构
Zookeeper的数据节点可以视为树状（或者目录）结构，树中的各节点被称为znode（即zookeeper node）.其中znode兼具文件和目录两种特点。 1.可以像文件一样维护着数据、元信息、ACL、时间戳等数据结构 2.可以像目录一样挂载子目录
一个znode大体上分为3各部分：
1.data：当前节点的数据
2.children：当前节点的子节点
3.stat：当前节点的状态，用来描述当前节点的创建、修改记录等
节点分类方式
一、是否持久化分类
持久化节点：（默认）该节点的生命周期不依赖于会话，并且只有在客户端执行删除操作的时候，它们才能被删除
临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除
二、是否有序进行分类
有序节点：每个节点都会为它的子节点维护一个顺序
无序节点：（默认）节点不会为子节点维护顺序
常见命令
1.创建节点
默认创建节点：默认持久无序节点
2.查看节点
get path : 获取节点的状态信息和数据信息
stat path : 获取节点的状态信息
3.查看节点列表
ls path: 查看指定节点的子节点列表
ls2 path: 就相当于（ls + stat ）
4.修改节点
zookeeper的节点修改，支持乐观锁
(1) set path data 直接使用set命令对指定节点内容进行修改
(2)set path data version 基于版本号对指定节点内容进行修改
5.删除节点
(1)delete path 使用delete命令删除指定节点
(2)delete path version 基于版本号删除指定节点
(3)rmr path 递归删除
监听节点
zookeeper中支持一种watch（监听）机制，它允许对zookeeper注册监听，当监听的对象发生指定的事件的时候，zookeeper就会返回一个通知。
它可以监听事件类型包含下面这些:
- None:客户端和服务端连接状态发生变化
- NodeCreated:创建节点
- NodeDeleted:删除节点
- NodeDataChanged:节点数据发生变化（dataVersion）
- NodeChildrenChanged:子节点发生变化(创建\删除\数据变更)
get path watch： 监听器在监听节点内容发生改变时，向客户端发出通知
stat path watch：状态改变时
ls/ls2 path watch：子节点新增和删除时
Zookeeper的事件监听机制有以下特性：
-
当监听器监听的事件被触发,服务端会发送通知给客户端,但不包括事件的具体内容。 -
Watcher是一次性的。一旦被触发将会失效。如果需要反复进行监听就需要反复进行注册。
节点监听
watch机制
zookeeperwatch机制，一个轻量级的设计。因为它采用了一种推拉结合的模式。
服务端只会发送事件类型和节点信息给关注的客户端，不包括变更内容。这就是推的部分。
收到变更通知的客户端要自己去拉变更的数据。这是拉的部分。
Curator框架
Cache的概念用来实现对ZooKeeper服务器端进行事件监听。
1.Cache是Curator对事件监听的包装，其对事件的监听可以近似看做是一个本地缓存视图和远程ZooKeeper视图的对比过程。
2.Curator会自动的再次监听，手动的重复监听了。
Curator中的cache共有三种:
NodeCache: 用来**监听节点**的创建和数据变化 get /node watch
PathChildrenCache: 用来监听**指定节点的子节点**增删和数据变化 ls /node watch
TreeCache: 像**上面两种Cache的结合体**，能够监听自身节点的变化、也能够监听子节点的变化 （get + ls ） watch
Zookeeper应用场景
ID生成器
通过在ZooKeepr里创建顺序节点，很容易创建一个全局唯一的名字，即生成全局唯一的ID。
配置中心
目的：
防止修改过多的配置文件
方案：
? 可以把所有的配置都放在一个配置中心，然后各个服务分别去监听配置中心，一旦发现里面的内容发生变化，立即获取变化的内容，然后更新本地配置即可
实现：
? 通过Zookeeper的watch机制
所有的服务监听Zookeeper的配置节点，当配置信息改变时，Zookeeper会将变化信息推送给服务，服务也可自己去拉取
后期使用SpringCloud提供**SprignCloudBus+ ** , 阿里nacos 用于配置中文，使用起来更加简单易用
集群选主
1.所有参与选主的主机都去Zookeeper上创建同一个临时节点
2.成功创建节点的客户端所在的机器就成为了Master，其他为 从
3.所有的从节点都会在主节点上注册一个子节点变更的Watcher
分布式锁
应用场景：下单扣减库存；清理未支付超时订单（恢复库存）
分布式锁特点：（zookeeper，redis-setnx）
- 多进程可见
- 排他性:同一时间只允许一个进程执行业务
- 高可用
zookeeper基于watcher机制和znode的有序节点，天生满足分布式锁条件。首先创建一个/test/lock父节点作为一把锁，尽量是持久节点（PERSISTENT类型），每个尝试获取这把锁的客户端，在/test/lock父节点下创建临时顺序子节点。
由于序号的递增性，我们规定序号最小的节点即获得锁。
缺点：
zookeeper分布式锁和redis分布式锁相比，因为大量的创建、删除节点性能上比较差，并不是很推荐。
Zookeeper集群
集群介绍
Zookeeper在一个系统中一般会充当一个很重要的角色，所以一定要保证它的高可用，这就需要部署Zookeeper的集群。
Zookeeper 有三种运行模式：单机模式、集群模式和伪集群模式。
- 单机模式：使用一台主机不是一个Zookeeper来对外提供服务，有单点故障问题，仅适合于开发、测试环境
- 集群模式：使用多台服务器，每台上部署一个Zookeeper一起对外提供服务，适合于生产环境
- 伪集群模式：在服务器不够多的情况下，也可以考虑在一台服务器上部署多个Zookeeper来对外提供服务
|