0


kafka的消息数据积压处理方案详解(两个方向)

(1)直接介绍一下处理方案。

1.首先,我们需要判断到底是kafka消费能力不足的问题还是下游数据处理不及时的问题。

2.如果是kafka消费能力不足的问题,则可以考虑增加Topic的分区数,并且同时提升消费组的消费者数量,消费者数=分区数。(两者缺一不可)

    分区数大于消费者消费数量时,一个消费者消费几个分区,消费速度会变慢。但分数区小于消费者组消费数量时,会造成部分消费者没有消费,浪费资源。所以最优解就是消费者数量等于分区数。

3.如果是下游的数据处理不及时:提高每批次拉取的数量。每批次拉取的数据过少(拉取的数据/处理时间<生产速度),使处理的数据小于生产的数据,也会造成数据积压。

(2)介绍一下出现问题的原因。

1.kafka的结构如下:

*(1***)Producer **消息生产者,就是向kafka broker发消息的客户端;

*(2***)Consumer **消息消费者,向kafka broker取消息的客户端;

*(3***)Consumer Group (CG):**消费者组,由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据,一个分区只能由一个消费者消费;消费者组之间互不影响。所有的消费者都属于某个消费者组,即消费者组是逻辑上的一个订阅者。

*(4***)Broker **一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。

*(5***)Topic **可以理解为一个队列,生产者和消费者面向的都是一个topic;

(6)Partition为了实现扩展性,一个非常大的topic可以分布到多个broker(即服务器)上,一个topic可以分为多个partition,每个partition是一个有序的队列;

(7)Replica副本,为保证集群中的某个节点发生故障时,该节点上的partition数据不丢失,且kafka仍然能够继续工作,kafka提供了副本机制,一个topic的每个分区都有若干个副本,一个leader和若干个follower

(8)leader每个分区多个副本的“主”,生产者发送数据的对象,以及消费者消费数据的对象都是leader。

(9)follower每个分区多个副本中的“从”,实时从leader中同步数据,保持和leader数据的同步。leader发生故障时,某个follower会成为新的leader。

2.kafka消费能力不足的问题,要在kafka集群里面增加分区数。

3.如果是下游的数据处理不及时,这考虑增加拉取数,在kafka集群到消费者组部分。


本文转载自: https://blog.csdn.net/ruiqu1650914788/article/details/127619233
版权归原作者 枫锦旧曾谙 所有, 如有侵权,请联系我们删除。

“kafka的消息数据积压处理方案详解(两个方向)”的评论:

还没有评论