🍋🍋大数据学习🍋🍋
🔥系列专栏: 👑哲学语录: 用力所能及,改变世界。
💖如果觉得博主的文章还不错的话,请点赞👍+收藏⭐️+留言📝支持一下博主哦🤞
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 被选出,它会从日志中读取最新的数据状态,并继续提供服务。