logo资料库

尚硅谷大数据Kafka.doc

第1页 / 共53页
第2页 / 共53页
第3页 / 共53页
第4页 / 共53页
第5页 / 共53页
第6页 / 共53页
第7页 / 共53页
第8页 / 共53页
资料共53页,剩余部分请下载后查看
一 Kafka概述
1.1 Kafka是什么
1.2 消息队列内部实现原理
1.3 为什么需要消息队列
1.4 Kafka架构
1.5 分布式模型
二 Kafka集群部署
2.1 环境准备
2.1.1 集群规划
2.1.2 jar包下载
2.1.3 虚拟机准备
2.1.4 安装jdk
2.1.5 安装Zookeeper
2.2 Kafka集群部署
2.3 Kafka命令行操作
2.4 Kafka配置信息
2.4.1 Broker配置信息
2.4.2 Producer配置信息
2.4.3 Consumer配置信息
三 Kafka工作流程分析
3.1 Kafka生产过程分析
3.1.1 写入方式
3.1.2 分区(Partition)
3.1.3 副本(Replication)
3.1.4 写入流程
3.2 Broker 保存消息
3.2.1 存储方式
3.2.2 存储策略
3.2.3 Zookeeper存储结构
3.3 Kafka消费过程分析
3.3.1 消费模型
3.3.2 高级API
3.3.3 低级API
3.3.4 消费者组
3.3.5 消费方式
3.3.6 消费者组案例
4.1 环境准备
4.2 Kafka生产者Java API
4.2.1 创建生产者(过时的API)
4.2.2 创建生产者(新API)
4.2.3 创建生产者带回调函数(新API)
4.2.4 自定义分区生产者
4.3 Kafka消费者Java API
5.1 拦截器原理
5.2 拦截器案例
六 kafka Streams
6.1 概述
6.1.1 Kafka Streams
6.1.2 Kafka Streams特点
6.1.3 为什么要有Kafka Stream
6.2 Kafka Stream数据清洗案例
七 常见问题
尚硅谷大数据技术之 Kafka ——————————————————————————— —— 尚硅谷大数据技术之 Kafka 一 Kafka 概述 1.1 Kafka 是什么 在流式计算中,Kafka 一般用来缓存数据,Storm 通过消费 Kafka 的数据进行计算。 1)Apache Kafka 是一个开源消息系统,由 Scala 写成。是由 Apache 软件基金会开发的 一个开源消息系统项目。 2)Kafka 最初是由 LinkedIn 公司开发,并于 2011 年初开源。2012 年 10 月从 Apache Incubator 毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。 3)Kafka 是一个分布式消息队列。Kafka 对消息保存时根据 Topic 进行归类,发送消息 者称为 Producer,消息接受者称为 Consumer,此外 kafka 集群有多个 kafka 实例组成,每个 实例(server)成为 broker。 4)无论是 kafka 集群,还是 producer 和 consumer 都依赖于 zookeeper 集群保存一些 meta 信息,来保证系统可用性。 1.2 消息队列内部实现原理 (1)点对点模式(一对一,消费者主动拉取数据,消息收到后消息清除) 点对点模型通常是一个基于拉取或者轮询的消息传送模型,这种模型从队列中请求信 息,而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
尚硅谷大数据技术之 Kafka ——————————————————————————— —— 收者接收处理,即使有多个消息监听者也是如此。 (2)发布/订阅模式(一对多,数据生产后,推送给所有订阅者) 发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订阅 者,临时订阅者只在主动监听主题时才接收消息,而持久订阅者则监听主题的所有消息,即 使当前订阅者不可用,处于离线状态。 1.3 为什么需要消息队列 1)解耦: 允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。 2)冗余: 消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风 险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需 要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你 使用完毕。 3)扩展性: 因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要 另外增加处理过程即可。 4)灵活性 & 峰值处理能力: 在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量并不常见。 如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列 能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃。 5)可恢复性: 系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所 以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。 6)顺序保证: 在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且 能保证数据会按照特定的顺序来处理。(Kafka 保证一个 Partition 内的消息的有序性) 7)缓冲: 有助于控制和优化数据流经过系统的速度,解决生产消息和消费消息的处理速度不一致 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
尚硅谷大数据技术之 Kafka ——————————————————————————— —— 的情况。 8)异步通信: 很多时候,用户不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户 把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要 的时候再去处理它们。 1.4 Kafka 架构 1)Producer :消息生产者,就是向 kafka broker 发消息的客户端。 2)Consumer :消息消费者,向 kafka broker 取消息的客户端 3)Topic :可以理解为一个队列。 4)Consumer Group(CG):这是 kafka 用来实现一个topic 消息的广播(发给所有的 consumer) 和单播(发给任意一个 consumer)的手段。一个 topic 可以有多个 CG。topic 的消息会复制- 给 consumer。如果需要实现广播,只要每个 consumer 有一个独立的 CG 就可以了。要实现 单播只要所有的 consumer 在同一个 CG。用 CG 还可以将 consumer 进行自由的分组而不需 要多次发送消息到不同的 topic。 5)Broker :一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。 6)Partition:为了实现扩展性,一个非常大的 topic 可以分布到多个 broker(即服务器)上, 一个 topic 可以分为多个 partition,每个 partition 是一个有序的队列。partition 中的每条消息 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
尚硅谷大数据技术之 Kafka ——————————————————————————— —— 都会被分配一个有序的 id(offset)。kafka 只保证按一个 partition 中的顺序将消息发给 consumer,不保证一个 topic 的整体(多个 partition 间)的顺序。 7)Offset:kafka 的存储文件都是按照 offset.kafka 来命名,用 offset 做名字的好处是方便查 找。例如你想找位于 2049 的位置,只要找到 2048.kafka 的文件即可。当然 the first offset 就 是 00000000000.kafka 1.5 分布式模型 Kafka 每个主题的多个分区日志分布式地存储在 Kafka 集群上,同时为了故障容错,每 个 分 区 都 会 以 副 本 的 方 式 复 制 到 多 个 消 息 代 理 节 点 上 。 其 中 一 个 节 点 会 作 为 主 副 本 (Leader),其他节点作为备份副本(Follower,也叫作从副本)。主副本会负责所有的客 户端读写操作,备份副本仅仅从主副本同步数据。当主副本出现故障时,备份副本中的一个 副本会被选择为新的主副本。因为每个分区的副本中只有主副本接受读写,所以每个服务器 端都会作为某些分区的主副本,以及另外一些分区的备份副本,这样 Kafka 集群的所有服务 端整体上对客户端是负载均衡的。 Kafka 的生产者和消费者相对于服务器端而言都是客户端。 Kafka 生产者客户端发布消息到服务端的指定主题,会指定消息所属的分区。生产者发 布消息时根据消息是否有键,采用不同的分区策略。消息没有键时,通过轮询方式进行客户 端负载均衡;消息有键时,根据分区语义(例如 hash)确保相同键的消息总是发送到同一 分区。 Kafka 的消费者通过订阅主题来消费消息,并且每个消费者都会设置一个消费组名称。 因为生产者发布到主题的每一条消息都只会发送给消费者组的一个消费者。所以,如果要实 现传统消息系统的“队列”模型,可以让每个消费者都拥有相同的消费组名称,这样消息就 会负责均衡到所有的消费者;如果要实现“发布-订阅”模型,则每个消费者的消费者组名 称都不相同,这样每条消息就会广播给所有的消费者。 分区是消费者现场模型的最小并行单位。如下图(图 1)所示,生产者发布消息到一台 服务器的 3 个分区时,只有一个消费者消费所有的 3 个分区。在下图(图 2)中,3 个分区 分布在 3 台服务器上,同时有 3 个消费者分别消费不同的分区。假设每个服务器的吞吐量时 300MB,在下图(图 1)中分摊到每个分区只有 100MB,而在下图(图 2)中,集群整体的 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
尚硅谷大数据技术之 Kafka ——————————————————————————— —— 吞吐量有 900MB。可以看到,增加服务器节点会提升集群的性能,增加消费者数量会提升 处理性能。 同一个消费组下多个消费者互相协调消费工作,Kafka 会将所有的分区平均地分配给所 有的消费者实例,这样每个消费者都可以分配到数量均等的分区。Kafka 的消费组管理协议 会动态地维护消费组的成员列表,当一个新消费者加入消费者组,或者有消费者离开消费组, 都会触发再平衡操作。 Kafka 的消费者消费消息时,只保证在一个分区内的消息的完全有序性,并不保证同一 个主题汇中多个分区的消息顺序。而且,消费者读取一个分区消息的顺序和生产者写入到这 个分区的顺序是一致的。比如,生产者写入“hello”和“Kafka”两条消息到分区 P1,则消 费者读取到的顺序也一定是“hello”和“Kafka”。如果业务上需要保证所有消息完全一致, 只能通过设置一个分区完成,但这种做法的缺点是最多只能有一个消费者进行消费。一般来 说,只需要保证每个分区的有序性,再对消息假设键来保证相同键的所有消息落入同一分区, 就可以满足绝大多数的应用。 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
尚硅谷大数据技术之 Kafka ——————————————————————————— —— 二 Kafka 集群部署 2.1 环境准备 2.1.1 集群规划 hadoop102 zk kafka 2.1.2 jar 包下载 hadoop103 zk kafka hadoop104 zk kafka http://kafka.apache.org/downloads.html 2.1.3 虚拟机准备 1)准备 3 台虚拟机 2)配置 ip 地址 尚硅谷大数据技术 之修改为静态ip.doc 3)配置主机名称 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
尚硅谷大数据技术之 Kafka ——————————————————————————— —— 尚硅谷大数据技术 之修改主机名.doc 4)3 台主机分别关闭防火墙 [root@hadoop102 atguigu]# chkconfig iptables off [root@hadoop103 atguigu]# chkconfig iptables off [root@hadoop104 atguigu]# chkconfig iptables off 2.1.4 安装 jdk 尚硅谷大数据技术 之安装jdk.doc 2.1.5 安装 Zookeeper 0)集群规划 在 hadoop102、hadoop103 和 hadoop104 三个节点上部署 Zookeeper。 1)解压安装 (1)解压 zookeeper 安装包到/opt/module/目录下 [atguigu@hadoop102 software]$ tar -zxvf zookeeper-3.4.10.tar.gz -C /opt/module/ (2)在/opt/module/zookeeper-3.4.10/这个目录下创建 zkData mkdir -p zkData (3)重命名/opt/module/zookeeper-3.4.10/conf 这个目录下的 zoo_sample.cfg 为 zoo.cfg mv zoo_sample.cfg zoo.cfg 2)配置 zoo.cfg 文件 (1)具体配置 dataDir=/opt/module/zookeeper-3.4.10/zkData 增加如下配置 #######################cluster########################## server.2=hadoop102:2888:3888 server.3=hadoop103:2888:3888 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
尚硅谷大数据技术之 Kafka ——————————————————————————— —— server.4=hadoop104:2888:3888 (2)配置参数解读 Server.A=B:C:D。 A 是一个数字,表示这个是第几号服务器; B 是这个服务器的 ip 地址; C 是这个服务器与集群中的 Leader 服务器交换信息的端口; D 是万一集群中的 Leader 服务器挂了,需要一个端口来重新进行选举,选出一个 新的 Leader,而这个端口就是用来执行选举时服务器相互通信的端口。 集群模式下配置一个文件 myid,这个文件在 dataDir 目录下,这个文件里面有一个 数据就是 A 的值,Zookeeper 启动时读取此文件,拿到里面的数据与 zoo.cfg 里面的配 置信息比较从而判断到底是哪个 server。 3)集群操作 (1)在/opt/module/zookeeper-3.4.10/zkData 目录下创建一个 myid 的文件 touch myid 添加 myid 文件,注意一定要在 linux 里面创建,在 notepad++里面很可能乱码 (2)编辑 myid 文件 vi myid 在文件中添加与 server 对应的编号:如 2 (3)拷贝配置好的 zookeeper 到其他机器上 scp -r zookeeper-3.4.10/ root@hadoop103.atguigu.com:/opt/app/ scp -r zookeeper-3.4.10/ root@hadoop104.atguigu.com:/opt/app/ 并分别修改 myid 文件中内容为 3、4 (4)分别启动 zookeeper [root@hadoop102 zookeeper-3.4.10]# bin/zkServer.sh start [root@hadoop103 zookeeper-3.4.10]# bin/zkServer.sh start [root@hadoop104 zookeeper-3.4.10]# bin/zkServer.sh start (5)查看状态 [root@hadoop102 zookeeper-3.4.10]# bin/zkServer.sh status 【更多 Java、HTML5、Android、python、大数据 资料下载,可访问尚硅谷(中国)官 网 www.atguigu.com 下载区】
分享到:
收藏