Kafka六大使用场景以及核心概念，你知道几个？-28资讯网—

Kafka六大使用场景以及核心概念，你知道几个？

2024-05-16 09:10:26 软件 124观看

摘要1. 为什么介绍Kafka1.高吞吐量：单机每秒处理十万级的消息量。即使存储了许多TB的消息，它也保持稳定的性能。2.高性能：单节点支持上千个客户端，并保证零停机和零数据丢失。利用Linux的页缓存顺序读，顺序写零拷贝3.持久化数

1. 为什么介绍Kafka

1.高吞吐量：单机每秒处理十万级的消息量。即使存储了许多TB的消息，它也保持稳定的性能。

2.高性能：单节点支持上千个客户端，并保证零停机和零数据丢失。

利用Linux的页缓存
顺序读，顺序写
零拷贝

3.持久化数据存储：将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防止数据丢失。

4.分布式系统: 易于向外扩展。所有的Producer、Broker和Consumer都会有多个，均为分布式的。无需停机即可扩展机器。多个Producer、Consumer可能是不同的应用。

5.可靠性: Kafka是分布式，分区，复制和容错的。

6.客户端状态维护：消息被处理的状态是在Consumer端维护，而不是由server端维护。当失败时能自动平衡。

7.支持online和offline的场景。

8.支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语言。

2. Kafka应用场景

2.1. 消息队列

Kafka 最常见的应用场景就是作为消息队列。 Kafka 提供了一个可靠且可扩展的消息队列，可以处理大量数据。

Kafka 可以实现不同系统间的解耦和异步通信，如订单系统、支付系统、库存系统等。在这个基础上 Kafka 还可以缓存消息，提高系统的可靠性和可用性，并且可以支持多种消费模式，如点对点或发布订阅。

2.2. 日志处理与分析(最常用的场景)

公司可以用Kafka可以收集各种服务的Log，典型就是 ELK（Elastic-Logstash-Kibana）。Kafka 有效地从每个实例收集日志流。

图片

2.3. 推荐数据流

流式处理是 Kafka 在大数据领域的重要应用场景之一，其与流处理框架（如Spark Streaming、Storm、Flink等）框架进行集成。主要内容包括：

Kafka作为流式处理平台的数据源或数据输出：Kafka可以作为流数据的中介，将实时数据发送到Kafka中，同时也可以从Kafka中读取数据进行处理和分析。推荐系统的工作流程：以淘宝、京东等线上商城网站的推荐系统为例，描述了推荐系统的工作流程。主要包括：

将用户的点击流数据发送到Kafka中。
使用Flink等流处理框架读取Kafka中的流数据，进行实时聚合处理。
机器学习算法使用来自数据湖的聚合数据进行训练，同时算法工程师也会对推荐模型进行调整。
推荐系统持续改进对每个用户的推荐相关性。

图片

2.4. 系统监控与报警

与日志分析系统类似，我们需要收集系统指标以进行监控和故障排除。不同之处在于，指标是结构化数据，而日志是非结构化文本。指标数据被发送到 Kafka 中，并在 Flink 中进行聚合。下图展示了常见监控报警系统的工作流程：

采集器读取购物车指标发送到 Kafka 中
Flink 读取 Kafka 中的指标数据进行聚合处理
实时监控系统和报警系统读取聚合数据作展示以及报警处理

图片

2.5. CDC（数据变更捕获）

CDC(Change data capture) 将数据库更改流式传输到其他系统，以便进行复制或缓存/索引更新。例如，在下图中，事务日志被发送到 Kafka，并由 ElasticSearch、Redis 和辅助数据库引入。

图片

2.6. 系统迁移

Kafka 可以用来作为老系统升级到新系统过程中的消息传递中间件（Kafka），以此来降低迁移风险。在下图中，为了升级下图中的订单服务，我们更新了旧版订单服务，以使用 Kafka 的输入并将结果写入 ORDER 主题。新的订单服务使用相同的输入，并将结果写入 ORDERNEW 主题，对帐服务比较 ORDER 和 ORDERNEW。如果它们相同，则新服务通过测试。

图片

3. Kafka核心概念

3.1. 生产者(Producer)

生产者: 创建消息,将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的 segment 文件中一般情况下，一个消息会被发布到一个特定的主题上。

默认情况下通过轮询把消息均衡地分布到主题的所有分区上。
在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。
生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。

3.2. 消费者（Consumer）

消费者读取消息。

消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。
消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。
消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。
如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配。

3.3. Broker

一个独立的Kafka 服务器被称为broker。

broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。

如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）控制器负责管理工作，包括将分区分配给broker 和监控broker 在集群中，一个分区从属于一个broker，该broker 被称为分区的首领。

图片

3.4. Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。

物理上不同Topic的消息分开存储。

Topic就好比数据库的表，尤其是分库分表之后的逻辑表。

3.5. 分区(Partition)

Topic可以被分为若干个分区，一个分区就是一个提交日志
消息以追加方式写入分区，然后以先入先出的顺序读取
无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序
Kafka 通过分区来实现数据冗余和伸缩性
在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1

图片

本文链接：http://www.28at.com/showinfo-26-88393-0.htmlKafka六大使用场景以及核心概念，你知道几个？

声明：本网页内容旨在传播知识，不代表本站观点，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。

显示全文

全部频道