一、什么是Zookeeper？
ZK是一个基于Java语言的开源的分布式协调工具，所以在使用ZK之前要先安装JDK，可以用来做分布式锁，注册中心和事件通知。它类似文件系统的树状目录结构，定义的节点路径是唯一的。
二、Zookeeper的应用场景有哪些？
1、分布式锁（redis或者zk）
2、注册中心（Dubbo+zk）
3、分布式配置中心disconfig
4、分布式消息中间件
5、发布订阅（事件通知）
6、Master选举
三、Zookeeper如何实现分布式锁？
Zk实现分布式锁思想：节点保持唯一、事件通知、临时节点（生命周期和session会话关联）
因为Zookeeper节点路径保持唯一，不允许重复 且有临时节点特性连接关闭后当前节点会自动消失，从而实现分布式锁。
实现原理：
1.多请求同时创建相同的节点（lockPath），只要谁能够创建成功 谁就能够获取到锁；
2.如果创建节点的时候，突然该节点已经被其他请求创建的话则直接等待；
3.只要能够创建节点成功，则开始进入到正常业务逻辑操作，其他没有获取锁进行等待；
4.正常业务逻辑流程执行完后，调用zk关闭连接方式释放锁，通知其他节点，从而是其他的请求开始进入到获取锁的资源。
四、Zookeeper与Eureka的区别？
| Zookeeper | Eureka | |
|---|---|---|
| 能否做注册中心 | 可以 | 可以 |
| CAP理论 | CP，保证数据一致性 | AP，保证服务可用 |
| 设计思想 | 中心化思想 | 去中心化思想 |
| 如何保证数据一致性 | Zab原子广播协议 | 采用 Peer to Peer 模式进行数据复制，为了防止相互循环复制，使用url中传参的方式来区分普通请求和复制请求，接受复制请求的不可以再向对方发送复制请求，解决了循环复制的问题，通过版本号来防止旧数据复制给新数据，通过心跳机制实现数据修复 |
| 如何判断节点宕机 | 心跳？ | 心跳不活跃会被剔除，如果是网络原因也可能判定宕机，所以有了自我保护机制，短时间丢失大量心跳会开启自我保护机制，暂时不会被剔除，网络故障恢复后退出自我保护机制。客户端也有缓存注册列表，以防因为网络问题所有的Eureka都访问不到，只要保证eureka有一个节点存在的话，就可以保证整个服务注册中心使用。 |
五、Zookeeper与Redis实现分布式锁的区别?
| Zookeeper | Redis | |
|---|---|---|
| 实现分布式锁的思想 | 1、节点唯一 2、事件通知 3、临时节点 | 1、Key唯一 2、事件通知 3、临时Key |
| 获取锁 | 同时创建同一个临时节点，谁先创建成功谁获取锁 | 使用setnx命令创建同一个key，创建成功的获取锁，创建失败返回0，成功返回1 |
| 释放锁 | 删除节点，相当于释放锁，节点事件通知其他线程开始争抢锁 | 删除key，相当于释放锁，事件通知其他线程开始争抢锁 |
| 超时锁 | 临时节点时间结束（Session会话），表示锁超时，回滚事务 | key时间结束，表示锁超时，回滚事务 |
六、Zookeeper的底层选举原理？如何保持数据一致性？
zxid大的为leader，zxid一样就比较myid，myid是自己设置的
基于Zab原子广播协议保持数据一致性，类似2PC两阶段提交协议
1.所有follower节点写的请求统一交个leader实现，当我们zk发出一个事务请求的时候，这时候我们的leader节点就会创建一个全局zxid（事务id，zxid越大代表数据越新）
2.Leader节点在第一阶段通知阶段，会带上zxid向每位follower节点发出确认同步通知（此时zxid+1）
3.只要有过半数的follower节点确认同步ack，这时候leader就会向所有的follower发出commit事务数据提交；
zxid是在第一阶段通知成功后修改，
七、什么是CAP理论？为什么不能CAP三者兼顾呢？
C：数据强一致性，保证数据不能出错，数据同步的时候服务不可用，注重数据一致
A：数据弱一致性，数据允许可以出错，允许脏读，数据同步的时候服务可用，数据最终会一致，注重服务可用
P：网络分区容错，允许出现网络故障，不会因为网络故障判断一个节点宕机了
CAP三者兼顾，就是又可以服务可用，又可以数据一致。比如：主节点在同步给从节点数据的时候，这时候从节点的数据不是最新的，如果你给从节点发送请求，返回数据一定是旧数据，如果你要保证是新数据，只能在同步阶段服务不可用。
八、为什么Zookeeper集群节点一定要是奇数？为什么集群数量要大于三台？
奇数的原因
1、因为节点剩余数要满足过半机制，剩余节点>总节点/2，三台集群和四台集群都只能宕机一台，还不如三台
2、偶数台容易造成票数相同
集群数量要大于三台的原因：
两台做集群的话，故障一台就不满足过半机制了，还不如不集群
九、Zookeeper中有哪三种类型的节点？分别是什么作用？
1.Leader类型 领导类型 负责写的请求，和各个节点同步；
2.Follower类型 跟随者 负责读的请求和投票决议
3.ObServer类型 观察者 和Follower大部分特征都是一样的，唯一区别就是不能参与选举和投票
注意：zk集群在后期扩容的时候，建议不要使用follow节点类型，会导致选举时间变长。
为什么要使用ObServer类型？
主要不影响原来本身选举的时间的效率、目的是提高客户端查询效率；
写操作都是转发给leader写的，读操作follower或者observer自己读
十、Zab原子广播协议、Paxos协议、2PC/3PC的区别？
十一、
十二、谈一谈Zookeeper中的网络分区脑裂问题？如何解决？
在集群的情况下，一般只会有选举一个master节点、其他节点都是为从接地安慰你，那么如果网络发生抖动或者部分节点无法实现通讯 那么就会导致部分节点从新实现选举，这样就会存在多个master节点。
通过过半机制解决脑裂问题。剩余节点数大于一半，而不等于一半，要么没有leader，要么就只有一个leader
十三、
十四、ACL四种权限类型
1、world:默认，全世界都能访问
2、auth:已经通过认证的用户可以访问
3、digest：用户名密码访问，常用
4、ip：指定ip可以访问
十五、节点类型分为四种：
1、临时节点–会话关闭，就自动消失（zk.close()）
2、持久节点–永久持久化到硬盘
3、临时有序节点，自增
4、持久有序节点
十六、分布式锁实现方式：概念：解决多个jvm中最终只能有一个jvm执行
1、基于数据库实现分布式锁
2、基于Redis实现分布式锁
3、基于Zk实现分布式锁
4、基于redisson框架实现分布式锁
十七、
十八、Eureka与Nacos的区别？
十九、zab原子广播协议有两种模式
1、恢复模式：初次启动节点时，选举leader，从节点进入恢复模式同步主节点数据
2、广播模式：解决每个节点的数据同步问题
二十、2PC两阶段提交协议解决分布式数据同步问题？
2PC两阶段提交协议应用于分布式事务场景，解决分布式多个系统间数据的一致性，如数据库XA机制。
多个服务器同时进行写操作，一台出错全部回滚
。是全局的事务id
事务请求：只有在写操作的时候才会用到事务
Zk底层解决分布式事务问题，就是采用类似2pc两阶段提交协议的Zab协议；
二十一、zxid什么情况下会不一致？
在同步的时候一台突然宕机了
二十二、
二十三、
二十四、
二十五、
二十六、
二十七、
二十八、
二十九、
三十、
根节点也允许为多个 没有节点名称不算根
得先创建父节点，再创建子节点，否则报错
单个jvm多线程生成订单序号一致问题使用synchronized或者lock锁
多个jvm同时生成订单号如果发生重复
synchronized或者lock锁只能在本地jvm中有效
ZK事务保持数据一致性是基于2PC两阶段提交协议的，主节点在处理事务请求的时候，如果主节点没有发生异常，主节点是先去通知从节点同步数据，还是先把主节点的事务提交了？zxid增加是在通知从节点同步之前还是之后？
