Zookeeper服务端初始化过程(三):数据恢复与同步
server类型(ServerType)
|
client端服务类
|
server端服务类
|
Leader(new)
|
LeaderZookeeperServer
|
Leader
|
Follower
|
FollowerZookeeperServer
|
FolloweràLearner
|
Observer
|
ObserverZookeeperServer
|
ObserveràLearner
|
- 在选举中,即当server的状态为LOOKING是,将会实例化一个ReadOnlyZookeeperServer来临时为client服务(如果server开启了readonly模式)。
- Leader是否可以直接服务于Client,取决于配置文件中“zookeeper.leaderServes”参数,即leader是否支持client服务.(当Leader不支持时,似乎是以异常的方式结束client链接,导致client被强制和其他Follower链接)。
- Client与server之间是通过NIO方式(长连接)进行通信,server端为单线程处理;每个socket链接对于server端而言,都有一个ServerCnxn类来维护,所有的请求ServerCnxnFatory之后交付给相应的ServerCnxn,最终请求packet经过zookeeperServer实例的各个processor处理。(“请求”全序性)
- Follower与Leader之间的通信,有些不同;Leader会维护每个Follower之间的链接,当然也是长连接,不过并没有使用NIO,而是普通的socket通信(同步数据交互,而非异步);Leader会为每个链接的Follower/Observer创建一个LearnerHandler线程,用于处理2者之间的数据交互,LearnerHandler类持有Leader实例;所以对于Leader而言,是多线程处理Follower/Observer的数据交互。
- LearnerCnxAcceptor,一个非常简单的线程,为Leader的内部类。它的主要作用是accept来自Follower/Observer的链接(侦听followingPort),为每个socket绑定一个LearnerHandler处理器线程,此线程持有socket句柄。此线程处理来自Follower/Observer的请求,并发送Leader的请求给Follower/Observer.
- 选举之前epoch来自server当前的zxid,N轮选举成功之后,最终的最大的epoch将作为最终的epoch;zxid的前32位为epoch,所以每次选举之后,leader的职责就是重新计算zxid,以免发生重复;在lead正式服务之前,这个重置的zxid(或者说是epoch)尚不能作为真正的zxid,即还不能持久在db中。此zxid经过大多数的Follower赞同之后(赞同:即所有现存的Follower都没有比此epoch更大的)才可以使用,在新leader提议这个epoch时,如果发现>=当前epoch时,leader就将较大的epoch +1并赋值给当前epoch,以确保新leader在服务器之前,所采用的epoch为最大的。(参见:Leader.getEpochToPropose())Epoch提议只会被计算一次,并且多数派时(包括leader在内),此epoch才能被生效,并参与接下来新的zxid生成。
-
Leader.getEpochToPropose(sid,lastAcceptedEpoch),这个方法会在leader.lead()和LearnerHandler中调用,此方法会阻塞,直到leader提交自己的epoch,并且“大多数”Follower也提交(LearnerHandler中)。所以在上述2个方法中,均会像”栅栏”一样,阻塞每个peer的执行此方法比较leader.epoch和每个sid所交付的lastAcceptedEpoch,并确保leader.epoch是最大的(且不相等,相等时,会+1):
if (lastAcceptedEpoch >= epoch) {
epoch = lastAcceptedEpoch+1;
}
Leader.lead()即表示leader提交自己的epoch.;LearnerHandler线程时负责接受follower连接的,所以在每个follower建立连接时也会向leader首先交付自己的epoch.只有在epoch达成一致之后,才能进行实际的通讯.
- 经过3)之后,leader和follower确认了epoch(选举票根)之后,leader计算并db持久化zxid,同是将自己(leader)目前的(epoch,zxid)信息封装,在此同时各个参与选举的follower也做同样的操作,不过每个follower所交付的zxid可能不同,但是他们不能比当前leader更”超前”(如果超前,将抛出异常,系统认为leader职能失败,重新选举),各个follower陆续向leader确认(epoch,zxid),如果此时大部分参与选举的follower都参与了确认且正常,那么到此为止,leader和follower各自的角色被真正决定,同时follower和leader之间的zxid步差也将被计算出来.[follower的ack操作也是在LearnerHandler中进行,3]操作之后]
- 此期间有个小小的细节,leader在和follower确认epoch和zxid时,会创建一个”标记”性proposal,此提议的zxid为根据epoch新计算的其中counter(计数器位)为0,在learnerHandler.run中,所有的follower都同步完毕,并手动去提交ACK消息时(leader.processAck),当所有的follower都ACK之后,将会导致LeaderZookeeperServer启动,接下来leader就可以为client提供服务了.
- 其实代码的复杂度还是很大.在LearnerHandler.run()和Follower.followLeader()方法中存在顺序性的交互操作.那么Leader.lead()只是根据上述2个方法的交互作为状态判断(有同步的过程).
- 当leader和follower确认”角色”关系之后,每个follower所对应的LearnerHandler就可以从follower发送的packet中得到当前follower所持有的最大的zxid,通过此zxid和leader所持有commitedLog中最大的czxid比较,如果follower的zxid比较大,那么handler将会首先发送一个TRUNC信号,让follower清除czxid之后的所有记录;如果follower的zxid比较小,那么此时handler将会遍历commitedLog,将zxid之后的所有记录,封装成”提议”直接发送给follower(此提议为commit状态,即follower直接提交,不再ACK),当数据同步完毕之后,handler最后向follower交付一个UPTODATE的标记提议,告知follower,数据已经同步结束,它即可开始为client服务了.
- LearnerHandler向follower同步完数据之后,即进入while自选循环中,用于顺序接收follower所发送的各种类型的提议,并做不同的业务处理.那么同时Follower也进入了服务状态(while循环),接收client的请求,响应事件,转发write操作等.
- 大小: 44.8 KB
- 大小: 77.6 KB
分享到:
相关推荐
zkServer.sh 用于启动服务器,zkCli.sh 用于启动命令行客户端,方便用户与 Zookeeper 进行交互。 2. conf:存放配置文件,如 zoo.cfg,这是 Zookeeper 的主配置文件,配置项包括数据存储路径、端口设置等。 3. ...
每个Server都保存整个数据树的一个副本,并通过Paxos或ZAB(Zookeeper原子广播协议)协议进行数据同步,以确保数据一致性。通常,为了高可用性,Zookeeper集群会配置奇数个Server节点。 **Zookeeper的部署模式:** ...
3. 客户端交互:使用`zkCli.sh`命令启动ZooKeeper客户端,可以进行创建节点、查看节点、设置数据等操作。 4. 监控与管理:ZooKeeper提供了一个名为`zkServer.sh`的脚本,用于启动、停止、重启和查看状态等操作。 ...
- **客户端工具**: bin目录下提供了zkCli.sh命令行工具,用于与Zookeeper交互。 5. **Zookeeper的应用场景** - **Hadoop HDFS**: 在Hadoop中作为元数据管理组件,负责NameNode的高可用。 - **Kafka**: 作为消息...
Zookeeper提供了丰富的命令行工具,如`zkCli.sh`,可以用来与Zookeeper服务器交互,进行数据的增删改查,或者查看节点状态。此外,Zookeeper的API也支持多种编程语言,如Java、Python、C++,使得开发者能方便地集成...
在日常运维中,了解Zookeeper的监控工具,如`zkCli.sh`客户端,用于与Zookeeper服务器交互,查询和修改数据;以及`jmx`监控,通过JMX接口获取Zookeeper的运行时信息,都是非常重要的。 总之,Apache ZooKeeper在...
5. **ZooKeeper命令行工具**:`bin/zkCli.sh`是ZooKeeper的客户端,用于与服务端交互,执行如创建、删除ZNode,获取数据,设置权限等操作。 6. **ZooKeeper的数据模型**:ZooKeeper的数据结构类似于文件系统,由...
5. **数据一致性模型**:Zookeeper采用ZAB(ZooKeeper Atomic Broadcast)协议来保证数据的一致性,通过主备选举和消息广播确保所有服务器节点的数据同步。 在Linux和Windows上部署Zookeeper-3.4.10,一般包括以下...
4. 使用`bin/zkCli.cmd`命令行客户端与Zookeeper交互,进行配置、监控或者管理操作。 在Windows环境中,可能还需要注意防火墙设置,确保Zookeeper的通信端口(默认是2181)对需要访问它的服务是开放的。 总之,...
2. **层次命名空间**:Zookeeper的数据结构是一个树形结构,与文件系统类似,允许用户以层次化的方式组织数据。这使得管理和查找服务变得更加直观和方便。 3. **原子操作**:Zookeeper的所有操作都是原子性的,即一...
在Zookeeper 3.4.6版本中,用户可以解压后直接运行 `bin/zkServer.cmd` 启动服务,这极大地简化了部署流程。接下来,我们将深入探讨Zookeeper的核心特性、工作原理以及如何在实际场景中应用。 1. **核心特性** - ...
**客户端与ZooKeeper交互:** ZooKeeper提供了多种客户端,包括命令行客户端、Java API以及各种语言的SDK,如Python、C++、Go等。这些客户端允许开发者创建、删除和更新ZNode(ZooKeeper中的数据节点),并订阅ZNode...
客户端通过TCP连接与服务器通信,使用Zookeeper协议进行交互。ZooKeeper采用主从结构,其中一个是Leader,其余是Follower,选举机制确保了高可用性。 4. **Zookeeper的数据模型:** 数据模型类似文件系统,由层次...
- **客户端工具**: `bin/zkCli.sh` 提供命令行接口,用于与Zookeeper 交互。 5. **Zookeeper 应用场景** - Hadoop YARN 使用Zookeeper 进行资源调度器的元数据管理和集群状态同步。 - Kafka 利用Zookeeper 实现 ...
2. 服务器(Server):构成 ZooKeeper 集群,每个服务器都保存整个数据树的一致视图,并通过 zab 协议进行同步。 3. 数据树(ZNode):ZooKeeper 中的数据模型,类似于文件系统,由一系列节点(ZNode)组成,每个...
Apache ZooKeeper是一款开源的分布式协调服务,它为分布式应用提供了一种简单、高效且可靠的命名服务、配置管理、集群同步、分布式锁等机制。在3.4.12版本中,Zookeeper继续展现了其稳定性和健壮性,成为了众多企业...
Zookeeper 提供了 Java 客户端 API,使得开发者可以方便地与 Zookeeper 交互。通常,客户端首先连接到 Zookeeper 集群中的一个节点,然后可以通过会话与 Zookeeper 进行通信,发送请求并接收响应。 **项目构建与...
3. 客户端连接:使用`zkCli.sh`脚本启动客户端,与ZooKeeper服务器进行交互。 4. 数据操作:在客户端上,用户可以创建、删除、更新znodes,设置watch等。 ZooKeeper-3.4.8版本相比早期版本可能已经修复了一些已知...