尚硅谷大数据Kafka_尚硅谷kafka资源-CSDN文库

5星 · 超过95%的资源需积分: 9 145 浏览量 2018-10-18 20:23:58 上传评论收藏 15.59MB DOC 举报

资源推荐

资源详情

资源评论

尚硅谷大数据技术之 Kafka

—————————————————————————————

尚硅谷大数据技术之 Kafka

一 Kafka 概述

1.1 Kafka 是什么

在流式计算中，Kafka 一般用来缓存数据，Storm 通过消费 Kafka 的数据进行计算。

1）Apache Kaa 是一个开源消息系统，由 Scala 写成。是由 Apache 软件基金会开发的

一个开源消息系统项目。

2）Kaa 最初是由 LinkedIn 公司开发，并于 2011 年初开源。2012 年 10 月从 Apache

Incubator 毕业。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。

3）Kaa 是一个分布式消息队列。Kaa 对消息保存时根据 Topic 进行归类，发送消息

者称为 Producer，消息接受者称为 Consumer，此外 kaa 集群有多个 kaa 实例组成，每个

实例(server)成为 broker。

4）无论是 kaa 集群，还是 producer 和 consumer 都依赖于 zookeeper 集群保存一些

meta 信息，来保证系统可用性。

1.2 消息队列内部实现原理

（1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

点对点模型通常是一个基于拉取或者轮询的消息传送模型，这种模型从队列中请求信

【更多 、、、、大数据资料下载，可访问尚硅谷（中国）官

网 下载区】

尚硅谷大数据技术之 Kafka

—————————————————————————————

息，而不是将消息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个

接收者接收处理，即使有多个消息监听者也是如此。

（2）发布/订阅模式（一对多，数据生产后，推送给所有订阅者）

发布订阅模型则是一个基于推送的消息传送模型。发布订阅模型可以有多种不同的订

阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息

即使当前订阅者不可用，处于离线状态。

1.3 为什么需要消息队列

1）解耦：

　　允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2）冗余：

消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失

风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，

需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直

到你使用完毕。

3）扩展性：

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只

要另外增加处理过程即可。

4）灵活性 & 峰值处理能力：

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。

如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队

列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

5）可恢复性：

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，

所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

6）顺序保证：

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并

且能保证数据会按照特定的顺序来处理。（Kaa 保证一个 Par**on 内的消息的有序性）

7）缓冲：

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一

【更多 、、、、大数据资料下载，可访问尚硅谷（中国）官

网 下载区】

尚硅谷大数据技术之 Kafka

—————————————————————————————

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）中，集群

整体的吞吐量有 900MB。可以看到，增加服务器节点会提升集群的性能，增加消费者数量

【更多 、、、、大数据资料下载，可访问尚硅谷（中国）官

网 下载区】

剩余45页未读，继续阅读

内容反馈

qq_39128546

2019-07-11

尚硅谷的就是不一样，不错的资料

leiweisoft2013

粉丝: 0
资源: 5

最新资源

资源上传下载、课程学习等过程中有任何疑问或建议，欢迎提出宝贵意见哦~我们会及时处理！点击此处反馈

feedback-tip