1、ZooKeeper 是啥，能用来做啥
是一个分布式协调系统，为分布式服务提供一致性。
可以用来做 注册中心，分布式锁，Master选举，数据的发布与订阅
实质是实现了一个文件系统（多层级的节点znode命名空间，每个节点都可以存放数据），特点watch机制
2、ZooKeeper 如何保证主从数据一致，如何实现数据的同步
Zab（ZooKeeper Automatic Broadcast） ZooKeeper原子消息广播协议
恢复模式：
当服务刚启动或者leader宕机或失联后，就进入恢复模式。崩溃恢复模式会开启下一轮的选举，选举产生的leader与过半的follower进行同步完成后，退出恢复模式。
广播模式：
收到写消息后，会将请求转发到leader节点，
leader节点会定义一个全局递增的唯一事务id zxid，包装成更新，leader会将更新发送给所有follower，
follower收到更新会将zxid与本地最大的zxid的相对比，如果更大，则将更新提案持久化到事务日志，回复leader ack消息
leader接受到超过半数的follower回复后，会向所有follower提交commit，同时将更新提交到Observer
leader自身commit更新 -- 对外可读了
follower和observer收到commit后，会将数据更新到内存数据库中，可读。回复leader ack
3、ZooKeeper选举
选举消息的内容：
ServiceId 服务器id，节点id
Zxid 事务id，服务器中存放的最大数据id，越大越新
Epoch 逻辑时钟 - 投票轮数，递增的。根据这个知道是哪一轮的投票
Server选举状态 looking选举中 leading following observing不参与投票
- 启动，先判断集群是否已经有leader了，如果有，就直接作为follower启动
- 如果处于选举状态，每台机器都在第一轮会投票给自己，并且获取其他机器的投票信息
- 收集到投票信息后，每台机器根据信息，先判断epoch，轮次大的胜出，然后选举zxid最大的，如果zxid一样大，选举serviceid最大的，并发起第二轮投票
- 如果超过半数的选票决出leader，选举结束，各个机器更改自己相应的状态 否则重复第3步
4、znode
- persistent 持久化节点 除非手动删除，否则一直存在。可创建子节点
- persistent seq 持久化顺序节点 比上多了个节点名后缀为自增数字 10位
- ephemeral 临时节点 会话关闭，自动删除。不能创建子节点
- ephemeral 临时顺序节点 比上多了个节点名后缀为自增数字 10位
create /module1 module1 创建了一个持久节点/module1，且其数据为”module1”
create -e /module1/app1 app1 创建了一个临时节点 /module1/app1，数据为”app1”
create -s /module1/app app 输出Created /module1/app0000000001
get /module1/app2
app2
cZxid = 0x20000000e
ctime = Thu Jun 30 20:41:55 HKT 2016
mZxid = 0x20000000e
mtime = Thu Jun 30 20:41:55 HKT 2016
pZxid = 0x20000000e
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0
节点状态信息 ：
ctime 创建时间 mtime 最新修改时间
cZxid 创建时的事务id mZxid 最新修改的事务id pZxid 子节点变更最新事务id
Zxid可用于客户端的重连，选择Zxid相同节点
cversion 当前节点的子节点变化是递增1
dataVersion 当前节点的内容版本号，每次set都会递增，不管数据是否发生变化
aclVersion acl变更版本号
版本号是避免并行更新产生的竞争
ephemeralOwner 创建该临时节点的会话的sessionId
dataLength 数据长度
numChildren 子节点个数
5、ACL （Access Control List）访问控制列表
身份认证方式：
- world 默认，所有都可以访问 world:anyone:[permissions]
- digest 密码访问 digest:username:Base64(Sha1(password)):[permissions]
- ip 对指定ip进行限制 ip:109.108.1.1:[permissions]
- auth 认证登录 auth:usernamepassword:[permissions]
权限permissions： - CREATE 允许当前节点下创建子节点
- DELETE 允许当前节点下删除子节点
- WRITE 允许当前节点下更新操作
- READ 允许读取当前节点内容及子节点列表
- ADMIN 允许对当前节点进行ACL更改操作
6、Watcher机制
ZK客户端可以向ZK服务端的某个Znode节点注册Watcher监听，当指定事件发生后，服务端会向客户端发送通知。
- 一次性 一旦触发即被移除，减轻服务端和客户端压力
- 客户端串行执行 客户端的watcher回调过程是一个串行过程，所以回调尽量快点
- 轻量 传输的事件只包含节点路径，事件类型，通知状态，不包含数据
- 时效性 在session过期时间内，重连任然可以收到watcher事件
注册：
getData getChildren exist 都可以用来向服务器注册watcher
触发：
create delete setData
- client 发送请求，将watch的状态保存到client中，即存在于等待回复队列中
- 标记watch的request请求到达服务端后，服务端会将这个watcher（包含client连接属性）以字典形式保存在内存中
- 当watch的节点发生变化时，去字典找出注册的watch，拿出连接
- 根据连接发送通知
- client从等待回复队列中取出元素，watch的回调被触发
7、分布式锁的实现
找一个持久化节点当做一个锁节点
在锁节点下创建临时顺序节点
获取锁节点下临时节点列表，判断是否是最小的，如果是最小的，获取锁成功
如果不是最小的，则监听比当前创建的临时节点次小的节点的删除事件，阻塞等待watch通知
收到前一节点删除通知，则再次获取临时节点列表，判断自己是否是最小的节点，如果是，则获取锁成功，否则重复上述步骤
8、注册中心与Eureka区别
ZooKeeper ：CP 使用主从模型，保证数据的一致性 leader宕机是停止对外服务，重新选主后再提供服务
Eureka ：AP 使用无主模型，所有节点平等 客户端访问所有节点都可以提供实时服务响应。如果宕机，请求会转向其他节点。集群中不同节点数据可能不一致，需要通过网络通讯同步其他节点信息，实现数据一致。影响最终一致性的因素有网络延迟，重试机制，同步频率等
ZooKeeper支持数据存储，Eureka不支持
ZooKeeper支持watcher机制订阅变更 Eureka通过轮询
