一、什么是Zookeeper
Zookeeper是一个可以作为注册中心、配置中心、分布式锁的分布式解决方案
二、数据一致性
一致性分为强一致性、弱一致性、最终一致性
Zookeeper可以保持数据的强一致性(CP)
主要是解决写、集群节点的同步、读之间的关系
- 强一致性:在硬件层面可以不能完全保证同步在读之前完成,但可以通过加锁的方案,即写后同步前会获取锁,读前也需要去获取这个锁,从而保证在同步操作没有完成前,无法进行读这个操作。(这里就是CAP中满足CP)
- 弱一致性:不保证同步操作一定会顺利执行,可能一致读到的就是同步之前的数据。
- 最终一致性:在同步完成之前可以正常读,同步后读取的数据才是最终的正确的数据。(这里就是CAP中满足AP)
Zookeeper和eureka的区别(CAP)
三、领导选举机制
目的:维持可用性
,用于集群leader节点宕机时,重新选举leader
一个Zookeeper集群可以有多个服务器节点,一般为单数,进行领导选举
2.1 选举标准
节点在存储数据时会先生成日志,而每条日志都有一个id,根据这个id的大小判断哪个节点的数据更新,日志id
大的更有机会成为leader
当两个节点的日志id一样时,节点id
大的更有机会成为leader
2.2 选举流程
每个节点先给自己投票
节点之间建立socket连接,互相发送自己的投票信息,并根据日志id和节点id的比较修改投票信息(此时会将修改的投票信息重新生成一份放在节点数组中,而无需修改的投票信息也会重新生成一份,从而记录投票的次数)
四、写操作
处理事务请求会被转发给leader节点统一处理
leader节点先生成日志文件,先向自己发送ack->向其他节点发送日志->其他节点收到日志后持久化日志,然后发送ack->leader节点等待收到超过一半的ack后,本地提交,更新内存数据(此时,如果有观察者节点,会向观察者节点发送完成更新的信号)->向其他节点发送commit->其他节点收到commit后,更新内存
那么为什么Zookeeper一般设置为奇数个节点呢?
因为leader节点需要收到超过一半的ack后(包括自己的)才会进行更新操作,
比如当节点为5个时,可允许宕机的节点个数为2(ack需要至少为3),
当节点为6个时,可允许宕机的节点个数为2(ack需要至少为4),那么在满足可用性时5和6个节点设置允许宕机的节点数是一样的,我们优先选5个
五、数据模型
文件类型,树结构
每个节点被称为ZNode,节点上保存自己的数据和节点信息
节点类型:
- 持久化节点
- 临时节点-e(只在当前的会话期间有效)
- 持久化顺序节点-s
- 临时顺序节点-es
六、数据同步
七、监听机制
new Zookeeper(String connectString, int sessionTimeout, Watcher watcher)
// 这个Watcher将作为整个Zookeeper会话期间的上下文,一直被保存在客户端ZKWatchManager的defaultWatcher
// 也可以动态添加watcher:getData(),exists, getChildren
串行同步,通过先进先出的队列实现,是同步过程,无需担心并发的问题
八、分布式锁
在单机下,可以使用synchronize实现锁(只能锁自己,锁不了其他节点)
而在分布式下,则需要使用分布式锁
(理解:分布式锁的本质就是跨机器的进程之间的数据同步问题,在分布式集群
工作下,属于多JVM工作环境,跨JVM
之间无法通过多线程的锁来解决同步问题,因此提供一个中心锁,需要调用的节点去中心取锁。)
方案:
-
数据库:利用唯一索引,乐观锁、悲观锁,
加锁插入,解锁删除,节点获取锁时去查询有数据,说明当前有其他线程正在访问,容易死锁 -
Redis:不可靠,如果master节点挂了,可能有多个salve节点获取到锁
-
Zookeeper:当客户端需要获取锁时,创建节点,使用完锁删除节点
1 客户端获取锁时,在Lock节点下创建
临时顺序节点
(临时节点会在会话结束后自动删除)
2 获取Lock下面所有子节点
,如果发现自己创建的子节点序号最小
,那么就认为该客户端获取
到了锁,使用完锁后,将该节点删除
3 如果发现自己创建的节点不是最小的,则需要找到比自己小
的那个节点,同时对其注册事件监听器,监听删除
事件
4 如果收到删除的通知,则再次判断
自己创建的节点是否是Lock子节点中序号最小
的,如果是则获取到了锁,如果不是则重复获取比自己小的节点并注册监听
。
九、应用场景
十、 事务性
原理是通过version一致进行控制
十一、观察者机制
Zookeeper中有三种节点:leader节点、follow节点、observer节点
其中observer节点不参加投票,不算在ack的半数节点范围内
十二、session会话管理
会话过期前断开,会重新进行连接,连接成功后会继续使用之前的过期时间
要避免2个客户端共用一个sessionId的场景,会导致第二个连接成功后,第一个被动断开,互相抢占,无限重连