zookeeper

Zookeeper

Zookeeper集群操作

zoo.cfg文件

zoo.cfg文件（通用配置文件）

tickTime = 2000

Zookeeper服务器与客户端的心跳时间（单位毫秒）

initLimit = 10：LF初始通信时限

Leader和Follower建立连接时能容忍的最多心跳数

syncLimit = 5：LF同步通信时限

Leader和Follower之间通信时间如果超过syncLimit * tickTime，Leader就认为Follower死了

dataDir

Zookeeper数据的存储位置

clientPort = 2181

客户端的连接端口

选举机制

选举机制中的概念

SID（服务器ID）：每台服务器的SID都不一样

ZXID（事务ID）：值越大说明数据越新（在选举算法中数据越新权重越大）

Epoch：投票的次数

选举状态

LOOKING：竞选状态

FOLLOWING：随从状态，同步leader状态，参与投票

OBSERVING：观察状态，同步leader状态，不参与投票

LEADING：领导者状态

选举机制（第一次启动）

比如有5台服务器

先启动服务器1，服务器1投自己一票，不够3票，此时服务器1会是Looking状态

启动服务器2，服务器1和服务器2都投自己一票，然后服务器1发现服务器2的myid比自己大，就会把自己的票给服务器2，服务器2的票数不到半数以上，这两个服务器都为Looking状态

启动服务器3，服务器1和服务器2的票都会给服务器3，服务器3超过半数以上，然后它为Leader，服务器1和服务器2为Follower

启动服务器4，已经出现了Leader，所以服务器4自动变成Follower

启动服务器5，和服务器4一样是Follower

选举机制（非第一次启动）

Leader挂掉后，其它的服务器会把自己的状态改为Looking，然后开始选举，选举的比较顺序是先比较Epoch（任期代号）、ZXID（事务id）、myid（服务器id）

ZK集群启动停止脚本

创建脚本（zk.sh）

#!/bin/bash
case $1 in
"start"){
    for i in node01 node02 node03
    do
        echo ---------- zookeeper $i 启动 ------------
        ssh $i "/opt/yjx/zookeeper-3.5.7/bin/zkServer.sh start"
	done
};;
"stop"){
    for i in hadoop102 hadoop103 hadoop104
    do
        echo ---------- zookeeper $i 停止 ------------ 
        ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh stop"
    done
};;
"status"){
    for i in hadoop102 hadoop103 hadoop104
    do
        echo ---------- zookeeper $i 状态 ------------ 
        ssh $i "/opt/module/zookeeper-3.5.7/bin/zkServer.sh status"
    done
};;
esac

添加脚本的执行权限

# 添加脚本的执行权限
chmod u+x zk.sh

客户端向服务端写数据的流程

发送给Leader节点

客户端给Leader发送写数据的请求，Leader会马上开始写操作，并通知第二台服务器进行写操作；

写完之后，会通知Leader已完成写操作，Leader会检测完成写操作的服务器是否超过半数，超过半数就通知客户端已完成写操作；

后面的话Leader节点还会继续通知其它没有完成写操作的服务器进行写操作。

发送给Follower节点

客户端给follower节点发送写操作的请求，follower会把写请求发送给Leader节点；

Leader节点收到follower节点转发的写操作请求，会开始写操作，并通知其他服务器开始写操作；

当Leader服务器检测到超过半数的机器完成了写操作，就会通知之前收到写请求的follower节点已完成写操作，然后这个follower节点再通知客户端已完成写操作。

企业面试真题

选举机制

1、第一次选举：投票的数量过半且服务器id大的胜出

2、非第一次选举：Epoch大的直接胜出，Epoch相同的话事务Id大的胜出，事务id相同服务器id大的胜出

生产环境安装多少zk合适

安装奇数台

生产经验

10台服务器推荐3台zk

20台服务器推荐5台zk

100台服务器推荐11台zk

200台服务器推荐11台zk

常用命令

ls、get、create、delete

算法基础

Paxos算法

paxos算法简介

paxos解决了分布式系统中的一致性问题

Paxos算法把所有节点分为3类：Proposer（提议者）、Acceptor（接受者）、Learner（学习者）

Proposer：负责提出提案（提案信息里面包括提案ID和提案值）

Acceptor：负责回应Proposer的提案

Learner：负责学习达成一致的提案

paxos算法流程

准备阶段。Proposer向Acceptors发出Prepare请求，Acceptors对收到的Prepare请求进行Promise承诺。

接受阶段。Proposer在收到半数以上Acceptors承诺的Promise后，向Acceptors发出提议请求，Acceptors对收到的提议请求进行接受处理。

学习阶段。Proposer在收到半数以上Acceptors的接受之后，提议形成，然后把形成的提议发送给所有Learners。

ZAB协议

什么是ZAB协议

Zookeeper的底层用的就是ZAB协议

ZAB协议包括消息广播和崩溃恢复

消息广播

客户端向Leader发送写请求

Leader会把客户端的请求转化为事务Proposal（提案），同时为每个Proposal（提案）分配一个zxid

Leader向每个Follower服务器分配一个单独的队列，然后把要广播的Proposal（提案）放到队列中，并且根据FIFO策略进行消息发送

Follower收到Proposal（提案）后，会写到本地磁盘中，写入成功后向Leader反馈一个Ack（确认）消息

Leader收到半数以上的Follower的确认消息后，向所有的Follower广播commit消息

崩溃恢复（如果Leader服务器出现崩溃或者由于网络导致Leader失去了过半Follower的联系，会进入崩溃恢复模式）

Leader选举

新Leader必须是已经提交了提案的Follower节点

选举zxid最大的当Leader，zxid相同的话，myid最大的当Leader（zxid最大表示它的日志是最全的）

数据恢复

Leader服务器会先确认事务日志中所有的提案是否已经被集群中过半的服务器commit

Leader会确保所有的Follower能接受到每一条事务的提案，并且能将已经提交的事务提案应用到内存数据中。然后Leader才会把这个Follower加入到可用的Follower列表中

CAP理论

CAP理论指出在分布式系统中最多只能满足CAP理论中的两个属性（网络分区）

CAP理论（一致性、可用性、分区容错性）

一致性：在多个副本中数据是否能保证一致

可用性：提供的服务需要一直处于可用状态，并且每个请求都能在有限的时间内返回结果

分区容错性：服务器之间发送的消息不能丢失

Zookeeper用的是CP

所以Zookeeper不能保证每次请求的可用性

posted @ 2023-03-28 16:17 mmgq 阅读(58) 评论(0) 收藏举报

刷新页面返回顶部

mmgq

zookeeper

Zookeeper

Zookeeper集群操作

zoo.cfg文件

选举机制

ZK集群启动停止脚本

客户端向服务端写数据的流程

企业面试真题

算法基础

Paxos算法

ZAB协议

CAP理论

公告