1.acks

kafka producer向topic分区leader副本所在的broker发送消息时，leader副本会向producer发出应答。根据不同的ack参数，应答方式也不同。

acks = 0 ，producer发完消息，不等待broker端返回，直接开始发送下一条数据，很显然，如果消息发送到broker的过程中，出了问题，这条消息就丢失了，因此生产环境不建议把ack设置成0，但是这种情况下，kafka的吞吐是最高的，因为它不需要等待broker端返回结果。

acks = -1（all） ，producer发送完消息，必须要等leader副本所在的broker将消息持久化到本地磁盘，同时ISR中所有的副本和leader完成消息同步，这时候才通知producer可以继续发送消息。很显然，这种情况有点极端，吞吐量最低，但是它的安全性最高，很多不能允许消息丢失的场景可以将acks设置成-1。

ack = 1，producer发完消息，必须要等待leader副本所在的broker将数据写入本地日志，才返回消息告诉producer，我已经成功接收，这时，producer才接着发送消息。这其实上面两种方案的折中，不是严格要求消息不能丢失的场景可以考虑将acks设置成1。但是，如果在leader发送acks的时候leader副本宕机，这时候producer并不知道，producer接着发送消息，所以当leader宕机时会导致消息的丢失。

2.buffer.memory

我们知道，producer在将数据发往broker时，经过拦截器，分区器，序列化器等一系列操作，会将数据缓存到消息累加器RecordAccumulator，然后由一个专门的线程负责从消息累加器拉取数据。这个参数值得就是消息累加器的内存大小，默认时32M。当生产者往缓存中发送数据的速度大于服务器拉取的速度，缓冲区中数据就会越来越多，最后导致空间不足，这时候要么抛出异常让用户参与处理，要么send（）方法阻塞。

3.compression.type

该参数用于指定生产者对发送的消息采取的压缩类型，默认时不采取压缩，目前kafka支持三种压缩格式：LZ4，snappy和GZIP。这三种压缩格式的压缩比LZ4最高。若要使用压缩，可以配置参数

properties.put(ProducerConfig .COMPRESSION_TYPE_CONFIG,"lz4")

4.retries

kafka生产者往broker发送消息的过程中，可能会因为一些瞬时的故障导致消息发送失败，比方说网络抖动或者瞬时的leader选举。这时候我们其实没必要采用消息回调的方式来处理这种异常，因为这种异常不是消息本身问题，这时候，我们可以设置让producer自己内部实现自动的重新发送，retries参数用于设置重试的次数，默认0，不进行重试。我们可以设置成一个大于0的值，推荐设置成3-5这个值。但是有两点我们必须心里有数。

1).重试可能会导致消息的重复发送，比方说由于网络的抖动，leader副本所在的broker已经将消息持久化到本地，但是由于网络抖动，broker向leader发送相应失败，这时producer以为消息发送失败，又发送了一次，导致消息重复发送，这种情况我们可以在consumer端消费消息的时候进行去重处理。

2).重试可能导致消息的乱序，我们知道producer会将消息缓存到消息累加器中，消息累加器是一个队列，如果消息重新发送会导致消息的乱序，对于这种情况，producer提供了 max.in.flight.requets.per.connection参数，我们可以将该参数设置成1，来保证某一时刻只有只能发送一个请求。

5.batch.size

producer会将发往同一个分区的消息封装进一个batch，当batch满了会发送消息，实际中可以不等batch满了就发送消息。但是如果batch太小，显然对应的消息数量就会很少，因此一次发送请求能够写入到broker端的消息数就很少，这个参数默认值是16KB，我们可以适当调大这个参数的值来提高吞吐量。

6.linger.ms

上面说到 batch.size 时，我们提到了消息没有填满 batch 也可以被发送的情况。实际上这也是 种权衡，即吞吐量与延时之间的权衡 linger.ms 数就是控制消息发送延时行为的 该参数默认值是0 ，表示消息需要被立即发送，无须关心batch 是否己被填满，大多数情况下这是合理的 毕竟我们总是希望消息被尽可能快地发送 不过这样做会拉低 producer吞吐量，毕竟 producer 发送的每次请求中包含的消息数越多producer 就越能将发送请求的开销摊薄到更多的消息上 从而提升吞吐量。

7.max.request.size

该参数用于控制producer能够发送的最大消息的大小，默认是1M，对于一些消息很大的场景，我们是需要调大该参数的。

8.request.timeout.ms

producer发送消息给broker之后，broker需要在规定的时间之内，返回结果给producer，而这个规定的时间就是request.timeout.ms,否则就会在回调函数中显示的报超时异常。这个参数的默认值是30s，一般情况下，这个参数没什么问题，但是如果遇到producer发送消息负载很大的情况30s就有可能不够，这时候需要增大这个参数的值。