Zookeeper是什么？
将其定义为分布式协调
简单来说，就是一个分布式系统下，有多个节点，每个节点一个请求，但是所有的节点只能确定一个请求被通过，而这个而通过的是所有节点达成一致的结果。
Google Chubby（不开源产品）其解决了分布式一致性
我们有多个不同的数据节点，如果我们去发起创建订单和扣减库存这两个动作，它分别落在不同的节点，如果我们要保证数据的一致性，可以考虑使用这种方案。其实就是解决分布式场景下达成一致的方式。
我们如何在不可靠的分布式场景中，基于某一个提议达成一致，这个一致是每一个节点都需要赞同的。
zookeeper是协调分布式下多个节点之间访问顺序的问题，所以也叫顺序一致性的中间件。而这个方式有点像实现锁的方式，所以zookeeper也能实现分布式锁，所以本质上其实就是一种锁的服务。
zookeeper是一种cp模型
怎么去设计
leader
- 整个集群中的调度节点
- 数据同步
follower
- 高可用特性
- 参与投票（leader选举的投票，数据达成一致的投票）
- 处理客户端的请求（提升集群性能）这样设计到扩容，但是并不是节点越多性能越好，因为涉及到了数据同步，这里面有一个思想叫做 过半提交 ，比如当发起一个操作的时候，整个集群中至少要有过半的节点认为这是成功的，才会成功返回给后端，也就会导致follower会参与到这个过程中来。正是因为这样，如果盲目的扩容，最终就会导致因为过多的follower参与而导致性能下降。
Observer
主要是为了解决 增加follower节点而导致的性能问题，其并不需要参与投票，但是会参与数据的同步，只需要跟leader节点保持一致。简单来说，observer服务器只提供非事务请求服务，通常在于不影响集群事物事务处理能力的前提下提升集群非事务处理的能力。
如果超过了半数，那么就认为事务是成功的，那么就返回。
提交事务
如果是过半提交，那么就意思着其不是强一致的。如果是强一致的话，就必然影响到整个集群的吞吐和性能。
而这个方式就是一个典型的2pc协议。
2pc协议是一个强一致性协议，如果想实现2pc，在这里的情况就是所有的节点都必须要成功，如果有一个失败，那么就不行，协议定义的是一种规范和标准。所以zookeeper也是使用了2pc的方式，只不过它是改进版本的，不需要全部成功，只需要过半就可以了。
集群组成
怎么要满足过半，所以一般是由2n+1台server组成，每个server都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。对于2n+1台server，只要有n+1台（大多数）server可用，整个系统保持可用。我们已经了解到，一个zookeeper集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信，基于这个特性，如果向搭建一个能够允许F台机器down掉的集群，那么就要部署2*F+1台服务器构成的zookeeper集群。
因此3台机器构成的zookeeper集群，能够在挂掉一台机器后依然正常工作。一个5台机器集群的服务，能够对2台机器怪调的情况下进行容灾。如果一台由6台服务构成的集群，同样只能挂掉2台机器。因此，5台和6台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的server会选举出一台server为Leader，其它的就作为follower（这里先不考虑observer角色）。
之所以要满足这样一个等式，是因为一个节点要成为集群中的leader，需要有超过及群众过半数的节点
支持，这个涉及到leader选举算法。同时也涉及到事务请求的提交投票
安装部署
部署好后，连接发现
这就意味着zookeeper可以存储一些数据在里面，可以针对性的对数据进行一些操作。
数据结构
key代表名字，value代表值
当dubbo作为服务中心的时候，会像zookeeper写入一些信息
它还有临时节点（生命周期） 、持久化节点、以及有序节点(递增的序列号）。
对于其树形结构来说，先有父节点，再有子节点，当然临时节点下不能存在子节点（如果临时节点失效了，那么子节点怎么办呢？）。
同级节点下，节点名字必须是唯一的。
当了解了节点，除了做注册中心，还可以做配置中心
所以以上就是 服务注册 和 配置中心的简单示意图。
学到这里，其实技术是存在一个取舍的，但是功能是可以实现的，甚至用数据库来实现其实都可以，无非就是一个统一的存储，然后做个监听数据的变化，那么我们可以监听数据库的变化呀，去触发一些动作也没什么问题，只不过就是会复杂一些，可行性是有的。
剩下的就是针对对应的节点做crud了。
create /nhs create /nhs/test "test" create [-s] [-e] [-c] [-t ttl] path [data] [acl] -s：表示创建的 znode 为顺序节点，即在节点名称后面添加一个自增的数字后缀； -e：表示创建的 znode 为临时节点，即客户端与 ZooKeeper 断开连接后，该节点会自动删除； -c：表示创建的 znode 为容器节点，即该节点可以拥有子节点； -t ttl：表示创建的 znode 有一个 TTL（Time To Live）值，即生存时间，超过该时间后节点将被删除； path：表示新创建的 znode 的路径； data：表示新创建的 znode 的数据内容； acl：表示新创建的 znode 的 ACL（Access Control List），即访问控制列表。
Zookeeper可以解决那些实际问题
有序队列的使用场景
有序节点： 全局ID
分布式锁 （ZooKeeper中的有序节点能够用于实现分布式锁的主要原因在于其顺序临时节点的特性。当多个客户端尝试创建有序临时节点时，ZooKeeper会为每个节点赋予一个唯一的递增顺序号，并且客户端创建的节点将按照顺序号从小到大排列。）
基于这一特性，可以利用ZooKeeper有序节点来实现分布式锁的过程如下：
- 每个客户端需要获取锁时，在指定的ZooKeeper节点下创建一个有序临时节点。
- 客户端可以通过获取当前指定节点下所有子节点，并且判断自己创建的节点是否为序号最小的节点，如果是，则表示客户端获得了锁；否则，客户端需要监听比自己序号小的节点的变化事件。
- 如果前面的节点释放了锁，那么其它客户端对应创建的节点会收到通知，进而继续尝试获取锁。
分布式队列
同级节点的唯一性
分布式锁
节点元数据
stat /nhs 显示节点的元数据 cZxid = 0x6 //节点被创建的事务zxid ctime = Sat Sep 05 21:26:15 CST 2020 //创建时间 mZxid = 0x6 //修改的事务id mtime = Sat Sep 05 21:26:15 CST 2020 //修改时间 pZxid = 0x8 //子节点列表中最后一次被修改的zxid cversion = 1 //子节点版本号 (乐观锁) dataVersion = 0 //当前节点版本号 aclVersion = 0 //权限版本号 ephemeralOwner = 0x0 //临时节点的所属会话 dataLength = 0 //数据的长度 numChildren = 1 //子节点数量（当前节点）
watcher(监听机制)
比如服务注册，有两个难点
1.服务的管理
2.服务的上下线感知
当我的服务提供者发生上下线变化的时候，那么需要去感知移除那个，最好的设置方式就是临时节点，当服务挂掉的时候，不需要去触发什么东西，zookeeper会去检测其心跳。
其中service provider是持久化节点。
上图的这个机制就叫做watcher
zookeeper提供了分布式数据的发布/订阅功能，zookeeper允许客户端向服务端注册一个watcher监听，当服务端的一些指定事件触发了watcher，那么服务端就会向客户端发送一个事件通知。
值得注意的是，Watcher通知是一次性的，即一旦触发一次通知后，该Watcher就失效了，因此客户端需要反复注册Watcher，即程序中在process里面又注册了Watcher，否则，将无法获取c3节点的创建而导致子节点变化的事件。
配置中心的变更也是这样
配置中心能够应用主要是其 key value结构。
