day09_kafka高级

文章目录

kafka高级
- 今日课程内容
- 核心概念整理
- Kafka的数据位移offset
- - [**为什么 Kafka 的 `offset` 就像是"书签"？**](#为什么 Kafka 的 offset 就像是“书签”？)
  - **实际意义**
- Kafka的基准/压力测试
- - 测试生产的效率
  - 测试消费的效率
- Kafka的分片与副本机制
- kafka如何保证数据不丢失
- - 生产者端
  - Broker端
  - 消费者端
  - 相关参数
- Kafka的数据存储和查询
- - 数据存储
  - 查询机制
- 生产者的分发策略
- - [**为什么 Kafka 生产者的分发策略就像是"邮递员的分拣规则"？**](#为什么 Kafka 生产者的分发策略就像是“邮递员的分拣规则”？)
  - **实际意义**
  - 分发策略：
  - 指定分区或者key
  - 内置的分区器
- 消费者的负载均衡
- - 负载均衡机制
  - 消费者组与分区
- 监控工具:kafka-eagle
- - 基本介绍
  - 启动服务:
  - 连接页面:
- Kafka中数据积压问题
- Kafka配额限速机制
- - 生产者
  - 消费者

kafka高级

今日课程内容

kafka核心概念汇总
kafka的数据位移offset
Kafka的基准/压力测试
Kafka的分片副本机制
kafka如何保证数据不丢失
kafka的消息存储及查询机制
生产者数据分发策略
消费者负载均衡机制
kafka的监控工具:kafka-eagle
Kafka中数据积压问题
Kafka配额限速机制

核心概念整理

sql 复制代码

- 生产者-producer: 负责生产消息（谁往Kafka中生产消息谁就是生产者）
- 消费者-consumer: 负责消费消息（谁从Kafka中消费消息谁就是消费者）

- 运行实例-broker:  Kafka实际工作的服务器进程,broker之间是没有主从之分

- 主题-topic: 一类消息的集合，消息往哪放从哪取相当于数据库中的表   
- 分区-partition: 数据的分区,分区数量可以大于broker节点数量,分区初始设置后,只能增大不能减小
- 副本-replica: 数据的副本,副本数量不能大于broker节点数量,副本初始设置后,不能更改!
- 主副本-leader replica: 实际负责数据读写的副本，生产者和消费者都与这个副本进行交互的
- 从副本-follower replica: 负责从主副本上同步数据，实现数据备份，保证数据可靠性

- 消费者组-consumer group: 多个消费者的集合

- AR: All Replica 所有副本的集合，等于 AR = ISR+OSR
- ISR: In Sync Replica 数据同步成功的副本（实际可用的副本）
- OSR: Out of Sync Replica 数据同步不成功的副本（不可用的副本）

Kafka的数据位移offset

简单来说 ：Kafka的offset就像是"书签"，用于标记消费者在分区中的读取位置，确保每条消息都能被准确记录和追踪。

具体而言：

定义：

offset是分区中每条消息的唯一标识，是一个单调递增的整数。

消费者通过offset记录自己已经读取到的位置，下次消费时从该位置继续读取。

管理方式 ：

自动提交 ：消费者可以配置自动提交offset，定期将当前消费位置提交到Kafka。

手动提交 ：消费者可以手动提交offset，确保消息处理成功后再提交，避免数据丢失。

存储位置 ：

Kafka内部 ：offset默认存储在Kafka的__consumer_offsets Topic中。

外部存储 ：某些场景下，offset可以存储在外部的数据库或文件中，便于管理和恢复。

实际生产场景：

在实时数据处理中，使用offset确保每条消息都被正确处理，避免数据丢失或重复消费。

在故障恢复中，通过offset快速定位消费位置，恢复数据消费。

总之：offset是Kafka中重要的概念，通过记录消费位置，确保消息的可靠处理和追踪，为数据流处理提供了强大的支持。

为什么 Kafka 的 `offset` 就像是"书签"？

标记位置：记录读取进度
- 书签：用于标记书籍中已经阅读到的位置，方便下次继续阅读。
- offset：用于标记消费者在分区中已经读取到的位置，确保下次消费时从正确的位置继续读取。
唯一标识：精准定位
- 书签：每个书签对应书籍中的一个特定位置。
- offset ：每个offset对应分区中的一条特定消息，确保每条消息都能被精准定位。
恢复阅读：快速定位
- 书签：当重新打开书籍时，可以通过书签快速找到上次阅读的位置。
- offset ：当消费者重启或故障恢复时，可以通过offset快速定位到上次消费的位置，避免数据丢失或重复消费。
灵活管理：手动或自动
- 书签：可以手动放置书签，也可以使用自动书签功能（如电子书的自动保存进度）。
- offset ：消费者可以配置自动提交 或手动提交 offset，根据业务需求灵活管理消费进度。

实际意义

**Kafka的offset**就像"书签"，通过记录消费位置，确保消息的可靠处理和追踪，为数据流处理提供了强大的支持。

分区在保存数据时，会对数据从0/1开始进行编号，用来记录数据的顺序，该编号称为偏移量offset

各自分区内的偏移量是独立的，互不影响，所有每个分区的内的数据是有序的，但是多个分区的数据之间无法保障有序

在Kafka0.8以前的kafka，消费的进度(offset)是写在zk中的，所以consumer需要知道zk的地址。这个方案有性能问题，Kafka 0.9版本之后的时候整体大改了一次，brokers 接管了消费进度，数据位移直接保存在Kafka内部主题__consumer_offsets中, consumer 不再需要和 zookeeper 通信了，这也是为什么后来使用bootstrap-server了。bootstrap-servers 会自动发现其他 broker

不同的消费者可以同时消费同一个主题，但是同一个消费者会不会重复消费呢？

生产者在生产数据的时候会生成对应的offset

消费者在消费数据的时候会记录当前已消费数据的offset

Kafka的基准/压力测试

Kafka的基准测试, 又叫压力测试, 主要是用于测试Kafka集群的吞吐量, 每秒钟最大可以生产多少条数据, 以及每秒钟最大可以消费多少条数据

如何测试,创建多个topic,依次运行然后对比每秒发送的消息数,每秒发送的数据量以及平均延迟等指标?

topic1: 1分区 1副本

topic2: 3分区 1副本相对topic1加了分区,理论上效率会提升

topic3: 1分区 3副本相对topic1加了副本,理论上效率会降低

多分区通常可以提高 Kafka 系统的整体性能和吞吐量，特别是在大规模数据处理和高并发场景下。然而，对于一些特定的应用场景，如需要严格顺序性或资源受限的情况下，单分区可能会更为适合。因此，在设计和执行 Kafka 基准测试时，需要结合具体的使用需求和场景来选择最合适的分区策略。

多副本会带来一些额外的开销，特别是在数据复制、同步和存储方面。然而，在大多数情况下，这种开销是可以接受的，因为它提高了系统的容错性和可靠性，对于大多数企业级应用来说，这是非常重要的考虑因素。

因此，在进行 Kafka 基准测试时，通常需要权衡分区数量和副本数量对性能、可靠性和成本的影响，以找到最适合特定需求的配置。

测试前提先要创建Topic

shell 复制代码

/export/server/kafka/bin/kafka-topics.sh --create --bootstrap-server node1:9092,node2:9092,node3:9092 --partitions 3 --replication-factor 2 --topic benchmark

测试生产的效率

1- 执行生产测试命令: 测试后，会增加4-5GB磁盘占用,否则会内存不足,直接崩溃!!!

shell 复制代码

/export/server/kafka/bin/kafka-producer-perf-test.sh --topic benchmark --num-records 5000000 --throughput -1 --record-size 1000 --producer-props bootstrap.servers=node1:9092,node2:9092,node3:9092 acks=1

2- 测试结果
kafka-producer-perf-test.sh 是 Apache Kafka 自带的性能测试脚本，用以测量 Kafka 生产者的性能指标。测试结果通常包含以下几个关键项：
1. Records sent: 发送的消息总数。
2. Records/sec : 每秒发送的消息数。这是一个衡量吞吐量的关键指标。
3. MB/sec : 每秒发送的数据量，以兆字节为单位。 这是一个重点指标
4. Avg. Latency (ms) : 平均延迟，以毫秒为单位。这是衡量延迟的关键指标。
5. Max Latency (ms): 最大延迟。
6. p50 Latency (ms): 50th百分位延迟。
7. p95 Latency (ms): 95th百分位延迟。
8. p99 Latency (ms): 99th百分位延迟。
9. p99.9 Latency (ms): 99.9th百分位延迟。

测试消费的效率

sql 复制代码

kafka-consumer-perf-test.sh 是 Apache Kafka 自带的消费者性能测试脚本，它能够评估 Kafka 消费者的吞吐量和其他性能指标。

1- 执行消费测试命令

shell 复制代码

/export/server/kafka/bin/kafka-consumer-perf-test.sh --broker-list node1:9092,node2:9092,node3:9092 --topic benchmark --fetch-size 1048576 --messages 5000000

2- 测试结果:

Kafka的分片与副本机制

简单来说：Kafka的分片（Partition）与副本（Replica）机制就像是"数据的分身术"，通过将数据分散存储和备份，提高系统的吞吐量和可靠性。

具体而言：

分片（Partition） ：

定义：每个Topic可以分为多个Partition，数据按顺序存储在Partition中。

作用：支持并行处理和水平扩展，提高系统的吞吐量。

副本（Replica） ：

定义：每个Partition可以有多个副本，分为Leader副本和Follower副本。

作用：通过副本机制，确保数据的高可用性和容错能力。

工作机制 ：

Leader副本：负责处理读写请求，Follower副本从Leader副本同步数据。

ISR（In-Sync Replicas）：与Leader副本保持同步的副本集合，确保数据一致性。

Leader选举：当Leader副本失效时，Kafka会从ISR中选举新的Leader，确保系统可用性。

实际生产场景：

在高并发场景中，使用Partition机制将数据分散存储，提高系统的吞吐量。

在容灾备份中，使用Replica机制确保数据的高可用性，避免数据丢失。

总之：Kafka的分片与副本机制通过数据分散存储和备份，提高了系统的吞吐量和可靠性，为大规模数据流处理提供了强大的支持。

分片：对于分布式的系统，可以将大规模的数据分开存储，比如hdfs上会把数据分成不同的block分别存储在不同的datanode上，即提高了存储能力又降低了复杂度，同时可以提高数据处理的并发能力
副本：对于分布式的系统，数据分散保存出现风险的机率高，有一个节点出现问题，数据就不完整了，所以可以利用多副本的机制提高容错

在Kafka中一个主题可以有多个分区，分区的数量建议是不要超过broker数量的3倍，可以更好的利用硬件资源，提高并行效率

一个分区可以设置多个副本，建议副本数不超过3个，即可以满足数据的容错，又不会太过影响性能

副本在broker数量满足的情况下会尽量分布在不同的broker上

副本之间会通过内部机制选举一个Leader副本，剩下的是follow副本，数据会首先写入，然后Leader会自动同步数据给follow副本

一般情况下Kafka集群也就是3、5、7台就够了，如果数据量特别大的,还可以搭建多个Kafka集群

分区有什么用呢?

sql 复制代码

作用：
1- 避免单台服务器容量的限制: 每台服务器的磁盘存储空间是有上限。Topic分成多个Partition分区，可以避免单个Partition的数据大小过大，导致服务器无法存储。利用多台服务器的存储能力，提升Topic的数据存储效率。

2- 提升Topic的吞吐量(数据读写速度): 利用多台服务器的数据读写能力、网络等资源


分区的数量有没有限制？

没有限制，分区数量和Kafka集群中的broker节点个数没有任何关系。在实际工作推荐Topic的分区数量不要超过Kafka集群中的broker节点个数的3倍，这只是一个推荐/经验值。

副本有什么用呢?

sql 复制代码

作用: 通过多副本的机制，提升数据安全性。但是副本过多，会导致冗余（重复）的数据过多


副本的数量有没有限制？
有限制，副本数量最大不能够超过Kafka集群中的broker节点个数。在实际工作中，推荐的分区的副本数量是1-3个。具体设置多少个，根据企业的数据重要程度进行选择。如果数据重要，可以将副本数设置大一些；如果数据不太重要，可以将副本数设置小一些。

kafka如何保证数据不丢失

简单来说：Kafka通过"多重保险"机制保证数据不丢失，包括生产者确认机制、副本同步机制和持久化存储，确保数据在传输和存储过程中的可靠性。

具体而言：

生产者确认机制 ：

acks参数 ：生产者发送消息后，可以设置acks参数控制确认级别：

acks=0：不等待确认，可能丢失数据。

acks=1：等待Leader副本确认，可能丢失数据。

acks=all：等待所有副本确认，确保数据不丢失。

副本同步机制 ：

ISR（In-Sync Replicas）：Kafka维护一个与Leader副本同步的副本集合（ISR），确保数据在多个副本之间同步。

Leader选举：当Leader副本失效时，Kafka会从ISR中选举新的Leader，确保数据可用性。

持久化存储 ：

日志文件：Kafka将消息持久化到磁盘的日志文件中，即使服务器重启，数据也不会丢失。

刷盘策略 ：通过配置flush参数，控制数据刷盘频率，平衡性能和数据可靠性。

实际生产场景：

在金融交易系统中，使用acks=all确保每笔交易数据不丢失。

在日志收集中，使用副本同步机制和持久化存储，确保日志数据的高可靠性。

总之：Kafka通过生产者确认机制、副本同步机制和持久化存储，提供了多重保障机制，确保数据在传输和存储过程中不丢失，为高可靠性数据流处理提供了强大支持。

生产者端

sql 复制代码

生产者端是如何保证数据不丢失的呢？
答：生产者端将消息发送给到Kafka集群以后，broker要给生产者响应信息。最关键就是ACK机制
ACK机制当中有3个参数配置值，分别是：0  1  -1(all)
0：生产者生产消息给到Kafka集群，生产者不等待（不接收）broker返回的响应信息
1：生产者生产消息给到Kafka集群，Kafka集群中的分区对应的Leader主副本所在的broker给生产者返回响应信息
-1(all)：生产者生产消息给到Kafka集群，Kafka集群中的分区对应的所有副本给生产者返回响应信息

消息的生产效率排序（由高到低）：0 > 1 > -1
消息的安全级别排序（由高到低）：-1 > 1 > 0


在实际工作中如何选择ACK参数配置？
答：根据数据的重要程度进行选择。如果数据重要，优先保证数据的安全性，再考虑生产效率；如果数据不重要，优先考虑生产效率，再尽可能提升安全级别。

数据写入：

数据成功写入leader
follow成功从leader同步数据

写入的模式：

同步：顺序执行，写入一条等待反馈，再写下一条
异步：先将数据写入缓冲区，批量写入Kafka等待反馈

数据复制的过程，通过HW机制保证消费数据可靠性（只考虑ISR队列）：

Broker端

消费者端

在Kafka0.8以前的kafka，消费的进度(offset)是写在zk中的，所以consumer需要知道zk的地址。这个方案有性能问题，Kafka 0.9版本之后的时候整体大改了一次，brokers 接管了消费进度，数据位移直接保存在Kafka内部主题__consumer_offsets中, consumer 不再需要和 zookeeper 通信了，这也是为什么后来使用bootstrap-server了。bootstrap-servers 会自动发现其他 broker

Kafka的数据存储和查询

简单来说：Kafka的数据存储和查询就像是"日志书架"，数据按顺序存储在分区中，查询时通过偏移量（Offset）快速定位，高效且可靠。

具体而言：

数据存储 ：

分区（Partition）：每个Topic分为多个分区，数据按顺序存储在分区中。

日志文件：每个分区对应一个日志文件，消息按顺序追加到日志文件中。

索引文件：Kafka为日志文件创建索引文件，支持快速定位消息。

数据查询 ：

偏移量（Offset）：每条消息在分区中有一个唯一的偏移量，消费者通过偏移量定位消息。

时间戳查询：Kafka支持通过时间戳查询消息，适用于时间范围查询。

消费者组：每个消费者组维护自己的偏移量，支持并行消费和消息重放。

实际生产场景：

在日志收集中，使用Kafka存储日志数据，通过偏移量快速查询特定日志。

在实时分析中，使用时间戳查询特定时间范围内的数据，进行实时分析。

总之：Kafka的数据存储和查询机制通过分区、日志文件和偏移量，提供了高效、可靠的数据存储和查询能力，适用于大规模数据流处理和分析。

数据存储

sql 复制代码

为什么存储是要拆分成多个文件？
	如果所有的数据都写入一个文件的话，文件的数量会越来越多，当查询读取数据时，就需要打开一个非常大的文件，文件的打开速度会变得越来越慢，影响数据的读取速度

	kafka将数据文件进行了拆分，当前数据超过1G就会创建一个新的文件，文件的名字会使用第一条数据的偏移量作为文件名。偏移量作为文件改名也方便数据的查找， 1036000偏移量的数据

	查找是会先根据查找的偏移量会文件的名称进行比对，确认数据在哪个文件中，然后再读取对应的文件数据，可以读取所有文件
	
	1-Topic的数据存放路径是：/export/server/kafka/data。在该目录下，还有其他的目录。而且是以Topic进行划分，具体目录的命名规则是：Topic名称-分区编号

	2- Topic目录下，存放的是消息的数据文件。并且是成对出现，也就是xx.log和xx.index文件

sql 复制代码

1-xx.log和xx.index它们的作用是什么？
答：
xx.log: 称之为segment片段文件，也就是一个Partition分区的数据，会被分成多个segment（log）片段文件进行存储。
xx.index: 称之为索引文件，该文件的作用是用来加快对xx.log文件内容检索的速度


2-xx.log和xx.index文件名称的意义？
答: 这个数字是xx.log文件中第一条消息的offset（偏移量）。offset偏移量从0开始编号。


3-为什么一个Partition分区的数据要分成多个xx.log（segment片段文件）文件进行存储？
答：
  1- 如果一个文件的数据量过大，打开和关闭文件都非常消耗资源
  2- 在一个大的文件中，检索内容也会非常消耗资源
  3- Kafka只是用来临时存储消息数据。会定时将过期数据删除。如果数据放在一个文件中，删除的效率低；如果数据分成了多个segment片段文件进行存储，删除的时候只需要判断segment文件最后修改时间，如果超过了保留时间，就直接将整个segment文件删除。该保留时间是通过server.sql文件中的log.retention.hours=168进行设置，默认保留168小时（7天）

shell 复制代码

# 具体配置在哪?以及怎么配置
# 在config/server.sql内
# 默认保留168小时（7天）
log.retention.hours=168

# 指定Kafka数据的位置
log.dirs=/export/server/kafka/data

查询机制

sql 复制代码

查询步骤：
1- 首先先确定要读取哪个xx.log（segment片段）文件。368776该offset的消息在368769.log文件中
2- 查询xx.log对应的xx.index，查询该条消息的物理偏移量范围
3- 根据消息的物理偏移量范围去读取xx.log文件（底层是基于磁盘的顺序读取）
4- 最终就获取到了具体的消息内容

sql 复制代码

扩展内容: 磁盘的读写中，有两种方案：随机读写   和   顺序读写。顺序读写的速度会更快
参考连接: https://www.cnblogs.com/yangqing/archive/2012/11/13/2767453.html

Kafka为什么有非常高的吞吐能力/读写性能：
https://baijiahao.baidu.com/s?id=1710624455165799096&wfr=spider&for=pc

连续索引和稀疏索引

生产者的分发策略

简单来说：Kafka生产者的分发策略就像是"邮递员的分拣规则"，决定了消息如何被分配到不同的分区（Partition）中，确保数据能够高效、均匀地分布。

具体而言：

默认策略 ：

轮询（Round Robin）：如果没有指定分区键（Partition Key），生产者会依次将消息分发到各个分区，确保数据均匀分布。

分区键策略 ：

哈希分区：如果指定了分区键（如用户ID），生产者会对分区键进行哈希计算，将消息分发到对应的分区中，确保相同键的消息总是分配到同一个分区。

自定义策略 ：

自定义分区器 ：开发者可以实现Partitioner接口，自定义数据分发逻辑，满足特定业务需求。

实际生产场景：

在日志收集中，使用轮询策略将日志数据均匀分布到各个分区，提高处理效率。

在用户行为分析中，使用哈希分区策略将同一用户的行为数据分配到同一个分区，便于后续分析。

总之：Kafka生产者的分发策略通过轮询、哈希分区和自定义分区器，确保数据能够高效、均匀地分布到各个分区中，为大规模数据处理提供了强大的支持。

为什么 Kafka 生产者的分发策略就像是"邮递员的分拣规则"？

分拣规则：决定数据去向
- 邮递员：根据地址或邮编将邮件分拣到不同的邮袋中，确保邮件能够准确投递。
- Kafka生产者：根据分区策略将消息分发到不同的分区中，确保数据能够高效、均匀地分布。
均匀分发：轮询策略
- 邮递员：如果邮件没有明确的地址，邮递员会均匀分配到不同的邮袋中。
- Kafka生产者 ：如果没有指定分区键，生产者会使用轮询策略，依次将消息分发到各个分区，确保数据均匀分布。
精准分发：哈希分区策略
- 邮递员：如果邮件有明确的地址，邮递员会根据地址将邮件分拣到对应的邮袋中。
- Kafka生产者 ：如果指定了分区键（如用户ID），生产者会使用哈希分区策略，将相同键的消息分配到同一个分区，确保数据精准分发。
自定义规则：满足特殊需求
- 邮递员：在某些情况下，邮递员可以根据特殊规则（如优先投递）分拣邮件。
- Kafka生产者 ：开发者可以通过自定义分区器，实现特定的分发逻辑，满足业务需求。

实际意义

Kafka生产者的分发策略就像"邮递员的分拣规则"，通过轮询、哈希分区和自定义分区器，确保数据能够高效、均匀地分布到各个分区中，为大规模数据处理提供了强大的支持。

何为生产者的数据分发策略呢?

sql 复制代码

指的就是生产者生产的消息，是如何保存到具体分区上

分发策略：

1- 随机分发策略：将消息发到到随机的某个分区上，还是发送到Leader主副本上。Python支持，Java不支持
2- 指定分区策略：将消息发到指定的分区上面。Python支持，Java支持
3- Hash取模策略：对消息的key先取Hash值，再和分区数取模。Python支持，Java支持
4- 轮询策略：在Kafka的2.4及以上版本，已经更名成粘性分发策略。Python不支持，Java支持
5- 自定义分发策略：Python支持，Java支持

指定分区或者key

通过send方法指定分区转发

python 复制代码

furture = producer.send(
        topic='test',
        value=f"binge is handsome{i}".encode("utf-8"),
        partition=1  # 指定分区发送
    )

python 复制代码

furture = producer.send(
        topic='test',
        value=f"binge is handsome{i}".encode("utf-8"),
        key="kafka_key" # 指定key发送
    )

指定分区的优先级大于指定key

注意: 当在发送数据的时候, 如果只传递了topic 和 value没有指定partition和key的时候, 那么此时就采用随机策略,

内置的分区器

分区器负责决定当数据来时，这个数据被分发至哪个分区

消费者的负载均衡

简单来说：Kafka消费者的负载均衡就像是"任务分配器"，通过将分区（Partition）分配给消费者组中的不同消费者，确保每个消费者都能均衡地处理数据。

具体而言：

消费者组 ：

定义：多个消费者可以组成一个消费者组，共同消费一个Topic的数据。

作用：通过消费者组实现并行消费，提高数据处理效率。

负载均衡机制 ：

分区分配：Kafka会将Topic的Partition分配给消费者组中的消费者，确保每个Partition只被一个消费者消费。

重平衡（Rebalance）：当消费者加入或退出时，Kafka会触发重平衡，重新分配Partition，确保负载均衡。

分配策略 ：

Range策略：按Partition范围分配，可能导致分配不均。

Round Robin策略：按轮询方式分配，确保分配均匀。

Sticky策略：尽量保持原有分配，减少重平衡的影响。

实际生产场景：

在高并发场景中，使用消费者组和负载均衡机制，提高数据处理的并行度和效率。

在动态扩展中，通过重平衡机制，自动调整分区分配，适应消费者数量的变化。

总之：Kafka消费者的负载均衡机制通过分区分配和重平衡，确保每个消费者都能均衡地处理数据，为高并发数据处理提供了强大的支持。

负载均衡机制

sql 复制代码

Kafka集群中每分钟新产生400条数据，下游的一个消费者每分钟能够处理400条数据。

随着业务发展，Kafka集群中每分钟新产生1200条数据，下游的一个消费者每分钟能够处理400条数据。
答：会导致broker中积压的消息条数越来越多，造成消息处理不及时。可以增加消费者数量，并且将这些消费者放到同一个消费组当中

随着业务发展，Kafka集群中每分钟新产生1600条数据，下游的一个消费者每分钟能够处理400条数据。
答：会导致broker中积压的消息条数越来越多，造成消息处理不及时。再增加消费组中消费者的个数已经无法解决问题。


如何解决：
    1- 增加消费组中消费者的个数
    2- 提高下游消费者对消息的处理效率

sql 复制代码

Kafka消费者的负载均衡机制
1- 在同一个消费组中，一个Topic中一个分区的数据，只能被同个消费组中的一个消费者所消费，不能被同个消费组中多个消费者所消费。但是一个消费组内的一个消费者可以消费多个分区的数据。也就是分区和消费者的对应关系，多对一
2- 在同一个消费组中，消费者的个数最多不能超过Topic的分区数。如果超过了，就会有一些消费者处于闲置状态，消费不到任何数据。
3- 不同的消费组中的消费者，可以对一个Topic的数据同时消费，也就是不同消费组间没有任何关系。也就是Topic的数据能够被多个消费组中的消费者重复消费。

消费者组与分区

查看当前消费者组列表

shell 复制代码

/export/server/kafka/bin/kafka-consumer-groups.sh --bootstrap-server node1:9092,node2:9092,node3:9092 --list

查看消费者组详情信息

shell 复制代码

/export/server/kafka/bin/kafka-consumer-groups.sh --bootstrap-server node1:9092,node2:9092,node3:9092 --group g_1 --describe

场景一：三个分区，一个消费者组里有一个消费者

1- 在同一个消费组中，一个Topic中一个分区的数据，只能被同个消费组中的一个消费者所消费，不能被同个消费组中多个消费者所消费。但是一个消费组内的一个消费者可以消费多个分区的数据。也就是分区和消费者的对应关系，多对一

所有的分区都由这个一个消费进行消费

场景二：三个分区，一个消费者组里有四个消费者

2- 在同一个消费组中，消费者的个数最多不能超过Topic的分区数。如果超过了，就会有一些消费者处于闲置状态，消费不到任何数据。

规则：同一个分区只能分配给一个消费者组内的一个消费者消费

划分分区时最好保证消费者的数量与分区相等

当消费者数据大于分区数量时，肯定有消费者空闲

场景三：三个分区，两个消费者组分别有四个消费者

3- 不同的消费组中的消费者，可以对一个Topic的数据同时消费，也就是不同消费组间没有任何关系。也就是Topic的数据能够被多个消费组中的消费者重复消费。

监控工具:kafka-eagle

基本介绍

Kafka Eagle是一个用于监控和管理kafka的开源组件，可以同时监控多个kafka集群,

通过Kafka Eagle可以看到当前的消费者组，对于每个组，他们正在使用的主题以及该组在每个主题中的偏移量，消费积压等等
JMX（Java Management Extensions，即 Java 管理扩展）是一个为应用程序、设备、系统等植入管理功能的框架。kafka 中已经集成该框架

它提供了对Java应用程序和JVM的监控和管理功能。通过JMX，我们可以监控服务器中的各种资源的使用情况，CPU、内存,JVM内存的使用情况.

安装kafka-eagle 参考安装文件，只需要在一台服务器上安装即可,版本是1.4.6

启动服务:

shell 复制代码

/export/server/kafka-eagle-bin-1.4.6/kafka-eagle-web-1.4.6/bin/ke.sh start

连接页面:

http://node1.itcast.cn:8048/ke

默认用户为admin，密码为：123456

Kafka中数据积压问题

简单来说：Kafka中的数据积压问题就像是"快递堆积"，当消费者处理速度跟不上生产者发送速度时，数据会在Kafka中堆积，可能导致延迟和资源耗尽。
具体而言：
- 原因：
  - 消费者处理能力不足：消费者处理速度慢，无法及时消费数据。
  - 分区分配不均：某些分区数据量过大，导致部分消费者负载过高。
  - 网络或硬件瓶颈：网络带宽或硬件资源不足，影响数据处理速度。
- 解决方案 ：
  - 增加消费者：通过增加消费者数量或提升消费者处理能力，加快数据消费速度。
  - 优化分区分配：调整分区分配策略，确保数据均匀分布。
  - 扩容集群：增加Kafka集群的Broker节点，提升整体处理能力。
  - 监控和告警：通过监控工具（如Kafka Manager、Prometheus）实时监控数据积压情况，及时采取措施。
实际生产场景：
- 在日志收集中，使用多个消费者并行处理日志数据，避免数据积压。
- 在实时分析中，通过优化分区分配和增加消费者，确保数据及时处理。
总之：Kafka中的数据积压问题通过增加消费者、优化分区分配和扩容集群等措施，可以有效缓解，确保数据处理的及时性和高效性。

出现积压的原因:

因为数据写入目的容器失败,从而导致消费失败

因为网络延迟消息消费失败

消费逻辑过于复杂, 导致消费过慢,出现积压问题

解决方案:

对于第一种, 我们常规解决方案, 处理目的容器,保证目的容器是一直可用状态

对于第二种, 如果之前一直没问题, 只是某一天出现, 可以调整消费的超时时间。并且同时解决网络延迟问题

对于第三种, 一般解决方案,调整消费代码, 消费更快即可, 利于消费者的负载均衡策略,提升消费者数量

页面查看:

Kafka配额限速机制

简单来说：Kafka的配额限速机制就像是"交通信号灯"，通过限制生产者和消费者的数据流量，确保集群资源的公平使用和稳定性。
具体而言：
- 配额类型 ：
  - 网络带宽配额：限制客户端每秒可以生产或消费的字节数。
  - 请求率配额：限制客户端对Kafka Broker的CPU利用率。
- 作用域 ：
  - Client ID：针对特定客户端设置配额。
  - User：针对特定用户设置配额。
  - User + Client ID：针对特定用户和客户端组合设置配额。
- 配置方式 ：
  - 动态配置 ：使用kafka-configs.sh脚本动态修改配额配置。
  - 静态配置：在Broker配置文件中设置默认配额（不推荐）。
- 执行机制 ：
  - 延迟响应 ：Broker会计算需要的延迟时间，并在响应中返回ThrottleTime字段。
  - 静默处理：Broker会暂时"静默"客户端的连接，直到延迟结束。
实际生产场景：
- 在生产者限速中，限制某个生产者每秒最多生产1MB数据，防止其占用过多带宽。
- 在消费者限速中，限制某个消费者每秒最多消费2MB数据，避免其对Broker造成过大压力。
- 在多租户隔离中，为不同用户或客户端组设置不同的配额，确保资源公平分配。
总之：Kafka的配额限速机制通过动态配置和优先级规则，提供了灵活且高效的流量控制能力，确保集群的稳定性和公平性。

生产者和消费者以极高的速度生产/消费大量数据或产生请求，从而占用broker上的全部资源，造成网络IO饱和。有了配额（Quotas）就可以避免这些问题。Kafka支持配额管理，从而可以对Producer和Consumer的produce&fetch操作进行流量限制，防止个别业务压爆服务器。

生产者

限流程序设置其TPS不超过1MB/s，即1048576/s 单位是byte
- --producer_byte_rate=1048576 限制生产者写入数据的速度
- --entity-type clients --entity-default 指定对所有生成者都生效

sh 复制代码

/export/server/kafka/bin/kafka-configs.sh --zookeeper node1:2181 --alter --add-config 'producer_byte_rate=1048576' --entity-type clients --entity-default

测试
- --num-records 数据量
- --throughput 吞吐量
- --record-size 数据字节大小 1000kb
- --acks 模式

sh 复制代码

/export/server/kafka/bin/kafka-producer-perf-test.sh --topic benchmark --num-records 5000000 --throughput -1 --record-size 1000 --producer-props bootstrap.servers=node1:9092,node2:9092,node3:9092 acks=1

消费者

限流程序设置其TPS不超过1MB/s，即1048576/s 单位是byte
- --consumer_byte_rate=1048576 限制消费者消费数据的速度
- --entity-type clients --entity-default 指定对所有生成者都生效

sh 复制代码

/export/server/kafka/bin/kafka-configs.sh --zookeeper node1:2181 --alter --add-config 'consumer_byte_rate=1048576' --entity-type clients --entity-default

测试
- --num-records 数据量
- --throughput 吞吐量
- --record-size 数据字节大小 1000kb
- --acks 模式
- --timeout 设置超时停止时间默认是10000ms(10s)

sh 复制代码

/export/server/kafka/bin/kafka-consumer-perf-test.sh --broker-list node1:9092,node2:9092,node3:9092 --topic benchmark1 --fetch-size 1048576 --messages 50000

sh 复制代码

/export/server/kafka/bin/kafka-consumer-perf-test.sh --broker-list node1:9092,node2:9092,node3:9092 --topic benchmark --fetch-size 1048576 --messages 500000

文章目录

kafka高级

今日课程内容

核心概念整理

Kafka的数据位移offset

为什么 Kafka 的 offset 就像是"书签"？

实际意义

Kafka的基准/压力测试

测试生产的效率

测试消费的效率

Kafka的分片与副本机制

kafka如何保证数据不丢失

生产者端

Broker端

消费者端

相关参数

Kafka的数据存储和查询

数据存储

查询机制

生产者的分发策略

为什么 Kafka 生产者的分发策略就像是"邮递员的分拣规则"？

实际意义

分发策略：

指定分区或者key

内置的分区器

消费者的负载均衡

负载均衡机制

消费者组与分区

查看当前消费者组列表

查看消费者组详情信息

场景一：三个分区，一个消费者组里有一个消费者

场景二：三个分区，一个消费者组里有四个消费者

场景三：三个分区，两个消费者组分别有四个消费者

监控工具:kafka-eagle

基本介绍

启动服务:

连接页面:

Kafka中数据积压问题

Kafka配额限速机制

生产者

消费者

为什么 Kafka 的 `offset` 就像是"书签"？