最新【大数据】kafka 线上会遇到哪些问题？_kafka线上问题，2024年最新专题解析

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

kafka是通过HW（High Water Mark） 机制来保证数据的一致性。

（1）follower故障
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。

（2）leader故障
leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。

3.Kafka会在哪些场景出现重复消费，为什么

导致Kafka消息重复消费有以下两个原因：
1.Kafka消息重复提交导致消息重复消费
默认情况下，消息消费完后，会自动提交Offset的值，避免重复消费。Kafka消费端的自动提交，会有一个默认5秒的间隔，在5秒之后的下一次向Broker拉取消息的时候才提交上一批消费的offset。如果在消费过程中，如果遇到应用程序被强制kill掉，就会导致Offset没有及时提交，导致消息重复消费。（消费者宕机造成重复消费）
2.Kafka服务端的Partition在均衡机制导致消息重复消费。
在Kafka服务端的Partition再均衡机制导致消息重复消费，会把多个Partition均衡的分配给多个消费者，消费者会从分配的partition里面去消费消息，如果消费者在默认的5分钟内没有去处理完这批消息的话就会触发kafka的reblance机制。从而导致offset自动提交失败。而Rebalance之后，消费者还会从之前没有提交的offset位置开始消费，从而导致消息重复消费。（1.session超时造成重复消费 2.处理能力弱造成重复消费）
解决重复消费消息的问题有以下方法：

1.提高消费端处理性能避免触发Balance
用多线程的方式处理消息，缩短单个消息消费的时长。
调整消息处理的超时时间
减少一次性从Broker上拉取数据的条数。
2.使用ConsumerRebalanceListener，再均衡监听器
用来设定发生再均衡动作前后的一些准备或者收尾工作。
3.使用消息幂等性
将消息生成的唯一id保存到mysql或者redis中，再处理消息之前先查mysql或者redis，判断是否已经消费过。

4.谈谈Kafka线上大量消息积压你是如何处理的？

如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。 (两者缺一不可)
如果是下游的数据处理不及时: 提高每批次拉取的数量。批次拉取数据过少(拉取数据/处理时间<生产速度) ，使处理的数据小于生产的数据，也会造成数据积压
**消息大量积压这个问题，直接原因一定是某个环节出现了性能问题，来不及消费消息，才会导致消息积压。**接着就比较坑爹了，此时假如 Kafka 集群的磁盘都快写满了，都没有被消费，这个时候怎么办？或者消息积压了⼏个⼩时，这个时候怎么办？生产环境挺常⻅的问题，⼀般不出问题，而⼀出就是⼤事故。

所以，我们先来分析下，在使用 Kafka 时如何来优化代码的性能，避免出现消息积压。如果你的线上 Kafka 系统出现了消息积压，该如何进行紧急处理，最大程度地避免消息积压对业务的影响。

01 优化性能来避免消息积压

对于 Kafka 性能的优化，主要体现在生产者和消费者这两部分业务逻辑中。而 Kafka 本身不需要多关注的主要原因是，对于绝大多数使用Kafka 的业务来说，Kafka 本身的处理能力要远大于业务系统的处理能力。Kafka 单个节点，消息收发的性能可以达到每秒钟处理几十万条消息的水平，还可以通过水平扩展 Broker 的实例数成倍地提升处理能力。

对于业务系统处理的业务逻辑要复杂一些，单个节点每秒钟处理几百到几千次请求，已经非常不错了，所以我们应该更关注的是消息的收发两端。

**1. 发送端性能优化

**
发送端即生产者业务代码都是先执行自己的业务逻辑，最后再发送消息。如果说性能上不去，需要你优先检查一下，是不是发消息之前的业务逻辑耗时太多导致的。

对于发送消息的业务逻辑，只需要注意设置合适的并发和批量大小，就可以达到很好的发送性能。我们知道 Producer 发消息给 Broker 且收到消息并返回 ack 响应，假设这一次过程的平均时延是 1ms，它包括了下面这些步骤的耗时：
1）发送端在发送网络请求之前的耗时。
2）发送消息和返回响应在网络传输中的耗时。
3）Broker 端处理消息的时延。
假设此时你的发送端是单线程，每次只能发送 1 条消息，那么每秒只能发送 1000 条消息，这种情况下并不能发挥出 Kafka 的真实性能。此时无论是增加每次发送消息的批量大小，还是增加并发，都可以成倍地提升发送性能。
如果当前发送端是在线服务的话，比较在意请求响应时延，此时可以采用并发方式来提升性能。
如果当前发送端是离线服务的话，更关注系统的吞吐量，发送数据一般都来自数据库，此时更适合批量读取，批量发送来提升性能。
另外还需要关注下消息体是否过大，如果消息体过大，势必会增加 IO 的耗时，影响 Kafka 生产和消费的速度，也可能会造成消息积压。
**

**2. 消费端性能优化

**
而在使用 Kafka 时，大部分的性能问题都出现在消费端，如果消费的速度跟不上发送端生产消息的速度，就会造成消息积压。如果只是暂时的，那问题不大，只要消费端的性能恢复之后，超过发送端的性能，那积压的消息是可以逐渐被消化掉的。
要是消费速度一直比生产速度慢，时间长了系统就会出现问题，比如Kafka 的磁盘存储被写满无法提供服务，或者消息丢失，对于整个系统来说都是严重故障。
所以我们在设计的时候，一定要保证消费端的消费性能要高于生产端的发送性能，这样的系统才能健康的持续运行。
消费端的性能优化除了优化业务逻辑外，也可以通过水平扩容，增加消费端的并发数来提升总体的消费性能。需要注意的是，在扩容 Consumer 的实例数量的同时，必须同步扩容主题中的分区数量，确保 Consumer 的实例数和分区数量是相等的，如果 Consumer 的实例数量超过分区数量，这样的扩容实际上是没有效果的。

消息积压后如何处理

日常系统正常时候，没有积压或者只有少量积压很快就消费掉了，但某时刻，突然开始积压消息且持续上涨。这种情况下需要你在短时间内找到消息积压的原因，迅速解决问题。

导致消息积压突然增加，只有两种：发送变快了或者消费变慢了。

假如赶上大促或者抢购时，短时间内不太可能优化消费端的代码来提升消费性能，此时唯一的办法是通过扩容消费端的实例数来提升总体的消费能力。如果短时间内没有足够的服务器资源进行扩容，只能降级一些不重要的业务，减少发送方发送的数据量，最低限度让系统还能正常运转，保证重要业务服务正常。
假如通过内部监控到消费变慢了，需要你检查消费实例，分析一下是什么原因导致消费变慢？

1、优先查看日志是否有大量的消费错误。
2、此时如果没有错误的话，可以通过打印堆栈信息，看一下你的消费线程是不是卡在哪里「触发死锁或者卡在某些等待资源」。

5.kafka数据丢失问题,及如何保证？

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新**

需要这份系统化资料的朋友，可以戳这里获取