zookeeper 入门与实践 （一）

1、可以用作复杂的集群系统的注册中心，检测服务实例的健康状态，更新健康服务实例给调用方。

2、系统集群环境下可用来做分布式锁，避免同一份资源被多个线程同时篡改，导致数据变更和预期不符。

3、配置中心，多个服务使用同一套配置，不用每个服务管理一套维护起来太麻烦，修改还得改代码，重启项目，使用zk统一管理修改方便、提高效率。

4、分布式队列，微服务中处理业务需要保证先进先出的顺序性，可以让所有待执行业务在zk上建立临时节点，按顺序执行一个删除一个。

• 持久节点（PERSISTENT）

  默认的节点类型。创建节点的客户端与zookeeperr断开连接后，该节点依旧存在。

• 持久节点顺序节点（PERSISTENT_SEQUENTIAL)

  所谓顺序节点，就是在创建节点时，zookeeper根据创建的时间顺序给该节点名称进行编号

• 临时节点（EPHEM ERAL）

  和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。

• 临时顺序节点（EPHEMERAL_SEQUENTIAL）

  临时顺序节点结合和临时节点和顺序节点的特点：在创建节点时，zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。使用场景：

  可以用作分布式锁，所有线程在zk上建立临时节点，编号最小的节点获取到锁执行程序，后面的节点检测检测自己上一个节点，上一个节点删除后即可得到锁，如果获取到锁的节点崩溃掉后，临时节点特性，会自动删除断开连接的节点，不会造成死锁。

Leader 角色

Leader 服务器是zk集群工作的核心，其主要工作有两个：

• 事务请求的唯一调度者和处理者，保证集群事务处理的顺序性。
• 集群内部各个服务器的调度者

Follower 角色
Follower 是 zk 集群的跟随者，其主要工作有三个：

• 处理客户端非事务性请求，转发事务请求给 Leader 服务器（事务请求都由 Leader 处理）
• 参与事务请求 Proposal 的投票
• 参与 Leader 选举投票

Observer 角色
Observer 充当观察者角色，观察 zk 集群的最新状态变化并将这些状态同步过来，对于非事务请求可以进行独立的处理，对于事务请求，则会转发给 Leader 服务器进行处理，Observer 不会参与任何形式的投票，包括事务请求 Proposal 的投票和 Leader 选举的投票。

LOOKING
寻找 leader 状态
当前服务器处于该状态时，它会认为当前集群中没有 leader，因此需要进入 leader 选举状态。

leader 选举的两种场景（选举规则，每个节点有两个状态值事务 id 和选举 id，先比较事务 id,大的作为leader，事务 id 一致再比较选举 id）：

• 集群启动时选举，分为同时启动和逐一启动两种（集群启动时，每个节点事务 id 都是一致的）
  • 同时启动，选举 id 大的作为 leader。
  • 逐一启动，启动超过一半时就已经按照规则选出 leader，后面启动的均为 Follower
• 集群工作时，leader 宕机选举，按照规则选举，事务 id 大为 leader,事务 id 一致比较选举 id。

FOLLOWING
跟随者状态
表示当前服务器的角色是 Follower 角色

LEADING
领导者状态
表示当前服务器是 Leader

OBSERVING
观察者状态
表示当前服务器角色是 Observer