重要概念
- 分布式，半数以上节点存活，就可以正常服务
- 用集群来保证高可用
- 数据存储在内存，保证了高吞吐量和低延迟
- 高性能，适合读多于写的场景，也是协调服务的典型场景
- 临时节点，会话结束临时节点删除。持久节点只有主动移除才可删除
- 管理（存储、读取）用户程序提交的数据；为用户程序提供数据节点监听服务
会话
- TCP长连接
- 心跳检测来保持会话，也能够向ZK服务器发送请求并接受响应，同时还能够通过该连接接受来自服务器的Watch事件通知。
数据模型 Znode
- PERSISTENT 持久化节点，节点创建后，不会因为会话失效而消失
- EPHEMERAL 临时节点， 客户端session超时此类节点就会被自动删除
- EPHEMERAL_SEQUENTIAL 临时自动编号节点
- PERSISTENT_SEQUENTIAL 顺序自动编号持久化节点，这种节点会根据当前已存在的节点数自动加 1
编号的唯一性保障
雪花算法
- 第一位
占用1bit，其值始终是0，没有实际作用。
- 时间戳
占用41bit，精确到毫秒，总共可以容纳约69年的时间。（当前时间 - 开始时间）
- 工作机器id
占用10bit，最多可以容纳1024个节点。
- 序列号
占用12bit，最多可以累加到4095。这个值在同一毫秒同一节点上从0开始不断累加。
Watcher
当创建一个节点时，可以注册一个该节点的监视器，当节点状态发生改变时，watch被触发时，ZK将会向客户端发送且仅发送一条通知，因为watch只能被触发一次。
分布式锁
根据zookeeper的这些特性，实现分布式锁：
- 创建一个锁目录lock
- 线程A获取锁会在lock目录下，创建临时顺序节点
- 获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁
- 线程B创建临时节点并获取所有兄弟节点，判断自己不是最小节点，设置监听(watcher)比自己次小的节点（只关注比自己次小的节点是为了防止发生“羊群效应”）
- 线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是最小的节点，获得锁
Curator
Curator 是一个 ZK 的开源客户端，提供了分布式锁的实现。实现分布式锁的底层原理和上面分析差不多。
-
获取当前所有节点排序后的集合
-
判断当前节点是否是最小的节点，是则获取锁
-
没获取到锁，对当前节点的上一个节点注册一个监听器
版本
ACL
权限控制
特点
- 顺序一致性
- 原子性
- 单一系统映像
- 可靠性
设计目标
- 简单的数据模型
- ZK允许分布式进程通过共享的层次结构命名空间进行相互协调，
- 可构建集群
- 顺序访问
- 高性能
集群角色介绍
- Leader
- 事务请求的唯一调度和处理者，保证集群事务处理的顺序性；
- 集群内部各服务器的调度者
- Follower
- 处理客户端非事务请求，转发事务请求给Leader服务器
- 参与事务请求Proposal的投票
- 参与Leader选举的投票
- Observer
- 不参与Leader选举，不参与过半策略，提高集群读性能
ZAB协议
- Leader election（选举阶段）：节点在一开始都处于选举阶段，只要有一个节点得到超过半数节点的票数，它就可以单选准leader。
- Discovery（发现阶段）：在这个阶段，followers跟准Leader进行通信，同步followers最近接收的事务提议。
- Synchronization（同步阶段）：同步阶段主要是利用leader前一阶段获得的最新提议历史，同步集群中所有的副本，同步完成之后准leader才会真正的leader。
- Broadcast（广播阶段）到了这个阶段，Zookeeper集群才能正式对外提供事务服务，并且leader可以进行消息广播，同时如果有新的节点加入，还需要对新节点进行同步。
崩溃恢复和消息广播
- 状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。
- 当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进入消息广播模式了。
使用场景
- 分布式协调
- A系统发送个请求到MQ，然后B消息消费之后处理了。A系统发送请求之后可以在ZK上对某个节点的值注册个监听器，一旦B系统处理完了就修改ZK那个节点的值，A立马就可以收到通知；
- 分布式锁
- 多台机器同时修改一份数据，就需要分布式锁，首先其中一台机器可以去创建一个临时的znode，接着执行操作，然后另外一个机器也尝试去创建那个znode，结果发现自己创建不了，就只能等待；
- 元数据/配置信息管理
- ZK可以用作很多系统的配置信息的管理，比如Kafka、Storm等等很多分布式系统都会选用ZK来做一些元数据、配置信息的管理，包括Dubbo注册中心。
- HA高可用性
- ZK来开发HA高可用机制，就是一个重要进程一般会做主备两个，主进程挂了立马通过ZK感知到切换到备用进程。
默认端口号
代码访问client的端口号： 2181 leader和flower通信的端口号： 2888 选举leader时通信的端口号： 3888 其他服务与监控中心通信端口： 7070
