大数据开发:Kafka Producer端主要参数解析

在Kafka的客户端,Producer是非常重要的一个环节,而kafka的配置,自然也包括Producer端的配置,这其中自然也就涉及到相关的参数,需要根据具体的应用场景来完成配置。今天的大数据开发分享,我们就主要来讲讲Kafka Producer端主要参数。

1、bootstrap.servers

参数含义

一组host:port对,用于创建向Kafka的连接,比如k1:9092,k2:9092,k3:9092。只需要指定一组列表即可,不需要列出集群中所有的机器。不管指定几台机器,producer都会通过该参数连接所有的kafka broker。为该参数指定多台机器只是为了fail-over使用。这样某一台broker挂掉了,producer依然可以通过该参数指定的其他broker连入kafka。

另外,如果broker端没有显式配置listeners为IP的话,这里最好使用主机名,而不是IP地址。

推荐配置

生产环境中至少3台机器的连接信息

2、{key|value}.serializer

参数含义

用于为{key|value}做序列化的,任何消息的key和value都会依据该参数指定的类转换成字节数组用于后续的发送

推荐配置

常见的是o.a.k.common.serialization.StringSerializer,即将字符串转换成字节数组。如果要实现自定义的序列化器,参考下面的步骤:

在producer项目中创建自定义序列化类C1,实现o.a.k.common.serialization.Serializer接口

设置该参数为该自定义序列化类,比如props.put(“key.serializer”,“com.abc.serialization.C1”);

3、acks

参数含义

在消息被认为是“已提交”之前,producer需要leader确认的produce请求的应答数。该参数用于控制消息的持久性,目前提供了3个取值:

acks=0:表示produce请求立即返回,不需要等待leader的任何确认。这种方案有最高的吞吐率,但是不保证消息是否真的发送成功。

acks=-1:表示分区leader必须等待消息被成功写入到所有的ISR副本(同步副本)中才认为produce请求成功。这种方案提供最高的消息持久性保证,但是理论上吞吐率也是最差的。

acks=1:表示leader副本必须应答此produce请求并写入消息到本地日志,之后produce请求被认为成功。如果此时leader副本应答请求之后挂掉了,消息会丢失。这是个这种的方案,提供了不错的持久性保证和吞吐。

推荐配置

如果要较高的持久性要求以及无数据丢失的需求,设置acks=-1。其他情况下设置acks=1

4、buffer.memory

参数含义

producer发送消息时只是将消息放入内存中的一个缓冲池中。该参数就是用来控制缓冲池大小的。值得注意的是,这不是producer使用的唯一内存区,不过倘若你要预估你的producer程序占用的内存数量(主要是堆的使用情况),那么可以粗略地使用该参数值作为一个不错的评估值。

推荐配置

默认的32MB是一个比较好的起始值。如果发现producer程序发送消息时有较长的停顿(排除是long GC停顿的原因)或是producer抛出RecordTooLargeException异常提示消息大小超过了该参数值时可以考虑增加此值。

5、retries

参数含义

顾名思义,就是producer重试的次数设置。重试时producer会重新发送之前由于瞬时原因出现失败的消息。瞬时失败的原因可能包括:元数据信息失效、副本数量不足、超时、位移越界或未知分区等。倘若设置了retries>0,那么这些情况下producer会尝试重试。注意的是,producer还有个参数:max.in.flight.requests.per.connection。如果设置该参数大约1,那么设置retries就有可能造成发送消息的乱序。

推荐配置

如果有较高的无消息丢失需求,那么设置retries为一个比较大的数,保证producer有足够的重试机会。其他情况下,关闭重试(retries=0)足矣了。

6、max.in.flight.requests.per.connection

参数含义

producer的IO线程在单个Socket连接上能够发送未应答produce请求的最大数量。增加此值应该可以增加IO线程的吞吐量,从而整体上提升producer的性能。不过就像之前说的如果开启了重试机制,那么设置该参数大于1的话有可能造成消息的乱序。

推荐配置

默认值5是一个比较好的起始点。如果发现producer的瓶颈在IO线程,同时各个broker端负载不高,那么可以尝试适当增加该值。不过一定要谨慎,因为过大增加该参数会造成producer的整体内存负担,同时还可能造成不必要的锁竞争反而会降低TPS。

7、compression.type

参数含义

producer压缩器,目前支持none(不压缩),gzip,snappy和lz4。

推荐配置

笔者试验过目前lz4的效果最好。如果有比较富裕的CPU资源,可以考虑设置该参数为lz4或gzip。由于目前代码中硬编码了snappy的某个关键参数,使得snappy的压缩效果并不好。

8、batch.size

参数含义

非常重要的producer参数!当前的producer都是按照batch进行发送的,因此batch大小的选择对于producer性能至关重要。

推荐配置

默认的16KB是个不错的起始值。如果发现producer性能不在用户线程则可以适当增加该参数值。具体数值需要结合kafka-producer-perf-test工具进行测试来确定。

9、linger.ms

参数含义

producer是按照batch进行发送的,但在何时可以发送batch的条件之中,有一条就是停留时间,即该参数指定的值。默认是0,表示不做停留。这种情况下,可能有的batch中没有包含足够多的produce请求就被发送出去了,造成了大量的小batch,给网络IO带来的极大的压力。指定该参数后,每个batch中就有可能包含更多的请求,从而减少了网络IO,提升了整体的TPS。假设设置linger.ms=5,表示produce请求可能会延时5ms才会被发送。

推荐配置

默认是0表示不做停留。如果对延时没有太高要求,可以适当设置该参数提升producer整体性能。

10、max.request.size

参数含义

最大的请求大小,也用于衡量消息大小的。如果碰到RecordTooLargeException异常,可以考虑增加该参数值。

推荐配置

默认的1MB对于生产环境都太小了,可以考虑设置成你的业务中最大的消息尺寸。

11、partitioner.class

参数含义

用于控制消息被发送到topic的哪个分区。如果要实现自定义的分区策略,创建你自己的类并实现o.a.k.clients.producer.Partitioner接口。

推荐配置

默认的DefaultPartitioner对于没有key的消息使用轮询算法,对于有key的消息采用Hash算法来确定要发送到哪个分区。

关于大数据开发,Kafka Producer端主要参数解析,以上就为大家做了大致的介绍了。在Kafka配置环节,producer端算是比较重要的一部分,对于常用的参数,建议大家还是记牢一些,实操巩固。

你可能感兴趣的:(大数据开发:Kafka Producer端主要参数解析)