zookeeper入门

1、ZooKeeper

为分布式应用提供一致性服务的软件，提供的功能包括：
配置维护、域名服务、分布式同步、组服务等。
从本质来说，ZooKeeper就是一个第三方，也称中间人，它搭建了一个平台，让所有其它进程通过它来进行间接的交流。

1.1 ZooKeeper的数据模型

1.2 ZooKeeper应该具备的能力

• zookeeper应该有基本消息通知：
  监视节点、通知进程、保持长连接，会话延续等
• 工作过程
  业务进程启动后与zookeeper建立连接，然后在zookeeper里创建临时节点并写入自己的相关信息。接着通过周期性的心跳和zookeeper保持住连接。
  一旦业务进程挂掉，zookeeper将接受不到心跳了，那么在超过一定的时间后，zookeeper将会删除与之对应的临时节点，表示这个业务进程不再可用了。

1.3 Zookeeper的特性

• 树状目录结构
  Zookeeper是一个树状的文件目录结构，有点想应用系统中的文件系统的概念。每个子目录（如App）被称为znode，我们可以对每个znode进行增删改查。
• 持久节点(Persistent)
  客户端与Zookeeper服务端断开连接后，该节点仍然存在。
• 持久有序节点(Persistent_sequential)
  在持久节点基础上，由zookeeper给该节点名称进行有序编号，如0000001，0000002。
• .临时节点(Ephemeral)
  客户端与Zookeeper服务端断开连接后，该节点被删除。临时节点下，不存在子节点。
• .临时有序节点(Ephemeral_sequential)
  在临时节点基础上，由Zookeeper给该节点名称进行有序编号，如0000001，0000002。

2、特性

2.1 功能

• 集群管理
  监控节点存活状态、运行请求等；
• 主节点选举
  主节点挂掉了之后可以从备用的节点开始新一轮选主，
  主节点选举说的就是这个选举的过程
• 分布式锁
  Zookeeper 提供两种锁：独占锁、共享锁。独占锁即一次只能有一个线程使用资源，共享锁是读锁共享，读写互斥，即可以有多线线程同时读同一个资源，如果要使用写锁也只能有一个线程使用。
  * 服务命名

2.2、ZAB协议

支持崩溃恢复的原子广播协议
包括两种基本的模式：

• 崩溃恢复
  当整个 Zookeeper 集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与 Leader 服务器保持正常通信时，所有服务器进入崩溃恢复模式，首先选举产生新的 Leader 服务器，然后集群中 Follower 服务器开始与新的 Leader 服务器进行数据同步。
• 消息广播
  当集群中超过半数机器与该 Leader 服务器完成数据同步之后，退出恢复模式进入消息广播模式，Leader 服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。

2.3 怎么保证主从节点的状态同步

• 恢复模式
  当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。
• 广播模式
  一旦 leader 已经和多数的 follower 进行了状态同步后，它就可以开始广播消息了，即进入广播状态。
  这时候当一个 server 加入 ZooKeeper 服务中，它会在恢复模式下启动，发现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。
  ZooKeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。

2.4、zk的部署模式

• 单机部署：一台集群上运行
• 集群部署：多台集群运行；
• 伪集群部署：一台集群启动多个 Zookeeper 实例运行。

2.5、Zookeeper 的通知机制

client 端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些 client 会收到 zk 的通知，然后 client 可以根据 znode 变化来做出业务上的改变等

2.6、集群中有 3 台服务器，其中一个节点宕机，这个时候 Zookeeper 还可以使用吗？**

可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。
集群规则为 2N+1 台，N >0，即最少需要 3 台。

微服务中应用场景

1.分布式锁
分布式锁主要解决不同进程中的资源同步问题。大家可以联想一下单进程中的多线程共享资源的情况，线程需要访问共享资源，首先要获得锁，操作完共享资源后便释放锁。

步骤1: 如图，根据Zookeeper有序临时节点的特性，每个进程对应连接一个有序临时节点（进程1对应节点/znode/00000001，进程2对应节点/znode/00000002…如此类推）。
每个进程监听对应的上一个节点的变化。编号最小的节点对应的进程获得锁，可以操作资源。

步骤2: 当进程1完成业务后，删除对应的子节点/znode/00000001，释放锁。此时，编号最小的锁便获得锁（即/znode/00000002对应进程）。
重复以上步骤，保证了多个进程获取的是同一个锁，且只有一个进程能获得锁，就是Zookeeper分布式锁的实现原理。

2.服务注册与发现

在微服务中，服务提供方把服务注册到Zookeeper中心去如图中的Member服务，但是每个应用可能拆分成多个服务对应不同的Ip地址，Zookeeper注册中心可以动态感知到服务节点的变化。
服务消费方（Order 服务）需要调用提供方（Member 服务）提供的服务时，从Zookeeper中获取提供方的调用地址列表，然后进行调用。这个过程称为服务的订阅。

• 服务注册原理
  

rpc框架会在Zookeeper的注册目录下，为每个应用创建一个持久节点，如order应用创建order持久节点，member应用创建member持久节点。
然后在对应的持久节点下，为每个微服务创建一个临时节点，记录每个服务的URL等信息。

• 服务动态发现原理