Kafka 分区分配及再平衡策略深度解析与消费者事务和数据积压的简单介绍

[二、Range 分区分配策略](#二、Range 分区分配策略)

（一）原理

（二）案例

[（三）Range 分区分配再平衡案例](#（三）Range 分区分配再平衡案例)

[三、RoundRobin 分区分配策略](#三、RoundRobin 分区分配策略)

（一）原理

（二）案例

[（三）RoundRobin 分区分配再平衡案例](#（三）RoundRobin 分区分配再平衡案例)

[四、Sticky 分区分配策略](#四、Sticky 分区分配策略)

（一）原理

（二）案例

[（三）Sticky 分区分配再平衡案例](#（三）Sticky 分区分配再平衡案例)

[五、CooperativeSticky 分区分配策略](#五、CooperativeSticky 分区分配策略)

六、消费者事务

七、数据积压（消费者如何提高吞吐量）

八、总结

在 Kafka 的消费任务处理中，分区的分配以及再平衡是至关重要的环节。合理的分区分配策略能够确保消费者高效地处理消息，而理解再平衡机制则有助于应对消费者组在运行过程中的动态变化。本文将深入探讨 Kafka 中不同的分区分配策略，包括 Range、RoundRobin、Sticky 和 CooperativeSticky，以及它们在各种场景下的再平衡表现，并结合实际案例进行详细分析，并对消费者事务和数据积压进行简单介绍。

一、分区分配策略基础

在一个 Kafka 消费者组中，包含多个消费者，而一个主题则由多个分区组成。关键问题在于确定哪个消费者来消费哪个分区的数据。Kafka 提供了四种主流的分区分配策略，并且可以通过配置参数 partition.assignment.strategy 来修改分区的分配策略，默认策略是 Range + CooperativeSticky。同时，还有一些相关的重要参数：

|-------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------|
| 参数名称 | 描述 |
| heartbeat.interval.ms | Kafka 消费者和 coordinator 之间的心跳时间，默认 3s。该条目的值必须小于session.timeout.ms，也不应该高于 session.timeout.ms 的 1/3。 |
| session.timeout.ms | Kafka 消费者和 coordinator 之间连接超时时间，默认 45s。超过该值，该消费者被移除，消费者组执行再平衡。 |
| max.poll.interval.ms | 消费者处理消息的最大时长，默认是 5 分钟。超过该值，该消费者被移除，消费者组执行再平衡 |
| partition.assignment.strategy | 消费者分区分配策略，默认策略是 Range +CooperativeSticky。Kafka 可以同时使用多个分区分配策略。可以选择的策略包括： Range 、 RoundRobin 、 Sticky 、CooperativeSticky |

二、Range 分区分配策略

（一）原理

Range 分区分配策略是基于主题的分区数量和消费者数量进行分配。它会按照顺序将连续的分区分配给每个消费者，尽可能平均地分配分区，但可能会导致不同消费者分配到的分区数量不一致。

（二）案例

首先，将主题 first 修改为 7 个分区：

bash 复制代码

bin/kafka-topics.sh --bootstrap-server bigdata01:9092 --alter --topic first --partitions 7

注意，分区数可增加但不能减少，主题的副本数修改需要制定计划执行，不能直接修改。

由三个消费者 CustomConsumer、CustomConsumer1、CustomConsumer2 组成消费者组，组名都为 "test"，同时启动这 3 个消费者。

启动 CustomProducer 生产者，发送 500 条消息，随机发送到不同的分区（修改发送次数为 500 次）。

java 复制代码

package com.bigdata.kafka.producer;

import org.apache.kafka.clients.producer.*;
import org.apache.kafka.common.serialization.StringSerializer;

import java.util.Properties;

public class CustomProducerCallback {
    public static void main(String[] args) throws InterruptedException {
        // 1. 创建 kafka 生产者的配置对象
        Properties properties = new Properties();
        // 2. 给 kafka 配置对象添加配置信息
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,
                "192.168.235.128:9092");
        // key,value 序列化（必须）：key.serializer，value.serializer
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG,
                StringSerializer.class.getName());

        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,
                StringSerializer.class.getName());
        // 3. 创建 kafka 生产者对象
        KafkaProducer<String, String> kafkaProducer = new
                KafkaProducer<String, String>(properties);
        // 4. 调用 send 方法,发送消息
        for (int i = 0; i < 500; i++) {
            // 添加回调
            kafkaProducer.send(new ProducerRecord<>("first",
                    "bigdata " + i), new Callback() {
                // 该方法在 Producer 收到 ack 时调用，为异步调用
                @Override
                public void onCompletion(RecordMetadata metadata,
                                         Exception exception) {
                    if (exception == null) {
                        // 没有异常,输出信息到控制台
                        System.out.println(" 主题： " +
                                metadata.topic() + "->" + "分区：" + metadata.partition());
                    } else {
                        // 出现异常打印
                        exception.printStackTrace();
                    }
                }
            });
            // 延迟一会会看到数据发往不同分区
            Thread.sleep(20);
        }
        // 5. 关闭资源
        kafkaProducer.close();
    }
}

说明：Kafka 默认的分区分配策略就是 Range + CooperativeSticky，所以不需要修改策略。

默认是Range,但是在经过一次升级之后，会自动变为CooperativeSticky。这个是官方给出的解释。

默认的分配器是[RangeAssignor, CooperativeStickyAssignor]，默认情况下将使用RangeAssignor，但允许通过一次滚动反弹升级到CooperativeStickyAssignor，该滚动反弹会将RangeAssignor从列表中删除。

观察消费情况，发现一个消费者消费了 5，6 分区，一个消费了 0,1,2 分区，一个消费了 3，4 分区。这是按照 Range 策略分配的结果。

此时并没有修改分区策略，原因是默认是Range.

（三）Range 分区分配再平衡案例

停止掉 0 号消费者，快速重新发送消息（45s 以内），此时 1 号消费者消费到 3、4 号分区数据，2 号消费者消费到 5、6 号分区数据，0 号的数据无人消费。

说明：0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。

再次重新发送消息（45s 以后），1 号消费者消费到 0、1、2、3 号分区数据，2 号消费者消费到 4、5、6 号分区数据。

说明：消费者 0 已经被踢出消费者组，所以重新按照 range 方式分配。

三、RoundRobin 分区分配策略

（一）原理

RoundRobin 分区分配策略以轮询的方式将分区分配给消费者，确保每个消费者尽可能均衡地获取分区，不考虑主题的因素，只要是消费者组内的分区都会按照轮询顺序分配。

（二）案例

在 CustomConsumer、CustomConsumer1、CustomConsumer2 三个消费者代码中修改分区分配策略为 RoundRobin（指定 org.apache.kafka.clients.consumer.RoundRobinAssignor），并修改消费者组为 test2。

java 复制代码

package com.bigdata.kafka.consumer;

import org.apache.kafka.clients.consumer.ConsumerConfig;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaConsumer;
import org.apache.kafka.common.serialization.StringDeserializer;

import java.time.Duration;
import java.util.ArrayList;
import java.util.Properties;

public class CustomConsumerWithFenPei {

    public static void main(String[] args) {

        Properties properties = new Properties();
        // 连接kafka
        properties.setProperty(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop11:9092");
        // 字段反序列化   key 和  value
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG,
                StringDeserializer.class.getName());

        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG,
                StringDeserializer.class.getName());

        // 配置消费者组（组名任意起名） 必须
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "test2");

        // 指定分区的分配方案
        properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, "org.apache.kafka.clients.consumer.RoundRobinAssignor");

        KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<String, String>(properties);
        // 消费者订阅主题，主题有数据就会拉取数据
        // 指定消费的主题
        ArrayList<String> topics = new ArrayList<>();
        topics.add("first");
        // 一个消费者可以订阅多个主题
        kafkaConsumer.subscribe(topics);
        while(true){
            //1 秒中向kafka拉取一批数据
            ConsumerRecords<String, String> records = kafkaConsumer.poll(Duration.ofSeconds(1));
            for (ConsumerRecord<String,String> record :records) {
                // 打印一条数据
                System.out.println(record);
                // 可以打印记录中的很多内容，比如 key  value  offset topic 等信息
                System.out.println(record.value());
            }

        }

    }
}

修改一下消费者组为test2

重启 3 个消费者，重复发送消息步骤并观察分区结果。

（三）RoundRobin 分区分配再平衡案例

停止掉 0 号消费者，快速重新发送消息（45s 以内），1 号消费者消费到 2、5 号分区数据，2 号消费者消费到 4、1 号分区数据，0 号消费者以前对应的数据无人消费。

说明：0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。

再次重新发送消息（45s 以后），1 号消费者消费到 0、2、4、6 号分区数据，2 号消费者消费到 1、3、5 号分区数据。

说明：消费者 0 已经被踢出消费者组，所以重新按照 RoundRobin 方式分配。

四、Sticky 分区分配策略

（一）原理

粘性分区定义： 可以理解为分配的结果带有"粘性的"。即在执行一次新的分配之前，考虑上一次分配的结果，尽量少的调整分配的变动，可以节省大量的开销。粘性分区是 Kafka 从 0.11.x 版本开始引入这种分配策略，首先会尽量均衡的放置分区到消费者上面，在出现同一消费者组内消费者出现问题的时候，会尽量保持原有分配的分区不变化。

（二）案例

1）需求

设置主题为 first，7 个分区；准备 3 个消费者，采用粘性分区策略，并进行消费，观察

消费分配情况。然后再停止其中一个消费者，再次观察消费分配情况。

2）步骤

（1）修改分区分配策略为粘性。

注意：3 个消费者都应该注释掉，之后重启 3 个消费者，如果出现报错，全部停止等

会再重启，或者修改为全新的消费者组。

bash 复制代码

// 修改分区分配策略
ArrayList<String> startegys = new ArrayList<>();
startegys.add("org.apache.kafka.clients.consumer.StickyAssignor");
properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, startegys);

（3）使用同样的生产者发送 500 条消息。

可以看到会尽量保持分区的个数近似划分分区。

（三）Sticky 分区分配再平衡案例

停止掉 0 号消费者，快速重新发送消息（45s 以内），1 号消费者消费到 2、5、3 号分区数据，2 号消费者消费到 4、6 号分区数据，0 号消费者的任务无人顶替。

说明：0 号消费者挂掉后，消费者组需要按照超时时间 45s 来判断它是否退出，所以需

要等待，时间到了 45s 后，判断它真的退出就会把任务分配给其他 broker 执行。

再次重新发送消息（45s 以后），1 号消费者消费到 2、3、5 号分区数据，2 号消费者消费到 0、1、4、6 号分区数据。

说明：消费者 0 已经被踢出消费者组，所以重新按照粘性方式分配。

五、CooperativeSticky 分区分配策略

CooperativeSticky 是新添加的策略。在消费过程中，会根据消费的偏移量情况进行重新再平衡，也就是粘性分区，并且在运行过程中还会根据消费的实际情况重新分配消费者，直到平衡为止。其好处是实现负载均衡，但多次平衡会浪费性能，它采用动态平衡，在消费过程中实施再平衡，而不是等到某个消费者退出再平衡。

六、消费者事务

若要实现 Kafka 消费端的精准一次性消费，需要将消费过程和提交 offset 过程做原子绑定。此时可将 Kafka 的 offset 保存到支持事务的自定义介质（如 MySQL），这部分知识将在后续项目中深入涉及，事务具有 ACID 四大特征，例如转账场景（张三 --> 李四）就需要事务的保障来确保数据的准确性和完整性。

七、数据积压（消费者如何提高吞吐量）

当面临数据积压问题时，消费者可以采取多种方式提高吞吐量，例如增加消费者数量、优化消费者代码处理逻辑、调整相关参数（如 max.poll.interval.ms 等）以适应更高的处理负载等。后续将深入探讨数据积压场景下的优化策略。

八、总结

通过对 Kafka 分区分配以及再平衡策略的深入理解和实践，可以更好地构建和优化 Kafka 消费任务处理流程，确保系统的高效稳定运行。在实际应用中，需要根据具体的业务需求和场景特点选择合适的分区分配策略，并合理处理再平衡过程中的各种情况。

消费者事务方面，为实现精准一次性消费，需将消费与提交 offset 原子绑定，可将 offset 存于支持事务的自定义介质如 MySQL 中。在数据积压场景下，消费者可通过增加数量、优化代码处理逻辑、调整参数等方式提高吞吐量，后续会深入探讨相关优化策略。这些知识对于深入理解和优化 Kafka 消费者的性能、可靠性和数据处理准确性具有极为重要的意义，有助于在实际应用中更好地构建和管理基于 Kafka 的系统架构