在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端算是比较重要的一部分，对于常用的参数，建议大家还是记牢一些，实操巩固。