zookeeper就是分布式的注册中心
配置文件
tickTime=2000 initLimit=10 syncLimit=5 dataDir=/app/soft/zookeeper-3.4.6/data （换成真实输出目录） clientPort=2181
#tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳，以毫秒为单位。 #initLimit：LF初始通信时限，集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量） #syncLimit：集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。 #dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。 #clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。 #dataLogDir：日志文件目录，Zookeeper保存日志文件的目录 #服务器名称与地址：集群信息（服务器编号，服务器地址，LF通信端口，选举端口），规则如：server.N=yyy:A:B #其中N表示服务器编号，YYY表示服务器的IP地址，A为LF通信端口，表示该服务器与集群中的leader交换的信息的端口。B为选举端口，表示选举新leader时服务器间相互通信的端口（当leader挂掉时，其余服务器会相互通信，选择出新的leader）。一般来说，集群中每个服务器的A端口都是一样，每个服务器的B端口也是一样。但是当所采用的为伪集群时，IP地址都一样，只能时A端口和B端口不一样。 server.1= 127.0.0.1:2888:3888 server.2= 127.0.0.1:2889:3889 server.3= 127.0.0.1:2890:3890 #server.A=B:C:D 其中A是一个数字，代表这是第几号服务器；B是服务器的IP地址；C表示服务器与群集中的“领导者”交换信息的端口；当领导者失效后，D表示用来执行选举时服务器相互通信的端口。
zkServer.sh status可以查看该服务器是什么类型的服务器
1.节点
主要分为临时节点和永久节点，其中又分为无序和有序
2.选举
选举服务器最好是基数，因为zookeeper的可用性是只要在一半以上服务器可用就整体可用，偶数个比及数个更浪费，5个服务器可损失的服务器是2个，6个服务器可损失的服务器也是两个，过半原则导致偶数服务器看上去有些浪费。
2.1选举在leader和follower中进行，比较zxid，如果zxid一致则比较myid，myid是可以设置的，在zoo.cfg中server.0=ip:port1:port2
其中0就是myid，ip就是各个服务器的ip地址，port1是leader和followerd的通信端口，port2是leader和follower的选举端口
在 ZAB 协议的事务编号 ZXID 设计中，ZXID 是一个 64 位的数字，其中低 32 位可以看作是一个简单的递增的计数器，针对客户端的每一个事务请求，Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。
而高 32 位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID，并从该 ZXID 中解析出对应的 epoch 值，然后再对这个值加一。
高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。同时，也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。
基于这样的策略：当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。
3.脑裂
如果leader和两个follower在一个网络区域，另外三台follower在一个网络区域，当两个网络区域断掉的时候，实施重新选举。
3.1情况一，选举出新leader后联通，则使用新leader
3.2情况二，在选举时原有leader联通了，则使用原有leader
4.同步
ZAB协议是为zookeeper专门设计的一种支持奔溃恢复的原子广播协议。
ZAB协议主要的作用在于三个方面1、选举出leader;2、同步节点之间的状态达到数据一致；3、数据的广播。
假设1：Leader 在复制数据给所有 Follwer 之后崩溃，怎么办？
假设2：Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃怎么办？
针对这些问题，ZAB 定义了 2 个原则：
- ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
- ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
所以，ZAB 设计了下面这样一个选举算法：
能够确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务。
针对这个要求，如果让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群总所有机器编号（即 ZXID 最大）的事务，那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。
而且这么做有一个好处是：可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。
5.zookeeper观察者
首先，在每一个想要成为观察者节点的配置文件中，你必须加入这一行：
peerType=observer 这一行告诉ZK这个服务端想要成为观察者。
第二，在每一个服务端的配置文件中，你必须在每一个观察者的服务者定义那一行加入:observer。例如:
server.1=localhost:2181:3181:observer
这告诉每一个其它服务端server.1是一个观察者，并且他们应该不要求它来投票。这是所有你需要增加的配置。现在你可以连接上它就好像它是一个普通的追随者。试试。通过运行下面的命令：
bin/zkCli.sh -server localhost:2181
这里的localhost:2181是观察者的主机名和端口号，正如在每一个配置文件中指定的那样。你应该可以看到一个命令行提示，通过它你可以发起像ls的命令来查询ZK服务。
6.zookeeper分布式锁
https://www.jianshu.com/p/5d12a01018e1
7.调用