大内容学习(130)-zookeeper
??大数据学习??
?系列专栏: ?哲学语录: 用力所能及,改变世界。
?如果觉得博主的文章还不错的话,请点赞?+收藏⭐️+留言?支持一下博主哦?
1. ZooKeeper 集群
ZooKeeper 集群 是一个分布式协调服务架构,由多个 ZooKeeper 服务器节点组成。这些节点通过协作来提供高可用性、一致性和可靠性的服务。以下是 ZooKeeper 集群的关键特性:
- 分布式架构通过:集群中的每个节点都能够处理客户端请求,并通过内部通信机制(如心跳)来保持数据的一致性。
- 高可用性:即使部分节点发生故障,集群仍能继续提供服务,因为素材被复制到多个节点上。
- 容错性:通过数据复制和冗余存储,确保数据不会因单点故障而丢失。
- 可扩展性:可以通过增加节点来扩展集群的处理能力,以应对更多的客户端请求。
工作原理:
- 客户端连接到集群中的任意一个节点,该节点会将请求转发给 Leader 节点(对于写操作)或直接处理(对于读操作)。
- Leader 节点负责协调写操作,并将更改同步到所有 Follower 节点。
- Follower 节点接收来自 Leader 的更改,并更新自己的资料副本。
2. ZooKeeper 启动
ZooKeeper 启动 是初始化服务器节点并使其加入集群的过程。以下是启动 ZooKeeper 服务器的详细步骤:
- 配置文件设置:
- 编辑
zoo.cfg文件,指定数据目录(dataDir)、客户端端口(clientPort)、集群中其他节点的地址(server.x=host:port1:port2)等信息。
- 编辑
- 创建数据目录和标识文件:
- 在每个节点的
dataDir目录下创建一个名为myid的文件,文件内容为该节点的唯一标识(与zoo.cfg中的server.x对应)。
- 在每个节点的
- 启动服务:
- 使用
zkServer.sh start(Linux)或相应的启动命令启动 ZooKeeper 服务。 - 启动后,节点会读取配置文件,初始化资料目录,并尝试与其他节点通信以加入集群。
- 使用
- 节点加入集群:
- 启动的节点会与其他节点交换信息,确认集群状态,并同步数据(如果得)。
3. ZooKeeper 选举机制
ZooKeeper 选举机制 是用于在集群中选择一个 Leader 节点的过程。当集群启动或 Leader 节点故障时,会触发选举。以下是选举机制的关键点:
- 选举触发条件:
- 集群启动时,所有节点都是 Follower,没有 Leader,因此会触发选举。
- Leader 节点故障时,Follower 节点会检测到 Leader 的不可用,并触发选举。
- 选举过程:
- 每个 Follower 节点会转变为 Candidate 角色,并开始选举过程。
- Candidate 节点会向其他节点发送投票请求,并接收来自其他节点的投票。
- 投票基于节点的 myid(配置中指定的唯一标识)和事务 ID(zxid,表示数据更新的顺序)。
- 节点会选择 zxid 最大的节点作为新的 Leader。若是 zxid 相同,则选择 myid 最大的节点。
- 选举结果:
- 一旦某个节点获得超过半数的投票,它就会成为新的 Leader。
- 其他节点会转变为 Follower 角色,并接受新的 Leader 的领导。
4. Follower(跟随者)和 Candidate(候选者)节点区别
在 ZooKeeper 集群中,节点可以处于不同的角色,这些角色在集群的运行过程中会动态变化。以下是 Follower 和 Candidate 节点的区别:
- Follower(跟随者):
- 角色:在集群正常运行时,大部分节点都是 Follower。
- 职责:
- 接收客户端请求并转发给 Leader(对于写操作)。
- 本地一致的,不得 Leader 协调)。就是直接处理读操作(缘于读操作
- 参与 Leader 选举投票。
- 行为:Follower 节点不会主动发起选举,而是等待选举过程的开始。
- Candidate(候选者):
- 角色:Candidate 是在 Leader 选举过程中临时的一个角色。
- 职责:
- 当现有 Leader 节点故障时,集群中的 Follower 节点可以转变为 Candidate,参与选举以成为新的 Leader。
- Candidate 节点会向其他节点发送投票请求,并接收来自其他节点的投票。
- 行为:Candidate 节点会积极参与选举过程,直到选举出新的 Leader 或自己成为新的 Leader。一旦选举出新的 Leader,Candidate 角色会消失,节点要么成为新的 Leader,要么恢复为 Follower。
5. Leader 节点挂掉期间写操作是否会丢失
在 ZooKeeper 集群中,如果 Leader 节点挂掉,写处理不会丢失,但会有短暂的影响。以下是详细解释:
- 写操作暂停:
- 在 Leader 节点挂掉期间,由于没有 Leader 来处理写请求,客户端的写操作会暂时被阻塞或返回错误。
- 这是因为 ZooKeeper 的写处理需要 Leader 节点的协调,以确保数据的一致性。
- 选举新 Leader:
- 集群会立即触发 Leader 选举过程,选择一个新的 Leader 节点。
- 选举过程通常是快速的,因为 ZooKeeper 使用了优化的选举算法(如 Fast Paxos)。
- 恢复写操作:
- 一旦新的 Leader 被选出,集群会恢复写操作的处理。
- 写操作会被提交到新的 Leader,并通过集群内部的一致性协议(如两阶段提交)同步到所有 Follower 节点。
- 新的 Leader 会确保在恢复写操作之前,所有 Follower 节点都已经同步了最新的数据。
- 数据一致性:
- ZooKeeper 通过事务日志和快照机制确保数据的一致性。
- 即使 Leader 节点挂掉,信息也不会丢失,因为事务日志被持久化存储在磁盘上,并且 Follower 节点可能从日志中恢复数据。
- 一旦新的 Leader 被选出,它会从日志中读取最新的数据状态,并继续给予服务。
浙公网安备 33010602011771号