kafka消息堆积，消息丢失，消息重复
消息积压的解决方法
加强监控报警以及完善重新拉起任务机制
1.实时/消费任务挂掉导致的消费积压的解决方法
在积压数据不多和影响较小的情况下，重新启动消费任务，排查宕机原因。
如果消费任务宕机时间过长导致积压数据量很大，除了重新启动消费任务、排查问题原因，还需要解决消息积压问题。
解决消息积压可以采用下面方法。
任务重新启动后直接消费最新的消息，对于"滞后"的历史数据采用离线程序进行"补漏"。
如下面图所示。创建新的topic并配置更多数量的分区，将积压消息的topic消费者逻辑改为直接把消息打入新的topic，将消费逻辑写在新的topic的消费者中。
1.实时/消费任务挂掉导致的消费积压的解决方法
在积压数据不多和影响较小的情况下，重新启动消费任务，排查宕机原因。
如果消费任务宕机时间过长导致积压数据量很大，除了重新启动消费任务、排查问题原因，还需要解决消息积压问题。
解决消息积压可以采用下面方法。
任务重新启动后直接消费最新的消息，对于"滞后"的历史数据采用离线程序进行"补漏"。
如下面图所示。创建新的topic并配置更多数量的分区，将积压消息的topic消费者逻辑改为直接把消息打入新的topic，将消费逻辑写在新的topic的消费者中。
如果还需要保证消息消费的局部有序，可以将消费者线程池改成多个队列，每个队列用单线程处理，更多内容可以查看博客《一文理解Kafka如何保证消息顺序性》
2.Kafka分区数设置的不合理或消费者"消费能力"不足的优化
Kafka分区数是Kafka并行度调优的最小单元，如果Kafka分区数设置的太少，会影响Kafka Consumer消费的吞吐量。
如果数据量很大，Kafka消费能力不足，则可以考虑增加Topic的Partition的个数，同时提升消费者组的消费者数量。
3.Kafka消息key设置的优化
使用Kafka Producer消息时，可以为消息指定key，但是要求key要均匀，否则会出现Kafka分区间数据不均衡。
所以根据业务，合理修改Producer处的key设置规则，解决数据倾斜问题。
kafka架构
kafka一般包含多个生产者（producer），多个Broker（kafka支持水平扩展，一般Broker越多，吞吐量越高），多个消费者（Consumer），以及一个zookeeper集群，kafka通过zookeeper来管理集群配置，选举机制以及消费者发生变化时进行Rebalance。
生产者使用push模式将消息发布到Broker，消费者使用pull模式从Broker订阅消息。
push模式很难适应消费速率不同的消费者，如果push的速度太快，容易造成消费者拒绝服务或网络拥塞；如果push的速度太慢，容易造成消费者性能浪费。但是采用pull的方式也有一个缺点，就是当Broker没有消息时，消费者会陷入不断地轮询中，为了避免这点，kafka有个参数可以让消费者阻塞知道是否有新消息到达。
2.kafka与传统消息系统之间的三大关键区别
（1）kafka持久化日志，这些日志可以被重复读取和无限期保留
（2）分布式系统：可灵活伸缩，在内部通过复制数据提高容错能力和高可用性
（3）支持实时流式处理（不明白）
3.kafka的消费者如何消费数据
消费者每次消费数据时，消费者都会记录消费的物理偏移量（offset），等下次消费时，会接着上次位置继续消费。
场景描述：Kafka使用分区将topic的消息打散到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。Kafka的producer和consumer都可以多线程地并行操作，而每个线程处理的是一个分区的数据。因此分区实际上是调优Kafka并行度的最小单元。对于producer而言，它实际上是用多个线程并发地向不同分区所在的broker发起Socket连接同时给这些分区发送消息；而consumer，同一个消费组内的所有consumer线程都被指定topic的某一个分区进行消费。
所以说，如果一个topic分区越多，理论上整个集群所能达到的吞吐量就越大。
分区多的优点
kafka使用分区将topic的消息打散到多个分区分布保存在不同的broker上，实现了producer和consumer消息处理的高吞吐量。Kafka的producer和consumer都可以多线程地并行操作，而每个线程处理的是一个分区的数据。因此分区实际上是调优Kafka并行度的最小单元。对于producer而言，它实际上是用多个线程并发地向不同分区所在的broker发起Socket连接同时给这些分区发送消息；而consumer，同一个消费组内的所有consumer线程都被指定topic的某一个分区进行消费。
所以说，如果一个topic分区越多，理论上整个集群所能达到的吞吐量就越大。
分区不是越多越好
分区是否越多越好呢？显然也不是，因为每个分区都有自己的开销：
一、客户端/服务器端需要使用的内存就越多
二、文件句柄的开销
三、降低高可用性
Kafka通过副本(replica)机制来保证高可用。具体做法就是为每个分区保存若干个副本(replica_factor指定副本数)。每个副本保存在不同的broker上。其中的一个副本充当leader 副本，负责处理producer和consumer请求。其他副本充当follower角色，由Kafka controller负责保证与leader的同步。如果leader所在的broker挂掉了，contorller会检测到然后在zookeeper的帮助下重选出新的leader——这中间会有短暂的不可用时间窗口，虽然大部分情况下可能只是几毫秒级别。**但如果你有10000个分区，10个broker，也就是说平均每个broker上有1000个分区。此时这个broker挂掉了，那么zookeeper和controller需要立即对这1000个分区进行leader选举。比起很少的分区leader选举而言，这必然要花更长的时间，**并且通常不是线性累加的。如果这个broker还同时是controller情况就更糟了。
根据业务特点确定partition数量
怎么理解呢？我们都知道一个topic肯定是跟某个业务强相关，比如电商业务中的用户登录数据，会用一个专门的topic，而购买数据而会用另外一个topic。
以用户登录数据为例，定多少个partition，可以根据你后续要如何对这个数据进行处理来定。
我们知道partition之间的数据是没有办法保证有序，且没有业务逻辑关系的，默认情况下，当用客户端向某个topic灌数据时，如果没有指定消息的key和要写入的partition，那么数据会以round-robin的方式均匀写到topic的每个partition中。
解决Kafka消息堆积的方法有以下几种：
-
增加消费者数量：通过增加消费者的数量，可以提高消息处理的速度，从而减少堆积。
-
增加分区数量：可以通过增加Kafka主题的分区数量来提高并行处理能力，从而分散消息堆积的情况。
-
调整消费者的消费速率：可以通过调整消费者的消费速率来与生产者的消息产生速率保持一致，避免堆积的发生。
-
提高消费者的处理能力：优化消费者的处理逻辑，提高消费者的处理能力，以便更快地处理消息，从而减少堆积。
-
增加Kafka集群的容量：如果消息堆积是因为Kafka集群的容量不足导致的，可以考虑增加集群的容量，以提供更大的存储和处理能力。
-
监控和报警：通过设置监控和报警系统，可以及时发现消息堆积的情况，并采取相应的措施进行处理。
以上是一些常见的解决方法，具体的解决方案需要根据实际情况进行调整和优化。
扫一扫
7749
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
