kafka-producer(数据生产)笔记

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u013128262/article/details/90160317

记录下kafka生产者遇到的一些问题,主要基于0.8/0.9版本的producer api。

一、kafka简介

Kafka是最初由Linkedin公司开发,是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统)。Kafka主要被用于两大类应用:1.在应用间构建实时的数据流通道;2.构建传输或处理数据流的实时流式应用。

链接:

【logo图】
在这里插入图片描述

二、生产者基本实现

1.示意图

在这里插入图片描述

2.具体实现:

2.1 Fire-and-forget模式

发送消息后不需要逻辑程序关心是否发送成功。这个是默认的写法,依赖producer api本身的高可用(配置相关参数后失败了也会重试),且默认就是高吞吐地异步发送。绝大部分情况下数据是会成功的,但是也会有失败的情况。
官方demo

  public Producer(String topic)
  {
    props.put("serializer.class", "kafka.serializer.StringEncoder");
    props.put("metadata.broker.list", "localhost:9092");
    // Use random partitioner. Don't need the key type. Just set it to Integer.
    // The message is of type String.
    producer = new kafka.javaapi.producer.Producer<Integer, String>(new ProducerConfig(props));
    this.topic = topic;
  }
  
  public void run() {
    int messageNo = 1;
    while(true)
    {
      String messageStr = new String("Message_" + messageNo);
      producer.send(new KeyedMessage<Integer, String>(topic, messageStr));
      messageNo++;
    }
  }

优点:

  • 写法简单,且producer api本身即提供一定的高可用
  • 吞吐高,默认即异步发送

缺点:

  • 当producer api本身的高可用不可靠时即会出现一些异常的情况,且程序本身很难捕获具体那条数据异常。

2.2 同步模式

参考代码:

producer.send(record).get();

即sender()方法后再调用get()方法会同步地等待结果返回,根据结果可以判断是否发送成功。

优点:

  • 可以捕获每批发送记录的情况,并可以在业务层面做一些二次处理

缺点:

  • 吞吐下降严重

2.3 callback模式

class DemoProducerCallback implements Callback {
	@Override
	public void onCompletion(RecordMetadata recordMetadata, Exception e) {
		if (e != null) {
			e.printStackTrace();
		}
	}
}
 
producer.send(record, new DemoProducerCallback());

通过callback机制,异步地触发式检查broker返回的结果,从而检查每次发送的结果。
要使用callback函数,先要实现org.apache.kafka.clients.producer.Callback接口,该接口只有一个onCompletion方法。如果发送异常,onCompletion的参数Exception e会为非空。

callback性能损失不容小视,但其吞吐仍然远远大于同步的模式。

【性能对比测试】

总之,我们需要根据我们具体的业务场景实现我们的生产方式。

三、producer参数调优

1. acks

  • acks=-1 强一致,不会丢数据。吞吐量会下降
  • acks=0 发过去就完事了,不关心broker是否处理成功,可能丢数据。
  • acks= 1 当写Leader成功后就返回,其他的replica都是通过fetcher去同步的,所以kafka是异步写,主备切换可能丢数据。

我们现网综合权衡成本效率下,默认使用的是acks= 1。

2. retries

顾名思义,当设置为大于零的值,客户端会重新发送任何发送失败的消息。主要问题:

  • retries 不生效问题(大坑),主要是一些不可重试地异常,如“message size too large”(消息太大)
  • 写入顺序的问题:重试会导致数据写入的无序

3. serializer.class

序列化用到的类。因为一些很复杂的业务问题,我们现网中以string为主。在某些特性开发中,会使用avro。

4. compression.codec

现网一般不压缩(生产机器cpu性能不太好),特性开发场景使用Snappy偏多。

5. batch.num.messages & queue.buffering.max.ms

影响吞吐\实时性的两个指标。

  • batch.num.messages:顾名思义,一批发送的消息数量
  • queue.buffering.max.ms:队列中buff的最大时间数目(数据即使没到batch的量也会发送)

现网中需要详细地压测着两个指标,以达到吞吐和实时性之间的平衡。

四、分区问题

0.8版本的producer会存在要死broker分区的情况,导致kafka多分区之间数据不均匀的情况。
解决方法有两种:

  • api端指定key: key对应分区不存在会出现异常
  • 0.9版本api已经内置相关的算法,直接升级即可

五、其他问题

1. 生产幂等性

2. kafka生产高吞吐原理

六、kafka高可用生产的一种尝试

TBD

参考

《震惊了!原来这才是kafka!》
https://www.jianshu.com/p/d3e963ff8b70
《Kafka基础-生产者发送消息》
https://blog.csdn.net/gangchengzhong/article/details/80745974

展开阅读全文

没有更多推荐了,返回首页