文章目录
一、前言
本文旨在记录zk重点基础知识点
二、zk简介及基础
2.1 zookeeper是啥？
分布式协调服务
2.2 zookeeper的本质是啥？
本质是文件存储系统+监听（通知）机制
2.3 CAP定理是啥？
cap定理：
C—>consistency 一致性 。白话：写入值到集群后，任何读操作都必须返回同一个值；
A—>availability一可用性 。白话：任何节点收到请求后，无论成功失败，都必须做出回应；
P—>partiton tolerance分区容错性。 白话：不同节点可能会数据不一致（因为同步失败的关系），当不一致时，系统依然能稳定运行。
2.4 zk是cap？ca？cp？
zk是cp模型
2.5 zk的数据节点类型有哪几种？
简单说：持久节点、顺序节点、临时节点
全部类型：
持久
持久顺序
临时
临时顺序
容器
持久 TTL
持久顺序 TTL
2.6 节点属性zxid是什么意思？
事务id：64位数字（前32位是epoch，后32位是事务次数）
值越大，数据同步次数越多，说明值越接近master
eg：0xee41
2.7 为什么原始api用的少？
因为：1、zk的原始api监听只生效一次，所以监听需要反复注册
2、不支持session超时重连
常用curator或zkclient
三、zk应用场景（分布式锁、配置中心、master选举、发布订阅）
3.1 为何用分布式锁？
synchronized是本地锁，只能锁住本地jvm进程中多个线程，对于多个jvm是锁不住的。
1、为了提高效率：防止不同节点做相同的事，浪费资源
2、为了安全：同一时间，只能一个线程去做
3.2 分布式锁常用什么？
分布式锁常用redis和zk，redis：支持并发高，zk：一致性更好
3.3 zk实现分布式锁采用基本思路时，羊群效应是什么意思？
基本思路：
1、某客户端创建临时节点lock
2、其他所有客户端监听该节点
3、锁释放后，事件通知
但会导致一个问题：羊群效应（所有监听的客户端一拥而上抢锁-大量请求，加重了网络负载，影响zk性能）
3.4 升级思路实现zk分布式锁
临时节点改用临时顺序节点
升级思路：
1、所有服务去zk中注册临时顺序节点;
2、判断自己节点是否是最小的那个，最小获取锁;
3、未获取锁的客户端 添加对前一个节点删除事件的监听
4、释放锁/持有锁的客户宕机后，节点被删除；
5、下一个客户端收到通知，重复。
四、选举策略
4.1 zk集群怎么保证数据的一致性？
通过ZAB协议保证，ZAB协议是以Paxos算法为理论基础
ZAB协议有3个角色：
leader：处理事务请求，数据同步
follower：处理非事务请求，具有投票权
observer：处理非事务请求，不具备投票权
4.2 zk啥时候会进入崩溃恢复模式？
zk启动时和leader挂了后
选出新leader，并与过半follower完成数据同步，然后进入消息广播模式
感兴趣自己去看源码 lookForLeader方法逻辑展示了如何选取leader
4.2 选举投票流程？
1、自增选举轮次：首先逻辑时钟都会+1；
2、初始化选票（先清空，再生成选票信息【包括三部分（epoch，zxid，myid）】，初始投给自己）；
然后（第3~第6）互相对比选票信息，先比较epoch值，如相同，则比较zxid，最后比较myid，取值大的当选leader；
3、发送初始化选票；
4、接收外部投票；
5、判断选举轮次；
6、选票PK；
7、统计选票-有过半服务器认可了自己的投票则终止投票
8、更新服务器状态-投票终止后，有过半选票则更新为LEADING，否则更新状态为FOLLOWING
203
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
