先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7

深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年最新大数据全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

如果你需要这些资料,可以添加V获取:vip204888 (备注大数据)

正文

(3)set:设置节点的值

(4) get:获取节点的值

(5) stat:查看节点的状态

(6) delete:删除节点

(7) deleteall:递归删除节点

Zookeeper目录结构

ZooKeeper的目录结构采用类似Unix文件系统的树形结构。ZooKeeper 目录结构由 ZNode 组成,每个ZNode 默认情况下最多可以存储 1MB 的数据。ZNode是ZooKeeper中的基本数据单元,可以用于存储配置信息、状态信息等。

ZooKeeper目录结构的根节点为/,所有的ZNode都是以根节点为基础进行构建的。每个ZNode的名称是唯一的,并且可以包含多个子节点,每个子节点都是一个独立的ZNode。ZNode可以是永久节点,也可以是临时节点。

在ZooKeeper目录结构中,常用的ZNode包括:

/zookeeper:ZooKeeper的内部节点,用于存储ZooKeeper的配置信息和状态信息。/brokers:Kafka集群中所有的Broker信息存储在该节点下。/controller:Kafka集群中Controller的状态信息存储在该节点下。/consumers:Kafka中所有的消费者组信息存储在该节点下。/config:Kafka集群的配置信息存储在该节点下。/admin:Kafka中所有的管理员操作信息存储在该节点下。

简述什么是CAP理论,zookeeper满足CAP的哪两个 ***

分布式系统有三个指标:

Consistency(一致性)

用户在访问分布式系统中的任意节点,得到的数据必须一致。

Availability(可用性)

用户访问集群中任意的健康节点,必须能得到响应,而不是超时或拒绝。

Paratition tolerance(分区容错性)

分区:因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接,形成独立的分区。容错:在集群出现分区时,整个系统也要持续对外提供服务。

分布式系统无法同时满足这三个指标,这个结论就是 CAP 理论。

Zookeeper 符合一致性、分区容错性。(CP)

Paxos 算法 ***

Paxos 算法:一种基于消息传递且具有高度容错性的一致性算法。

Paxos 算法解决的问题:如何快速正确的在一个分布式系统中对某个数据的值达成一致,并且保证不论发生任何异常,都不会破坏整个系统的一致性。

在一个 Paxos 系统中,首先将所有的节点划分为Proposer(提议者)、Accepter(接受者)和 Learner(学习者)。(注意每个节点都可以身兼数职)

一个完整的 Paxos 算法流程分为三个阶段:

准备阶段

Proposer 向多个 Accepter 发出 Propose 请求Promise(承诺)Accepter 针对收到的Propose请求进行Promise(承诺) 接受阶段

Proposer 收到多个Accepter的Promise(承诺)后,向Accepter发出ProposeAccepter 针对收到的Propose请求进行Accept处理 学习阶段

Proposer将形成的决议发送给所有的 Learner

ZAB协议/Zookeeper怎么保证一致性的 ***

依赖了 ZAB 协议,ZAB 协议借鉴了 Paxos 算法,是专门为 ZooKeeper 设计的支持崩溃恢复的原子广播协议。Paxos 算法中采用多个Proposer 会存在竞争 Acceptor 的问题,ZooKeeper 设计为只有一个 Leader 负责处理外部的写事务请求,然后 Leader 将数据同步到其他 Follower 节点。即,ZooKeeper 只有一个 Leader 可以发起提议。

ZAB 协议包括两种基本的模式:消息广播(正常)、崩溃恢复(异常)。

这两个模式是相辅相成的,消息广播模式就是 Zookeeper 不出现任何问题,并且正常工作的模式,崩溃恢复看字面意思就是当 Zookeeper 出现故障时用于恢复的。

(1)消息广播

(2)崩溃恢复

ZooKeeper 使用的ZAB协议与Paxo算法的异同?

相同点:

两者都存在一个类似于 Leader 进程的角色,由其负责协调多个 Follower 进程的运行Leader 进程都会等待超过半数的 Follower 做出正确的反馈后,才会将一个提案进行提交ZAB 协议中,每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader 周期,Paxos 中名字为 Ballot

不同点:

ZAB(ZooKeeper Atomic Broadcast) 用来构建高可用的分布式数据主备系统(Zookeeper),Paxos 是用来构建分布式一致性状态机系统。而 Paxos 算法与 ZAB 协议不同的是,Paxos 算法的发起者可以是一个或多个。当集群中的 Acceptor 服务器中的大多数可以执行会话请求后,提议者服务器只负责发送提交指令,事务的执行实际发生在 Acceptor 服务器。这与 ZooKeeper 服务器上事务的执行发生在 Leader 服务器上不同。Paxos 算法在数据同步阶段,是多台 Acceptor 服务器作为数据源同步给集群中的多台 Learner 服务器,而 ZooKeeper 则是单台 Leader 服务器作为数据源同步给集群中的其他角色服务器。

注意:ZAB是在Paxos的基础上改进和演变过来的。

分布式集群中为什么会有主节点

在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机器可以共享这个结果,这样可以大大减少重复计算,提高性能,于是就需要主节点。

节点挂掉的时候Zookeeper是如何发现的

ZooKeeper提供了一种心跳机制,即每个节点都会定期向其他节点发送心跳消息,如果一个节点超过一定时间没有收到其他节点的心跳消息,就会判定这个节点已经下线了。

Leader一旦选出,如何让集群中所有Follow获悉

心跳机制

Zookeeper下 服务器的工作状态有几种

ZooKeeper 服务器有四种工作状态:

LOOKING:寻找 Leader 状态。当服务器处于该状态时,它会认为当前服务器没有 Leader,因此需要进入 Leader 选举状态。FOLLOWING:跟随者状态。表明当前服务器角色是 Follower。LEADING:领导者状态。表明当前服务器角色是 Leader。OBSERVING:观察者状态。表明当前服务器角色是 Observer。

Zookeeper提供了什么

(1)文件系统 (2)通知机制

ZooKeeper是否会自动进行日志清理?

ZooKeeper 不会自动进行日志清理,需要运维人员进行日志清理

请说明 ZooKeeper 使用到的各个端口的作用?

(1)2888:Follower与Leader交换信息的端口

(2)3888:万一集群中的 Leader 服务器挂了,需要一个端口来重新进行选举,选出一个新的 Leader,而这个端口就是用来执行选举时服务器相互通信的端口

zookeeper 负载均衡和 nginx 负载均衡区别

zk的负载均衡是可以调控,nginx只是能调权重,其他需要可控的都需要自己写插件;但是nginx的吞吐量比zk大很多,应该说按业务选择用哪种方式。

什么是脑裂

脑裂通常会出现在集群环境中,当集群中出现故障(比如网络故障),分成了“两个集群”,这两个集群无法互相通信,此时就会让集群觉得Leader挂了,这时候就会出现两个Leader节点,这就是脑裂。

实际上Zookeeper集群中是不会出现脑裂问题的,而不会出现的原因就跟过半机制有关。有了过半机制,对于一个Zookeeper集群,要么没有Leader,要没只有1个Leader,这样就避免了脑裂问题。

ZooKeeper节点类型

(1)Znode有两种类型:

短暂:客户端和服务器端断开连接后,创建的节点自己删除持久:客户端和服务器端断开连接后,创建的节点不删除

(2)Znode有四种形式的目录节点(默认是persistent )

持久化目录节点:客户端与zookeeper断开连接后,该节点依旧存在持久化顺序编号目录节点: 客户端与zookeeper断开连接后,该节点依旧存在,只是Zookeeper给该节点名称进行顺序编号临时目录节点: 客户端与zookeeper断开连接后,该节点被删除临时顺序编号目录节点:客户端与zookeeper断开连接后,该节点被删除,只是Zookeeper给该节点名称进行顺序编号

临时节点、永久节点用来作什么?

临时节点常用于实现分布式锁等功能,而永久节点则用于存储一些配置信息、元数据等。

能否为临时节点创建子节点

ZooKeeper 中不能为临时节点创建子节点,如果需要创建子节点,应该将要创建子节点的节点创建为永久性节点

是哪个进程在Zookeeper上注册临时节点

一般情况下,是客户端进程通过ZooKeeper的API在zk上注册临时节点。客户端注册的临时节点在客户端连接断开后会自动删除。

ZooKeeper对节点的watch监听是永久的吗

不是,一个Watch事件是一个一次性的触发器,当被设置了Watch的数据发生了改变的时候,则服务器将这个改变发送给设置了Watch的客户端,以便通知它们。

为什么不是永久的,举个例子,如果服务端变动频繁,而监听的客户端很多情况下,每次变动都要通知到所有的客户端,这太消耗性能了。在实际应用中,很多情况下,我们的客户端不需要知道服务端的每一次变动,我只要最新的数据即可。

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

可以分为两种情况,一是将写入请求直接发送给 leader ,一是将写入请求发给 follower(该情况也会将写入请求转发给 leader)。

(1)客户端会向ZK集群中的一台机器server1发送写数据的请求。

(2)server1接收到请求后,马上会通知leader 有写数据的请求来了

(3)leader拿到请求后,进行广播,让集群每一台机器都准备要写数据

(4)集群中的所有机机器接收到leader广播后都回应一下leader

(5) leader再次进行广播 开始写数据,其他机器接收到广播后也开始写数据

(6)数据成功写入后,回应leader,最后由leader来做整个事务提交

(7)当数据成功写入后,有最初和客户端发生连接的 server1 回应客户端数据写入成功。

zookeeper 是如何实现分布式锁的

(1)首先 zookeeper 集群接收到获取锁的请求时,就会在 locks 节点下创建一个临时顺序节点。

(2)然后先对当前节点下的所有子节点进行排序,判断自己是不是最小的节点,如果是,就可以获取到锁,如果不是,就说明锁已被其他客户端获取,然后可以对前一个节点进行监听,等待客户端把自己创建的节点删除。

(3)获取到锁后,进行业务的处理,释放锁的时候删除该临时节点,然后后面的节点就会接收到通知。

当自己master连接不上Zookeeper,会怎么办

当一个Hadoop集群中的Active NameNode连接不上ZooKeeper时,它会尝试在一段时间内重新连接ZooKeeper。如果在此期间内,Active NameNode仍然无法连接到ZooKeeper,会直接转为standby。

Zookeeper的数据存储在什么地方

(1)内存中(DataTree、DataNode、ZKDatabase):ZooKeeper 会将一部分数据存储在内存中,以提高读取速度和性能。

(2)磁盘上的快照文件:ZooKeeper 会定期将内存中的数据持久化到磁盘上的快照文件中,以便在重启后恢复状态。

(2)事务日志:ZooKeeper 会将所有更新操作记录在事务日志中,以确保数据的持久性和一致性。

总结一下哪些地方用到了 zookeeper

(1)Hadoop HA:配置高可用

(2)HBase:保证master的高可用、RegionServer 的监控、元数据的入口以及集群配置的维护等工作。

(3)Kafka:controller的选举、broker 的注册、topic 的注册

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以添加V获取:vip204888 (备注大数据)

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

eeper

(1)Hadoop HA:配置高可用

(2)HBase:保证master的高可用、RegionServer 的监控、元数据的入口以及集群配置的维护等工作。

(3)Kafka:controller的选举、broker 的注册、topic 的注册

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以添加V获取:vip204888 (备注大数据) [外链图片转存中…(img-iAjkPg1h-1713393385221)]

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

好文链接

评论可见,请评论后查看内容,谢谢!!!评论后请刷新页面。

大家都在找:

大数据:大数据与会计

zookeeper:安装zookeeper教程

学习:学习励志

大家都在看: