zookeeper简介
1、什么是zookeeper
ZooKeeper 是一个分布式的，开放源码的分布式应用程序协同服务。
ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服 务封装起来，构成一个高效可靠的原语集，并以一系列简单易用 的接口提供给用户使用。
2、zookeeper的使用场景
2.1、数据发布/订阅，配置中心
1、发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订阅。
2、Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知后，主动到服务端获取最新的数据。
2.2、分布式锁
1、排它锁也叫独占锁
① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成功的客户端需要注册/exclusive_lock节点监听。
② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获取。
2、读写锁
① 获取锁，在需要获取共享锁时，所有客户端都会到/shared_lock下面创建一个临时顺序节点，如果是读请求，那么就创建例如/shared_lock/host1-R-00000001的节点，如果是写请求，那么就创建例如/shared_lock/host2-W-00000002的节点。
② 判断读写顺序
1. 创建完节点后，获取/shared_lock节点下所有子节点，并对该节点变更注册监听。
2. 确定自己的节点序号在所有子节点中的顺序。
3. 对于读请求：若没有比自己序号小的子节点或所有比自己序号小的子节点都是读请求，那么表明自己已经成功获取到共享锁，同时开始执行读取逻辑，若有写请求，则需要等待。对于写请求：若自己不是序号最小的子节点，那么需要等待。
4. 接收到Watcher通知后，重复步骤1。
③ 释放锁，其释放锁的流程与独占锁一致。
两种锁如何避免羊群效应？
1、独占锁：
2、读写锁呢？
2.2.3、一主多从，master-worker协同
- 使用一个临时节点/master表示master。master在行使master的职能之前，首先要创建这个znode。如果能 创建成功，开始行使master职能。
- worker通过在/workers下面创建临时节点来加入集群
- master会通过watch机制监控/workers下面的worker节点列表来实时获取worker成员的变化。
2.2.4、kafak如何使用zookeeper
1、master-worker模式
一个Kafka集群由多个broker组成，这些borker是系统中的worker。Kafka会从这些worker选举出一个 controller，这个controlle是系统中的master，负责把topic和partition分配给各个broker。
2、Topic注册
Topic的消息会被分成多个分区并将其分布在多个Broker上，这些分区信息及与Broker的对应关系也都是由Zookeeper在维护。
3、消费分区与消费者的关系，消息消费位移记录
同一个消费者组内，每个分区只能有一个消费者进行消费，每条消息只被消费一次，所以消费者和消费分区之间的关系也写入zookeeper。
zookeeper中的重要概念
数据模型
ZooKeeper 使用文件系统模型，Datatree。Datatree 的每个节点叫作 znode。每个节点都可以保存数据。每个节点都有一个版本 (version)。版本从 0 开始计数。
基于版本号的条件更新
znode节点
- 持久性的 znode (PERSISTENT): ZooKeeper 宕机，或者 client 宕机，这个 znode 一旦创建就不会丢失。
- 临时性的 znode (EPHEMERAL): ZooKeeper 宕机了，或者 client 在指定的 timeout 时间内没有连接 server ，都会被认为丢失。
znode 节点也可以是顺序性的。每一个顺序性的 znode 关联一个唯一的单调递增整数。这个单调递增整 数是 znode 名字的后缀。 - 持久顺序性的 znode(PERSISTENT_SEQUENTIAL): znode 除了具备持久性 znode 的特点之外，znode 的名字具备顺序性。
- 临时顺序性的 znode(EPHEMERAL_SEQUENTIAL): znode 除了具备临时性 znode 的特点之外，znode 的名字具备顺序性。
standalone 模式和 quorum模式
quorum模式要求至少3个节点
其中2181是默认客户端服务端口，3333是quorum之间的通信，3334是用于leader选举的端口。
服务器节点角色与区别
事务日志和快照
zookeeper数据一致性
1、CAP理论下，zookeeper是如何工作的。
2、zookeeper的数据一致性
• 可线性化(Linearizable)写入:先到达 leader 的写请求会被先处理，leader 决定写请求的执 行顺序。
• 客户端FIFO顺序:来自给定客户端的请求按照发送顺序执行。
3、ZAB协议
1、2PC,3PC,Paxos,Raft算法
2、ZAB（ZooKeeper Atomic Broadcast）协议
- Leader发送PROPOSAL给集群中所有的节点。
- 节点在收到PROPOSAL之后，把PROPOSAL落盘,发送一个ACK给Leader。
- Leader在收到大多数节点的ACK之后，发送COMMIT给集群中所有的节点。
Leader选举
1、Vote投票包含的信息：sid（服务器ID），zxid（事务ID），epoch（leader周期）
2、投票过程
一个ZooKeeper节点通过向所有的节点发送vote开始选举
一个节点在接收到vote之后如果发现接收到的投票新，就把自己的投票更新成最新的投票，并把vote发送给所有的ZooKeeper节点。否则的话，什么也不用做。
如何判断一个投票是新的？
一个3节点集群选举一个leader的时序图:
3、脑裂-长时间的消息发送延迟导致选举出两个leader
