kafka学习笔记03-生产者_futurerecordmetadata-CSDN博客

本文链接：https://blog.csdn.net/zhaocuit/article/details/91354987

本文深入探讨Kafka生产者的工作流程，包括消息发送、序列化、分区策略及配置参数。解析不同消息发送模式的优缺点，阐述序列化器选择与自定义分区的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 生产者发送消息流程

1）生产消息：ProducerRecord 对象需要包含目标主题和要发送的内容。我们还可以指定键或分区。

2）序列化消息：生产者要先把键和值对象序列化成字节数组，这样它们才能够在网络上传输。

3）分区器：如果ProducerRecord 对象里指定了分区，那么分区器直接把指定的分区返回。如果没有指定分区，那么分区器会根据ProducerRecord 对象的键来计算一个分区，如果没有键，那么根据值计算分区。选好分区以后，才知道往主题的那个分区发送消息。

4）主题分区：是一个缓冲区，消息被添加到主题的某个分区的记录批次里，这个批次里的所有消息会被发送到相同的主题和分区上。

5）真正的消息发送：由一个独立的线程负责把这些记录批次发送到相应的broker 上。

6）服务器在收到某个批次的消息后会返回一个RecordMetaData 对象作为响应。它包含了主题和分区信息，以及记录在分区里的偏移量。如果写入失败，则会返回一个错误，生产者在收到错误之后会尝试重新发送消息，几次之后如果还是失败，就返回错误信息。

2. 创建生产者

创建生产者，并设置相关属性：

Properties pro=new Properties();
pro.put("bootstrap.servers","broker1:9092,broker2:9092");
pro.put("key.serializer","org.apache.kafka.comom.serialization.StringSerializer");
pro.put("value.serializer","org.apache.kafka.comom.serialization.StringSerializer");
KafkaProducer producer=new KafkaProducer<String,String>(pro);

bootstrap.servers：broker地址列表，列表不需要包含所有的broker地址，生产者会从给定的broker里查找到其他broker信息，建议提供2个，防止其中一个不可用。

key.serializer、value.serializer：key和value序列化器，即使用何种序列化器序列化key和value。

3. 发送消息到broker

消息发送方式：

1）发送并忘记：将消息发送给服务器，但井不关心它是否正常到达。大多数情况下，消息会正常到达，因为 Kafka 是高可用的，而且生产者会自动尝试重发。不过，使用这种方式有时候也会丢失一些消息。

ProducerRecord<String,String> msg=new ProducerRecord<>("主题","key","value");
try{
    producer.send(msg);
}catch(Exception e){
    
}

使用生产者的send方法发送消息。根据消息发送步骤，消息先是被放进缓冲区，然后使用单独的线程发送到服务器端。send方法会返回一个包含RecordMetaData的Future对象，不过因为我们会忽略返回值，所以无法知道消息是否发送成功，用于消息可靠性要求不高的场景。

我们可以忽略发送消息时可能发生的错误或在服务器端可能发生的错误，但在发送消息之前，生产者还是有可能发生其他的异常。这些异常有，因此一般情况下需要在catch里处理异常。

2）同步发送：调用 send方法发送消息，并返回一个Futrue 对象，再调用Futrue的 get 方法进行等待，就可以知道悄息是否发送成功。

ProducerRecord<String,String> msg=new ProducerRecord<>("主题","key","value");
try{
    Future<RecordMetaData> result=producer.send(msg);
    RecordMetaData meta=result.get();//如果服务器返回错误，get方怯会抛出异常。如果没有发生错误，我们会得到一个RecordMetaData对象，可以用它获取消息的偏移量。
}catch(Exception e){
    //ProducerRecord一般会发生两类错误：
    //一类是可重试错误 ，这类错误可以通过重发消息来解决。比如对于连接错误，ProducerRecord可以配置成自动重试，如果在多次重试后仍无能解决问题，应用程序会收到一个重试异常。
    //一类错误无出通过重试解决 ，比如消息太大、序列化消息失败、缓冲区已满、发送线程被中断等。对于这类错误，会直接抛出异常。
}

3）异步发送：调用send方法时，指定一个回调函数，服务器返回时会调用这个回调函数。

//定义一个类实现kafka的callback接口
class MyCallBack implements CallBack{
    public void onCompletion(RecordMetaData meta,Exception e){
        //如果kafka返回错误，这里的e就为非空，可以根据实际需求对异常进行处理
    }
}
ProducerRecord<String,String> msg=new ProducerRecord<>("主题","key","value");
producer.send(msg,new MyCallBack());

4. 生产者配置

1）acks：一个分区的n个副本收到消息后，才认为消息发送成功。

如果为0，表示生产者写完消息就不管了；

如果为1，表示分区的leader收到消息就认为消息发送成功。但如果分区leader节点崩溃，生产者重发也会失败，如果一个没有收到消息的从节点成为leader，消息还是会丢失。

如果为all，表示所有参与复制的分区节点全部收到消息后，才返回成功。这种模式可以保证消息不丢失，但系统吞吐量会下降。

2）buffer.memory：生产者缓冲区大小。即记录主题分区批次的内存大小，缓冲区满了，要么send方法被阻塞，要么抛出缓冲区满异常。

3）compression.type：指定消息被发送给 broker 之前使用哪一种压缩算法，默认不压缩。使用压缩可以降低网络传输开销和存储开销。

snappy：Google发明，占用较少的cpu，较好的性能和压缩比。

gzip：占用较多的cpu，更高的压缩比。

4）retries：消息重发次数。一般连接性错误，比如leader节点宕机，可以通过重试，达到可能成功发送消息，但有些错误，比如消息太大，就没有必要进行重试。

5）retry.backoff.ms：重试间隔时间。

什么情况下批次将会被发送给broker？默认情况下，只要有可用的线程，生产者就会把有消息的批次发送出去，但为了系统吞吐率，需要配置如下参数，让批次到达一定大小时，或者批次发送到达一定时间间隔时，再发送给broker。