理解Zookeeper

Flora.~

已于 2024-03-21 18:29:37 修改

阅读量931

点赞数 19

分类专栏：学习笔记文章标签： java

于 2023-12-04 00:10:36 首次发布

本文链接：https://blog.csdn.net/weixin_40497710/article/details/134769589

版权

学习笔记专栏收录该内容

10 篇文章 0 订阅

订阅专栏

一、什么是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子节点中序号最小的，如果是则获取到了锁，如果不是则重复获取比自己小的节点并注册监听。