全网最详细地理解Kafka中的Topic和Partition以及关于kafka的消息分发、服务端如何消费指定分区、kafka的分区分配策略(range策略和RoundRobin策略)

已于 2023-02-10 21:01:34 修改
阅读量2.6k 收藏 14
点赞数 3
分类专栏： 免费专栏 文章标签： kafka java 分布式 后端 运维开发
于 2023-02-10 20:06:11 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lvoelife/article/details/128969510
版权

文章目录

1. 文章引言

最近在学习kafka相关的知识，特将学习成功记录成文章，以供大家共同学习。

首先要注意的是，Kafka中的Topic和ActiveMQ中的Topic是不一样的。

在Kafka中，Topic是一个存储消息的逻辑概念，可以认为是一个消息集合。每条消息发送到Kafka集群的消息都有一个类别。

物理上来说，不同的Topic的消息是分开存储的，每个Topic可以有多个生产者向它发送消息，也可以有多个消费者去消费其中的消息。

在这里插入图片描述

每个Topic可以划分多个分区**（每个Topic至少有一个分区）**，同一Topic 下的不同分区包含的消息是不同的。

每个消息在被添加到分区时，都会被分配一个offset，它是消息在此分区中的唯一编号，Kafka通过offset保证消息在分区内的顺序。

offset的顺序不跨分区，即Kafka只保证在同一个分区内的消息是有序的。

消息是每次追加到对应的Partition的后面：

在这里插入图片描述

2. Topic & Partition的存储

Topic是一个逻辑上的概念，具体的存储还是基于Partition来的。

创建一个test2 Topic（注意这里的 partitions 参数为 3）：

在这里插入图片描述

可以进入/tmp/kafka-logs目录下进行查看（当前机器IP 192.168.220.135），如下图所示：

在这里插入图片描述

在另外一台136机器上：

在这里插入图片描述

可以发现：

  1. 在135机器上有test2-0和test2-2

  2. 在136机器上有test2-1。

接下来，再结合Kafka的消息分发策略来看。

3. Kafka的消息分发

Kafka中最基本的数据单元就是消息，而一条消息其实是由Key + Value组成：

  1. Key是可选项，可传空值

  2. Value也可以传空值

这也是与ActiveMQ不同的一个地方。

在发送一条消息时，我们可以指定这 Key，那 Producer会根据Key和partition机制来判断当前这条消息应该发送并存储到哪个partition 中（这个就跟分片机制类似）。

我们可以根据需要进行扩展Producer的partition机制 （默认算法是hash取%）。

如下扩展自己的partition代码所示：

 
/**
 * 消息发送后会调用自定义的策略
 *
 * @author super先生
 * @date 2023/2/10 14:20
 */
public class MyPartitioner implements Partitioner {
 
    @Override
    public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
        //获取当前 topic 有多少个分区（分区列表）
        List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
        int partitionNum = 0;
        if (key == null) { //之前介绍过 Key 是可以传空值的
            partitionNum = new Random().nextInt(partitions.size());   //随机
        } else {
            //取 %
            partitionNum = Math.abs((key.hashCode()) % partitions.size());
        }
        System.out.println("key：" + key + "，value：" + value + "，partitionNum：" + partitionNum);
        //发送到指定分区
        return partitionNum;
    }
 
    @Override
    public void close() {}
 
    @Override
    public void configure(Map<String, ?> configs) {}
}

生产者和消费者代码可参考我的博文：实现kafka的生产者(Producer)和消费者(Consumer)的代码

如下创建kafka生产者(Producer)的代码：

/**
 * @author super先生
 * @date 2023/2/10 14:40
 */
public class KafkaProducerDemo extends Thread {
    /**
     * 消息发送者
     */
    private final KafkaProducer<Integer, String> producer;
 
    /**
     * topic
     */
    private final String topic;
 
    private final Boolean isAsync;
 
    public KafkaProducerDemo(String topic, Boolean isAsync) {
        this.isAsync = isAsync;
        //构建相关属性
        //@see ProducerConfig
        Properties properties = new Properties();
        //Kafka 地址
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.220.135:9092,192.168.220.136:9092");
        //kafka 客户端 Demo
        properties.put(ProducerConfig.CLIENT_ID_CONFIG, "KafkaProducerDemo");
        //The number of acknowledgments the producer requires the leader to have received before considering a request complete. This controls the durability of records that are sent.
        /**发送端消息确认模式：
         *  0：消息发送给broker后，不需要确认（性能较高，但是会出现数据丢失，而且风险最大，因为当 server 宕机时，数据将会丢失）
         *  1：只需要获得集群中的 leader节点的确认即可返回
         *  -1/all:需要 ISR 中的所有的 Replica进行确认（集群中的所有节点确认），最安全的，也有可能出现数据丢失（因为 ISR 可能会缩小到仅包含一个 Replica）
         */
        properties.put(ProducerConfig.ACKS_CONFIG, "-1");
 
        /**【调优】
         * batch.size 参数（默认 16kb）
         *  public static final String BATCH_SIZE_CONFIG = "batch.size";
         *
         *  producer对于同一个 分区 来说，会按照 batch.size 的大小进行统一收集进行批量发送，相当于消息并不会立即发送，而是会收集整理大小至 16kb.若将该值设为0，则不会进行批处理
         */
 
        /**【调优】
         * linger.ms 参数
         *  public static final String LINGER_MS_CONFIG = "linger.ms";
         *  一个毫秒值。Kafka 默认会把两次请求的时间间隔之内的消息进行搜集。相当于会有一个 delay 操作。比如定义的是1000（1s），消息一秒钟发送5条，那么这 5条消息不会立马发送，而是会有一个 delay操作进行聚合，
         *  delay以后再次批量发送到 broker。默认是 0，就是不延迟（同 TCP Nagle算法），那么 batch.size 也就不生效了
         */
        //linger.ms 参数和batch.size 参数只要满足其中一个都会发送
 
        /**【调优】
         * max.request.size 参数（默认是1M）   设置请求最大字节数
         * public static final String MAX_REQUEST_SIZE_CONFIG = "max.request.size";
         * 如果设置的过大，发送的性能会受到影响，同时写入接收的性能也会受到影响。
         */
 
        //设置 key的序列化，key 是 Integer类型，使用 IntegerSerializer
        //org.apache.kafka.common.serialization
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.IntegerSerializer");
        //设置 value 的序列化
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
 
        //指定分区策略
        properties.put(ProducerConfig.PARTITIONER_CLASS_CONFIG,"superJson.kafka.partition.MyPartitioner");
 
        //构建 kafka Producer，这里 key 是 Integer 类型，Value 是 String 类型
        producer = new KafkaProducer<Integer, String>(properties);
        this.topic = topic;
    }
 
    public static void main(String[] args) {
        new KafkaProducerDemo("test2",true).start();
    }
 
    @Override
    public void run() {
        int num = 0;
        while (num < 100) {
            String message = "message--->" + num;
            System.out.println("start to send message 【 " + message + " 】");
            if (isAsync) {  //如果是异步发送
                producer.send(new ProducerRecord<Integer, String>(topic, message), new Callback() {
                    @Override
                    public void onCompletion(RecordMetadata metadata, Exception exception) {
                        if (metadata!=null){
                            System.out.println("async-offset："+metadata.offset()+"-> partition"+metadata.partition());
                        }
                    }
                });
            } else {   //同步发送
                try {
                    RecordMetadata metadata = producer.send(new ProducerRecord<Integer, String>(topic, message)).get();
                    System.out.println("sync-offset："+metadata.offset()+"-> partition"+metadata.partition());
                } catch (InterruptedException | ExecutionException e) {
                    e.printStackTrace();
                }
            }
            num++;
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

实现kafka的消费者(Consumer)中在接收消息的时候输出分区，如下代码所示：

在这里插入图片描述

 
/**
 * @author super先生
 * @date 2023/2/10 15:10
 */
public class KafkaConsumerDemo extends Thread {
 
    private final KafkaConsumer<Integer, String> kafkaConsumer;
 
    public KafkaConsumerDemo(String topic) {
        //构建相关属性
        //@see ConsumerConfig
        Properties properties = new Properties();
        properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.220.135:9092,192.168.220.136:9092");
        //消费组
        /**
         * consumer group是kafka提供的可扩展且具有容错性的消费者机制。既然是
         一个组，那么组内必然可以有多个消费者或消费者实例((consumer instance),
         它们共享一个公共的ID，即group ID。组内的所有消费者协调在一起来消费订
         阅主题(subscribed topics)的所有分区(partition)。当然，每个分区只能由同一
         个消费组内的一个consumer来消费.后面会进一步介绍。
         */
        properties.put(ConsumerConfig.GROUP_ID_CONFIG, "KafkaConsumerDemo");
 
        /** auto.offset.reset 参数  从什么时候开始消费
         *  public static final String AUTO_OFFSET_RESET_CONFIG = "auto.offset.reset";
         *
         *  这个参数是针对新的groupid中的消费者而言的，当有新groupid的消费者来消费指定的topic时，对于该参数的配置，会有不同的语义
         *  auto.offset.reset=latest情况下，新的消费者将会从其他消费者最后消费的offset处开始消费topic下的消息
         *  auto.offset.reset= earliest情况下，新的消费者会从该topic最早的消息开始消费
            auto.offset.reset=none情况下，新的消费组加入以后，由于之前不存在 offset，则会直接抛出异常。说白了，新的消费组不要设置这个值
         */
 
        //enable.auto.commit
        //消费者消费消息以后自动提交，只有当消息提交以后，该消息才不会被再次接收到（如果没有 commit，消息可以重复消费，也没有 offset），还可以配合auto.commit.interval.ms控制自动提交的频率。
        //当然，我们也可以通过consumer.commitSync()的方式实现手动提交
        properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
 
        /**max.poll.records
         *此参数设置限制每次调用poll返回的消息数，这样可以更容易的预测每次poll间隔
         要处理的最大值。通过调整此值，可以减少poll间隔
         */
 
        //间隔时间
        properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");
        //反序列化 key
        properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.IntegerDeserializer");
        //反序列化 value
        properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer");
        //构建 KafkaConsumer
        kafkaConsumer = new KafkaConsumer<>(properties);
        //设置 topic
        kafkaConsumer.subscribe(Collections.singletonList(topic));
    }
 
 
    /**
     * 接收消息
      */
    @Override
    public void run() {
        while (true) {
            //拉取消息
            ConsumerRecords<Integer, String> consumerRecord = kafkaConsumer.poll(100000000);
            for (ConsumerRecord<Integer, String> record : consumerRecord) {
                //record.partition() 获取当前分区
                System.out.println(record.partition()+"】】  message receive 【" + record.value() + "】");
            }
        }
    }
 
    public static void main(String[] args) {
        new KafkaConsumerDemo("test2").start();
    }
 
}

首先启动Consumer，再启动Producer：

在这里插入图片描述

可以看到是能够对的上的。

默认情况下，Kafka采用的是hash 取 % 的分区算法。

如果Key为null，则会随机分配一个分区。

这个随机是在这个参数metadata.max.age.ms的时间范围内随机选择一个。

对于这个时间段内，如果Key为 null，则只会发送到唯一的分区。这个值默认情况下是 10 分钟更新一次 （因为 partition 状态可能会发生变化）。

4. 关于 Metadata

Metadata包含 Topic 和 Partition 和 broker 的映射关系，每一个 Topic 的每一个 partition，需要知道对应的 broker 列表是什么，Leader 是谁，Follower 是谁。

这些信息都是存储在Metadata这个类中，如下图所示：

在这里插入图片描述

5. 消费端如何消费指定分区

Consumer可以指定具体消费的分区，如下图所示：

在这里插入图片描述

再重新启动Consumer和Producer：

在这里插入图片描述

可以看到Consumer只消费了分区为1的消息。

以上是单个Consumer消费（指定）分区的情况。

一般每个Topic都会有多个partition（主要是用于数据分片，减少消息的容量，从而提升 I/O 性能）。

当然也可以使用多个Consumer从而提高消费能力，有一个消费组的概念（具体可参看：一文了解kafka消息队列）

如果Consumer1、Consumer2 和 Consumer3 都属于group.id 为1 的消费组，那么消费情况如下：

  1. Consumer1就会消费 p0

  2. Consumer2就会消费p1

  3. Consumer3就会消费p2

在这里插入图片描述

不使用指定分区的方式创建三个Consumer：

在这里插入图片描述

而且，它们都是同一个消费组：

在这里插入图片描述

在这里插入图片描述
同时启动三个Consumer和Producer，而且它们都是同一个消费组：

在这里插入图片描述

在这里插入图片描述

可以看到三个Consumer分别消费三个Partition，很均匀。

对同一个Group来说，其中的Consumer可以消费指定分区也可以消费自动分配的分区（这里是 Consumer数量和partition数量一致，均匀分配）。

如果下述情况如何处理：

  1. 如果Consumer数量大于partition数量呢？
  2. 如果Consumer数量小于partition数量呢？

这两种情况，读者可自行测试。

但要注意如下情况：

  1. 如果Consumer数量比partition数量多，会有的Consumer闲置无法消费，这样是一个浪费。

  2. 如果Consumer数量小于partition数量会有一个Consumer消费多个partition。

Kafka在partition上是不允许并发的。Consuemr数量建议最好是partition的整数倍。

还有一点，如果Consumer从多个partiton上读取数据，是不保证顺序性的。Kafka只保证一个partition的顺序性，跨partition是不保证顺序性的。增减 Consumer、broker、partition 会导致 Rebalance。

6. Kafka 分区分配策略

在Kafka中，同一个Group中的消费者对于一个Topic中的多个partition存在一定的分区分配策略——分区分配策略有如下两种：

  1. Range（默认）策略

  2. RoundRobin（轮询）策略

通过partition.assignment.strategy这个参数来设置。

6.1 Range strategy（范围分区）

Range策略是对每个主题而言的，首先对同一个主题里面的分区按照序号进行排序，并对消费者按照字母顺序进行排序。

假设我们有10个分区，3个消费者，排完序的分区将会是0,1,2,3,4,5,6,7,8,9；消费者线程排完序将会是C1-0, C2-0, C3-0。

然后partitions的个数除于消费者线程的总数来决定每个消费者线程消费几个分区。如果除不尽，那么前面几个消费者线程将会多消费一个分区。

假如在 Topic1中有10个分区，3个消费者线程，10/3 = 3，而且除不尽，那么消费者线程C1-0将会多消费一个分区，所以最后分区分配的结果是这样的：

  1. C1-0将消费0,1,2,3分区

  2. C2-0将消费4,5,6分区

  3. C3-0将消费7,8,9分区

假如在Topic1中有11个分区，那么最后分区分配的结果看起来是这样的：

  1. C1-0将消费0,1,2,3分区

  2. C2-0将消费4, 5, 6, 7分区

  3. C3-0将消费8,9,10分区

假如有两个Topic：Topic1 和 Topic2，都有10个分区。那么，最后分区分配的结果看起来是这样的：

  1. C1-0将消费Topic1的0,1,2,3分区和Topic1的0,1,2,3分区

  2. C2-0将消费Topic1的4,5,6分区和Topic2的4,5,6分区

  3. C3-0将消费Topic1的7,8,9分区和Topic2的7,8,9分区

其实这样就会有一个问题，C1-0就会多消费两个分区，这就是一个很明显的弊端。

6.2 RoundRobin strategy(轮询分区)

轮询分区策略是把所有partition和所有Consumer线程都列出来，然后按照hashcode进行排序。

最后通过轮询算法分配partition给消费线程。如果所有Consumer实例的订阅是相同的，那么partition会均匀分布。

假如按照hashCode排序完的Topic / partitions组依次为:

  • T1一5
  • T1一3
  • T1-0
  • T1-8
  • T1-2
  • T1-1
  • T1-4
  • T1-7
  • T1-6
  • T1-9

消费者线程排序为：

  • C1-0
  • C1-1
  • C2-0
  • C2-1

最后的分区分配的结果为：

  • C1-0将消费T1-5, T1-2, T1-6分区
  • C1-1将消费T1-3, T1-1, T1-9分区
  • C2-0将消费T1-0, T1-4分区
  • C2-1将消费T1-8, T1-7分区

使用轮询分区策略必须满足两个条件：

  • 每个主题的消费者实例具有相同数量的流

  • 每个消费者订阅的主题必须是相同的

1. 什么时候会触发这个策略呢?

当出现以下几种情况时，Kafka会进行一次分区分配操作，也就是Kafka Consumer的Rebalance

  • 同一个Consumer group内新增了消费者

  • 消费者离开当前所属的Consumer group，比如主动停机或者宕机

  • Topic新增了分区（也就是分区数量发生了变化）

Kafka Consuemr的Rebalance机制规定了一个Consumer group下的所有Consumer如何达成一致来分配订阅Topic的每个分区。

而具体如何执行分区策略，就是前面提到过的两种内置的分区策略。而Kafka对于分配策略这块，提供了可插拔的实现方式，也就是说，除了这两种之外，我们还可以创建自己的分配机制。

2. 谁来执行Rebalance以及管理Consumer的group呢?

Consumer group如何确定自己的coordinator是谁呢，消费者向Kafka集群中的任意一个broker发送一个 GroupCoord inatorRequest请求，服务端会返回一个负载最小的broker节点的id，并将该broker设置为 coordinator。

3. JoinGroup的过程

在Rebalance之前，需要保证coordinator是已经确定好了的，整个Rebalance的过程分为两个步骤，Join和Syncjoin：表示加入到Consumer group中，在这一步中，所有的成员都会向coordinator发送 joinGroup的请求。

一旦所有成员都发了joinGroup请求，那么coordinator会选择一个Consumer担任leader角色，并把组成员信息和订阅信息发送给消费者：

在这里插入图片描述

  • protocol-metadata：序列化后的消费者的订阅信息

  • leader id：消费组中的消费者，coordinator会选择一个作为leader，对应的就是member id

  • member metadata：对应消费者的订阅信息

  • members: consumer group中全部的消费者的订阅信息

  • generation_id：年代信息，类似于ZooKeepe 中的epoch，对于每一轮Rebalance，generation_id都会递增。主要用来保护consumer group，隔离无效的offset提交。也就是上一轮的consumer成员无法提交 offset到新的Consumer group中。

4. Synchronizing Group State 阶段

完成分区分配之后，就进入了Synchronizing Group Stat 阶段，主要逻辑是向GroupCoordinator发送SyncGroupRequest请求，并且处理SyncGroupResponse响应，简单来说，就是leader将消费者对应的 partition分配方案同步给Consumer group中的所有Consumer：

在这里插入图片描述

每个消费者都会向coordinator发送syncgroup请求，不过只有leader节点会发送分配方案，其他消费者只是打打酱油而已。

当leader把方案发给coordinator以后，coordinator会把结果设置到SyncGroupResponse中。这样所有成员都知道自己应该消费哪个分区。

Consumer group的分区分配方案是在客户端执行的！Kafka将这个权利下放给客户端主要是因为这样做可以有更好的灵活性。

7.参考文献

  1. https://dongguabai.blog.csdn.net/article/details/86536894
互联网全栈开发实战
关注
  • 3
    点赞
  • 踩
  • 14
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
springboot整合kafka，指定分区发送，批量消费，指定topic分区消费
09-26
springboot2.x整合kafka，发送者包含自定义分区发送，发送之后的回调函数，消费者有两个监听，一个是批量消费多topic，另外一个是消费指定topic的不同分区
SpringBoot整合kafka，代码简洁，自动分配分区和指定分区消费(亲测可用)
04-24
在本文中，我们将深入探讨如何将SpringBoot与Apache Kafka进行集成，实现消息生产和消费功能，同时涵盖自动分配分区和指定分区消费的策略。SpringBoot以其轻量级、快速开发的特性，深受开发者喜爱，而Kafka作为一个...
kafka--kafka的基本概念-topic和partition
weixin_39213232的博客
08-19 1667
topic是逻辑概念以Topic机制来对消息进行分类的，同一类消息属于同一个Topic，你可以将每个topic看成是一个消息队列。生产者（producer）将消息发送到相应的Topic，而消费者（consumer）通过从Topic拉取消息来消费kafka中是要求消费者主动拉取消息消费的，它并不会主动推送消息。
kafka-消费者-指定分区消费（SpringBoot整合Kafka）
最新发布
小丁的博客
06-06 721
kafka-消费者-指定分区消费（SpringBoot整合Kafka）
Kafka中的主题（Topic）和分区（Partition）是什么？它们之间有什么关系？
wzxue1984的博客
07-29 1315
每个分区是消息存储的单元，分区内的消息是有序的，并且具有递增的偏移量（Offset）。在Kafka中，生产者（Producer）将消息发布到特定的主题，而消费者（Consumer）可以从主题中订阅并消费消息。生产者在发布消息的时候，可以选择消息的键（Key），用于消息的分区和存储。在Kafka中，主题（Topic）和分区（Partition）都是用于组织和存储消息的概念，它们有密切的关系。不同的消费者可以并行地消费同一个主题的不同分区。每个分区中的消息是有序的，而不同分区之间的消息则可以并发地处理。
kafka配置参数
weixin_42496486的博客
05-21 1354
kafka常见的参数
Kafka的Partition分区详解.md
HueyLong的博客
09-28 307
一个topic可以存在一个或者多个partitionpartition与都有着密不可分的联系。
Kafka：合理设置分区数
程序员无羡的博客
04-06 3226
Kafka：合理设置分区数
kafka分区消费策略
02-21
在分布式消息系统Kafka中，分区消费策略是一个关键的概念，它决定了消息如何在消费者与生产者之间有效地流转。本文将深入探讨"Kafka分区消费策略"，以及如何实现"发送到指定分区"。 首先，我们需要了解Kafka的基本...
kafka自定义partition分发策略实例代码.zip
09-26
kafka版本:kafka_2.11-0.9.0.1 kafka jar包版本:0.9.0.1 kafka集群:192.168.1.101,192.168.1.102,192.168.1.103 ...partition分发策略主要是自定义Partitioner的实现类,通过根据key和分区数量来实现
kafka监控获取指定topic的消息总量示例
09-18
在Kafka监控中，获取指定topic的消息总量是一个关键任务，这对于了解系统的运行状态、消息处理效率以及故障排查至关重要。本文将通过一个Java示例详细解释如何实现这一功能。 首先，我们要明白Kafka是一个分布式流...
kafka消费者--指定分区消费
atarik@163.com
03-12 7837
kafka消费者有两种模式, 订阅模式和分配模式, 具体区别如下 模式 不同之处 相同之处 subscribe() 使用 Kafka Group 管理，自动进行 rebalance 操作 可以在 Kafka 保存 offset assign() 用户自己进行相关的处理 也可以进行 offset commit，但是尽量保证 group.id 唯一性，如果...
Kafka的分区
...
05-26 1383
Kafka可以将主题划分为多个分区（Partition），会根据分区规则选择把消息存储到哪个分区中，只要分区规则设置合理的话，那么所有的消息将会均匀的分布到不同的分区中，这样就实现了负载均衡和水平扩展。另外，多个订阅者可以从一个或多个分区中同时消费数据，以支持海量数据处理能力。 副本机制 由于Producer和Consumer都只会与leader角色的分区副本相连，所以Kafka需要以集群的组织形式提供主题中的消息高可用。Kafka支持主从复制，所以消息具备高可用和持久性。 一个分区可以有多个副本，这些副本
Kafka 基础概念
mrathena
12-16 1278
博文目录 文章目录使用场景基本概念 Kafka官网 Kafka最新版本文档 Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apach
9.Kafka 分区分配策略（Range分配策略 && RoundRobin分配策略）
热门推荐
扛麻袋的少年的博客
09-12 1万+
前言 在 Kafka 实际生产过程中，每个 topic 都会有 多个 partitions。 1.多个Partitions有什么好处？ ①多个 partition ，能够对 broker 上的数据进行分片，通过减少消息容量来提升 IO 性能； ②为了提高消费端的消费能力，一般情况下会通过多个 conusmer 去消费 同一个 topic 中的消息，即实现消费端的...
Kafka 实战 - 指定分区和偏移量，时间消费
qq_33240556的博客
04-10 816
总结来说，通过上述方法，Kafka 消费者可以在实战中灵活指定分区、偏移量或基于时间戳进行消息消费，以满足各种复杂的应用场景需求。在实际操作时，需要根据业务特点、数据一致性要求以及 Kafka 集群配置进行合理选择和调整。在 Apache Kafka 中，消费者可以通过指定分区和偏移量来精确控制消息消费的位置。此外，还可以基于时间戳来消费特定时间段内的消息。注意，这种方法要求 Kafka 集群启用并配置了时间戳索引，且消息带有正确的时间戳（如通过。的第 0 和第 1 分区消费消息。
kafka自定义分区实战
wh柒八九的博客
01-18 2258
本文来说下kafka自定义分区相关的知识与内容，说下springboot整合kafka如何来实现自定义分区 文章目录概述 概述
Kafka学习笔记(二):理解Kafka集群与Topic
BlueLotuss的博客
10-14 2234
上一篇博客中，我们初步了解了Kafka实质上是一个消息队列，具有异步、解耦、削峰的作用并且在mac环境下安装了Kafka相关环境，具体可以参考https://blog.csdn.net/BlueLotuss/article/details/120755867?spm=1001.2014.3001.5502。今天我们将以实战的方式深入理解 Kafka 集群的基本组件和专有术语 broker、topic、producer、consumer、partition等。 从上节课的实验，我们了解了 Kafka 的基本架
Kafka生产者分区发送数据
feizuiku0116的博客
06-10 2869
1. Kafka分区的优点 2. Kafka默认分区器DefaultPartitioner 3. Java代码实现功能 4. 自定义分区器
linux 中kafka消费者指定topic分区
04-08
可以使用Kafka提供的assign()方法，手动为消费者指定要读取的分区。例如： ```java Properties props = new Properties(); props.put("bootstrap.servers", "localhost:9092"); props.put("group.id", "test-group"); 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); TopicPartition partition = new TopicPartition("my-topic", 0); consumer.assign(Arrays.asList(partition)); ``` 这样就会将消费者指定为读取名为"my-topic"的第一个分区。如果要读取多个分区，可以在assign()方法中传入多个TopicPartition对象。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

互联网全栈开发实战

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值