目录
5、kafka注意事项
Kafka消费积压(Consumer Lag)是指消费者处理消息的速度****跟不上生产者发送消息的速度，导致消息在Kafka主题中堆积。
关于kakfa的架构图，如下所示：
更多关于kafka的介绍，参考：关于MQ之kafka的深入研究-CSDN博客
https://blog.csdn.net/weixin_50055999/article/details/148535599?spm=1011.2415.3001.5331
1、kafka消费的流程
之前的章节中，介绍了kafka消息由producer通过hash函数存放到broker节点后，每个broker节点由多个topic主题组成，可水平扩展。
每个topic由多个partitin组成，partition里面的内容有顺序，跨partition无序。
对于点对点模式下：
消费组内每个消费者可以消费多个partition、同时保留offset偏移位置，保证下次消费。
对于发布订阅模式：
不同消费组内的消费者可以消费同一个patition，两个消费组不受影响，各自保留彼此的offset的偏移位置。
如图所示：
在消费者消费过程的流程如下：
由上图可知：
1、每个topic里面包含多个partition。
2、每个partition里面的内容是按顺序分布的。
3、每个消费者可以消费多个partition。
4、而partition只能被一个消费者消费。
对于不同消费者组，可以共同消费同一个topic里面的消息。
2、kafka的消费模式
Kafka 的消费订阅模式取决于消费者组的配置方式，可以分为以下两种主要模式：
2.1、点对点模式
特点：一条消息只能被一个消费者消费
实现方式：
-
所有消费者属于同一个消费者组 （相同的
group.id） -
Kafka 会在组内消费者之间自动平衡分区分配
java
// 消费者1和消费者2使用相同的group.id
Properties props = new Properties();
props.put("bootstrap.servers", "kafka:9092");
props.put("group.id", "my-consumer-group"); // 相同的组ID
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
consumer.subscribe(Arrays.asList("test-topic"));工作流程：
-
假设主题有3个分区（P0, P1, P2）
-
如果有1个消费者，它将消费所有3个分区
-
如果增加第二个消费者，Kafka会重新平衡：
-
消费者1可能获得P0和P1
-
消费者2获得P2
-
-
消息在每个分区内有序，且只被分配给该分区的消费者消费
2.2、发布-订阅模式
特点 ：一条消息可以被多个消费者（不同消费组）消费（本质还是点对点）
实现方式：
-
不同消费者组订阅同一个主题
-
每个消费者组都会收到完整的消息流
java
// 组A的消费者
Properties propsA = new Properties();
propsA.put("group.id", "group-a"); // 不同组ID
// ...其他配置
KafkaConsumer<String, String> consumerA = new KafkaConsumer<>(propsA);
// 组B的消费者
Properties propsB = new Properties();
propsB.put("group.id", "group-b"); // 不同组ID
// ...其他配置
KafkaConsumer<String, String> consumerB = new KafkaConsumer<>(propsB);工作流程：
-
生产者发送消息到主题
-
组A的所有消费者（作为一个组）会收到消息的一个副本
-
组B的所有消费者（作为另一个独立的组）也会收到消息的一个副本
-
在每个组内部，消息仍然遵循点对点模式（组内只有一个消费者收到）
3、consumer消息积压
Kafka消息积压的问题，核心原因是生产太快、消费太慢，处理速度长期失衡，从而导致消息积压（Lag）的场景，积压到超过队列长度限制，就会出现还未被消费的数据产生丢失的场景。
如果长时间不解决消息积压，可能会引发资源紧张、服务延迟或崩溃等问题。解决消息积压的关键是提高消费者的消费能力，并优化Kafka集群的整体处理效率。
3.1、处理方案
-
如果是Kafka消费能力不足，则可以考虑增加 topic 的 partition 的个数（提高kafka的并行度），同时提升消费者组的消费者数量，消费数 = 分区数 （二者缺一不可）
-
若是下游数据处理不及时，则提高每批次拉取的数量。批次拉取数量过少（拉取数据/处理时间 < 生产速度），使处理的数据小于生产的数据，也会造成数据积压。
方法：
-
增大partion数量。
-
消费者加了并发，服务， 扩大消费线程。
-
增加消费组服务数量。
-
kafka单机升级成了集群。
-
避免消费者消费消息时间过长，导致超时。
-
使Kafka分区之间的数据均匀分布。
3.2、积压量
- 生产量：Kafka Topic 在一个时间周期内各partition offset 起止时间差值之和。
- 消费量：Kafka Topic 在一个时间周期内某个消费者的消费量。
- 积压量：Kafka Topic 的某个Consumer Group残留在消息中间件未被及时消费的消息量。
4、消息过期失效
产生消息堆积，消费不及时，kafka数据有过期时间，一些数据就丢失了，主要是消费不及时。
当出现这种现象的时候，可参考以下经验，进行规避：
- 消费kafka消息时，应该尽量减少每次消费时间，可通过减少调用三方接口、读库等操作，
从而减少消息堆积的可能性。
-
如果消息来不及消费，可以先存在数据库中，然后逐条消费（可以保存消费记录，方便定位问题）。
-
每次接受kafka消息时，先打印出日志，包括消息产生的时间戳。
-
kafka消息保留时间（修改kafka配置文件， 默认一周）
-
任务启动从上次提交offset处开始消费处理
5、kafka注意事项
-
由于Kafka消息key设置,在Kafka producer处，给key加随机后缀，使其均衡。
-
数据量很大，合理的增加Kafka分区数是关键。
Kafka分区数是Kafka并行度调优的最小单元，如果Kafka分区数设置的太少，
会影响Kafka consumer消费的吞吐量. 如果利用的是Spark流和Kafka direct approach方式，
也可以对KafkaRDD进行repartition重分区，增加并行度处理.
参考文章：