Kafka的生产者原理及重要参数说明

2401_85699020

于 2024-06-25 09:28:08 发布

阅读量951

点赞数 19

文章标签： kafka 分布式

本文链接：https://blog.csdn.net/2401_85699020/article/details/139946950

版权

当然你也可以指定一个key，作用之后会说明：

ProducerRecord<String, String> record = new ProducerRecord<>(

“test-topic”, “test-key”, “test-value”)

发送消息

带有一个回调函数，如果没有异常就返回消息发送成功。

// 这是异步发送的模式

producer.send(record, new Callback() {

@Overridepublic void onCompletion(RecordMetadata metadata, Exception exception) { if(exception == null) {

// 消息发送成功

System.out.println(“消息发送成功”);

} else {

// 消息发送失败，需要重新发送

}}});Thread.sleep(10 * 1000);

// 这是同步发送的模式(是一般不会使用的，性能很差，测试可以使用)

// 你要一直等待人家后续一系列的步骤都做完，发送消息之后

// 有了消息的回应返回给你，你这个方法才会退出来

producer.send(record).get();

关闭连接

producer.close();

干货时间：调优部分的代码

================================================================================

区分是不是一个勤于思考的打字员的部分其实就是在1那里还没有讲到的那部分调优，一个个拿出来单独解释，就是下面这一大串。

props.put(“acks”, “-1”);

props.put(“retries”, 3);

props.put(“batch.size”, 32384);

props.put(“linger.ms”, 100);

props.put(“buffer.memory”, 33554432);

props.put(“max.block.ms”, 3000);

acks 消息验证

=============================================================================

props.put(“acks”, “-1”);

Kafka的生产者原理及重要参数说明

这个acks参数有3个值，分别是-1，0，1，设置这3个不同的值会成为kafka判断消息发送是否成功的依据。Kafka里面的分区是有副本的，如果acks为-1.则说明消息在写入一个分区的leader partition后，这些消息还需要被另外所有这个分区的副本同步完成后，才算发送成功（对应代码就是输出System.out.println(“消息发送成功”)），此时发送数据的性能降低。

如果设置acks为1，需要发送的消息只要写入了leader partition，即算发送成功，但是这个方式存在丢失数据的风险，比如在消息刚好发送成功给leader partition之后，这个leader partition立刻宕机了，此时剩余的follower无论选举谁成为leader，都不存在刚刚发送的那一条消息。

如果设置acks为0，消息只要是发送出去了，就默认发送成功了。啥都不管了。

retries 重试次数（重要）

====================================================================================

这个参数还是非常重要的，在生产环境中是必须设置的参数，为设置消息重发的次数。

props.put(“retries”, 3);

在Kafka中可能会遇到各种各样的异常（可以直接跳到下方的补充异常类型），但是无论是遇到哪种异常，消息发送此时都出现了问题，特别是网络突然出现问题，但是集群不可能每次出现异常都抛出，可能在下一秒网络就恢复了呢，所以我们要设置重试机制。

这里补充一句：设置了retries之后，集群中95%的异常都会自己乘风飞去，我真没开玩笑！

代码中我配置了3次，其实设置5~10次都是合理的，补充说明一个，如果我们需要设置隔多久重试一次，也有参数，没记错的话是retry.backoff.ms，下面我设置了100毫秒重试一次，也就是0.1秒。

props.put(“retry.backoff.ms”,100);

batch.size 批次大小

===================================================================================

批次的大小默认是16K，这里设置了32K，设置大一点可以稍微提高一下吞吐量，设置这个批次的大小还和消息的大小有关，假设一条消息的大小为16K，一个批次也是16K，这样的话批次就失去意义了。所以我们要事先估算一下集群中消息的大小，正常来说都会设置几倍的大小。

props.put(“batch.size”, 32384);

linger.ms 发送时间限制

====================================================================================

比如我现在设置了批次大小为32K，而一条消息是2K，此时已经有了3条消息发送过来，总大小为6K，而生产者这边就没有消息过来了，那在没够32K的情况下就不发送过去集群了吗？显然不是，linger.ms就是设置了固定多长时间，就算没塞满Batch，也会发送，下面我设置了100毫秒，所以就算我的Batch迟迟没有满32K，100毫秒过后都会向集群发送Batch。

props.put(“linger.ms”, 100);

buffer.memory 缓冲区大小

=======================================================================================

当我们的Sender线程处理非常缓慢，而生产数据的速度很快时，我们中间的缓冲区如果容量不够，生产者就无法再继续生产数据了，所以我们有必要把缓冲区的内存调大一点，缓冲区默认大小为32M，其实基本也是合理的。

props.put(“buffer.memory”, 33554432);

那应该如何去验证我们这时候应该调整缓冲区的大小了呢，我们可以用一般Java计算结束时间减去开始时间的方式测试，当结束时间减去开始时间大于100ms，我们认为此时Sender线程处理速度慢，需要调大缓冲区大小。

当然一般情况下我们是不需要去设置这个参数的，32M在普遍情况下已经足以应付了。

Long startTime=System.currentTime();

producer.send(record, new Callback() {

@Override

public void onCompletion(RecordMetadata metadata, Exception exception) {

if(exception == null) {