Kafka 学习

学习中

Kafka概念

Kafka 传统定义：是一个分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。

kafka 最新定义：开源的分布式事件流平台，用于高性能数据管道 、流分析、数据集成和关键任务应用。

野心非常大，不甘心只做消息队列

发布/订阅：消息的发布者不会将消息直接发送给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接收感兴趣的消息。

在大数据库场景主要采用 KafKa，JavaEE 开发中采用 ActiveMQ、RabbitMQ、RocketMQ

⭐ 消息队列作用：削峰、异步、解耦

⭐ 消息队列模式

• 点对点模式：消费者主动拉取数据，消息成功消费后清除消息
• 发布/订阅模式：可以有多个 topic 主题，每个消费者相互独立，消费者消费数据后不删除数据

Kafka 基础架构

1. 为方便扩展，提高吞吐量，一个 topic 分为多个 partition
2. 配合分区的设计，提出消费者组的概念，组内每个消费者并行消费
   • 一个分区 partition，只能由一个消费者消费。如果由多个消费者不利于消息的管理
3. 为提高可用性，为每个 partition 增加若干副本
   • 分为 leader & follower，只针对于 leader 进行生产和消费
   • 只有 leader 挂掉后 follower 才能成为 leader，才能进行生产和消费
4. Zookeeper 管理 Kafka 集群
   • 记录在线的 broker
   • 记录 partitions 中的 leader

• Producer：生产者，负责将客户端生产的消息发送到 Kafka 中，可以支持消息的异步发送和批量发送；
• broker：服务代理节点，Kafka 集群中的一台服务器就是一个 broker，可以水平无限扩展，同一个 Topic 的消息可以分布在多个 broker 中；
• Consumer：消费者，通过连接到 Kafka 上来接收消息，用于相应的业务逻辑处理。 ZooKeeper：管理 Kafka 集群
• Consumer Group：消费者组，指的是多个消费者共同组成一个组来消费一个 Topic 中的消息。

Kafka 重要概念

Topic 与 Partition

一个 Topic 是一个逻辑上的消息分类，可以看作是一个消息的容器。生产者将消息发布到特定的 Topic 中，而消费者则从 Topic 中订阅并消费消息。

每个 Topic 可以被分成多个 Partition，每个 Partition 是一个有序的消息序列。Partition 在物理上是分布在不同的 Broker 节点上的，这样可以实现消息的分布式存储和处理。

Partition 的数量是在创建 Topic 时指定的，可以根据需求进行设置。每个 Partition 都有一个唯一的标识符（Partition ID），通常是一个整数。

Partition的存在有以下几个重要的作用：

1. 提供了消息的并行处理能力：不同的 Partition 可以在不同的 Broker 节点上并行处理消息，提高了整体的吞吐量。
2. 实现了消息的顺序性：每个 Partition 内的消息是有序的，但不同 Partition 之间的消息顺序是不保证的。
3. 提供了消息的冗余和容错能力：每个 Partition 都有多个副本（Replica），分布在不同的 Broker 节点上，当某个 Broker 节点故障时，其他节点上的副本可以继续提供服务。

在消费者消费消息时，可以选择订阅整个 Topic，也可以选择订阅特定的 Partition。 Topic 是消息的逻辑分类，而 Partition 是 Topic 的物理分片，提供了并行处理、顺序性和容错能力。通过合理的设置 Partition 数量和消费者的订阅方式，可以实现高效的消息处理和分布式的消息传递。

由于一个分区只属于一个主题，很多时候也会被叫做主题分区(Topic-Partition)。

Leader 和 Follower

一个分区会有多个副本，副本之间是一主(Leader)多从(Follower)的关系，Leader 对外提供服务，这里的对外指的是与客户端程序进行交互，而 Follower 只是被动地同步 Leader 而已，不能与外界进行交互。

当然了，你可能知道在很多其他系统中 Follower 是可以对外提供服务的，比如 MySQL 的从库是可以处理读操作的，但是在 Kafka 中 Follower 只负责消息同步，不会对外提供服务。

Kafka 多副本机制

Kafka 为分区引入了多副本机制，同一分区的不同副本中保存的信息是相同的，通过多副本机制实现了故障的自动转移，当集群中某个 broker 失效时仍然能保证服务可用，可以提升容灾能力。

副本处于不同 broker 中，生产者与消费者只和 Leader 副本进行交互，而 Follower 副本只负责消息的同步。当 Leader 副本出现故障时，会从 Follower 副本中重新选举新的 Leader 副本对外提供服务。

• AR(Assigned Replicas)：一个分区中的所有副本统称为 AR；
• ISR(In-Sync Replicas)：Leader 副本和所有保持一定程度同步的 Follower 副本（包括 Leader 本身）组成 ISR；
• OSR(Out-of-Sync Raplicas)：与 ISR 相反，没有与 Leader 副本保持一定程度同步的所有Follower 副本组成OSR；

AR = ISR + OSR

生产者会将消息发送给 Leader 副本，然后 Follower 副本才能从 Leader 中拉取消息进行同步，在同一时刻，所有副本中的消息不完全相同， 也就是说同步期间，Follower 相对于 Leader 而言会有一定程度上的滞后，当然这个滞后程度是可以通过参数来配置的。

Leader 负责维护和跟踪 ISR 集合中所有 Follower 副本的滞后状态，当 Follower 出现滞后太多或者失效时，Leader 将会把它从 ISR 集合中剔除。

当然，如果 OSR 集合中有 Follower 同步范围追上了 Leader，那么 Leader 也会把它从 OSR 集合中转移至 ISR 集合。

一般情况下，当 Leader 发送故障或失效时，只有 ISR 集合中的 Follower 才有资格被选举为新的 Leader，而 OSR 集合中的 Follower 则没有这个机会（不过可以修改参数配置来改变）。

安装使用

安装部署

集群规划

我的虚拟机里面由 3 个 CentOS 系统，所以规划为：

101	102	103
zk	zk	zk
kafka	kafka	kafka

每一台机器内都安装 zookeeper 和 kafka，我这里为了方便就只在 103 内配置了 zk。

集群部署

步骤0：配置 zk 集群，也可以单机

步骤1：下载 (opens new window)

2.12 版本指 Scale 版本，3.0.0 版本指 Kafka 版本。

步骤2：解压 tar -zxvf kafka_2.12-3.0.0.tgz

步骤3：重命名 mv kafka_2.12-3.0.0 kafka，把解压后的文件名改为 kafka

步骤4：配置 kafka/config/server.properties

# kafka 集群中身份唯一表示，三个 broker 分别配置 0 1 2
broker.id=0

# 存储 kafka 数据，默认放在 temp 中，会被定期清理
log.dirs=/opt/kafka/datas

# 配置 zk 集群，/kafka 表示都在 kafka 节点上，后面需要找个集群时可以直接删掉
# zookeeper.connect=192.168.150.101:2181,192.168.150.102:2181,192.168.150.103:2181/kafka
# 也可以不使用集群，就配置个单机
zookeeper.connect=192.168.150.103:2181/kafka

分别配置 3 个 kafka，注意 broker.id 要不同。

步骤5：配置环境变量

vim /etc/profile.d/my_env.sh

为每个节点，添加以下内容：

#KAFKA_HOME
export KAFKA_HOME=/opt/kafka
export PATH=$PATH:$KAFKA_HOME/bin

刷新：source /etc/profile

步骤6：启动 zookeeper

步骤7：启动 kafka

kafka-server-start.sh -daemon config/server.properties

流处理

流处理与普通业务

流处理之所以被称为"流"，是因为它处理的是连续不断的数据流，而不是离散的、静态的数据集合。

与传统的批处理不同，流处理是实时处理数据流的一种方式。它可以在数据到达时立即进行处理，并持续地对数据进行处理和响应。流处理框架可以处理无限的数据流，而不需要等待所有数据都到达才开始处理。

与普通的处理业务相比，流处理具有以下几个不同之处：

• 实时性：流处理是实时处理数据流的方式，可以在数据到达时立即进行处理。这使得流处理能够及时响应数据的变化和事件的发生，适用于需要实时性的应用场景。
• 连续性：流处理是对连续的数据流进行处理，而不是对离散的数据集合进行处理。它可以处理无限的数据流，并持续地对数据进行处理和分析。
• 有状态性：流处理框架可以维护和更新状态信息，以支持更复杂的数据处理逻辑。这意味着流处理可以跟踪和记忆之前处理过的数据，从而实现更丰富的计算和分析。
• 灵活性：流处理框架通常提供了丰富的API和功能，可以进行各种数据转换、聚合、过滤等操作。它们还支持窗口操作、时间窗口计算等高级功能，使得开发者可以根据需求进行灵活的数据处理。

Kafka在流处理中的作用

Kafka在流处理中的地位主要体现在以下几个方面：

• 数据源：作为数据源，可以提供实时的、连续的数据流。流处理框架可以从Kafka中订阅数据流，并对数据进行处理和分析。
• 数据存储：作为数据存储，可以将处理后的数据持久化存储在Kafka主题中。这些数据可以被其他应用程序或服务订阅和使用。
• 数据传递：作为消息队列系统，可以实现高效的数据传递和分发。流处理框架可以利用Kafka的分布式消息传递能力，将数据流分发到多个消费者节点上进行处理。
• 数据处理：Kafka Streams 是一个直接集成在 Kafka 客户端中的流处理库，可以在消费者端进行流处理。它提供了丰富的API和功能，如窗口操作、聚合、过滤、连接等，可以方便地进行实时数据处理。
• 数据一致性：提供了 Exactly-once 语义的支持，确保每条消息在处理过程中只会被处理一次，避免了重复处理和数据丢失的问题。

参考

一文带你搞懂 Kafka 的系统架构 (opens new window)