生产端核心参数
1. acks
参数说明：这是一个非常重要的参数，表示指定分区中成功写入消息的副本数量，这是Kafka生产端消息的持久性（durability）保证。只有当leader确认已成功写入消息的副本数后，才会给Producer发送响应，此时消息才可以认为“已提交”。该参数影响着消息的可靠性以及生产端的吞吐量，并且两者往往相向而驰，通常消息可靠性越高则生产端的吞吐量越低，反之亦然。acks有3个取值：
-
acks = 0：表示生产端发送消息后立即返回，不等待broker端的响应结果。通常此时生产端吞吐量最高，消息发送的可靠性最低。
-
acks = 1: 表示leader副本成功写入就会响应Producer，而无需等待ISR（同步副本）集合中的其他副本写入成功。这种方案提供了适当的持久性，保证了一定的吞吐量。默认值即是1。
-
acks = all或-1: 表示不仅要等leader副本成功写入，还要求ISR中的其他副本成功写入，才会响应Producer。这种方案提供了最高的持久性，但也提供了最差的吞吐量。
调优建议：建议根据实际情况设置，如果要严格保证消息不丢失，请设置为all或-1；如果允许存在丢失，建议设置为1；一般不建议设为0，除非无所谓消息丢不丢失。
2. max.request.size
参数说明：这个参数比较重要，表示生产端能够发送的最大消息大小，默认值为1048576，即1M。
调优建议：一般而言，这个配置有点小，为了避免因消息过大导致发送失败，建议适当调大，比如调到10485760即10M。
3. retries
参数说明：表示生产端消息发送失败时的重试次数，默认值为0，表示不进行重试。这个参数一般是为了解决因瞬时故障导致的消息发送失败，比如网络抖动、leader换主，其中瞬时的leader重选举是比较常见的。因此这个参数的设置显得非常重要。
另外为了避免频繁重试的影响，两次重试之间都会停顿一段时间，受参数retry.backoff.ms，默认为100ms，通常可以不调整。
调优建议：这里要尽量避免消息丢失，建议设置为一个大于0的值，比如3或者更大值。
4. compression.type
参数说明：表示生产端是否对消息进行压缩，默认值为none，即不压缩消息。压缩可以显著减少网络IO传输、磁盘IO以及磁盘空间，从而提升整体吞吐量，但也是以牺牲CPU开销为代价的。当前Kafka支持4种压缩方式，分别是gzip、snappy、lz4 及 zstd（Kafka 2.1.0开始支持）。
调优建议：出于提升吞吐量的考虑，建议在生产端对消息进行压缩。对于Kafka而已，综合考虑吞吐量与压缩比，建议选择lz4压缩。如果追求最高的压缩比则推荐zstd压缩。
5. buffer.memory
参数说明：表示生产端消息缓冲池或缓冲区的大小，默认值为33554432，即32M。这个参数基本可以认为是Producer程序所使用的内存大小。
当前版本中，如果生产消息的速度过快导致buffer满了的时候，将阻塞max.block.ms（默认60000即60s）配置的时间，超时将会抛TimeoutException异常。在Kafka 0.9.0及之前版本，建议设置另一个参数block.on.buffer.full为true，该参数表示当buffer填满时Producer处于阻塞状态并停止接收新消息而不是抛异常。
调优建议：通常我们应尽量保证生产端整体吞吐量，建议适当调大该参数，也意味着生产客户端会占用更多的内存。也可以选择不调整。
6. batch.size
参数说明：发送到缓冲区中的消息会被分为一个一个的batch，分批次的发送到broker 端，这个参数就表示batch批次大小，默认值为16384，即16KB。因此减小batch大小有利于降低消息延时，增加batch大小有利于提升吞吐量。
调优建议：通常合理调大该参数值，能够显著提升生产端吞吐量，比如可以调整到32KB，调大也意味着消息会有相对较大的延时。
7. linger.ms
参数说明：用来控制batch最大的空闲时间，超过该时间的batch也会被发送到broker端。这实际上是一种权衡，即吞吐量与延时之间的权衡。默认值为0，表示消息需要被立即发送，无需关系batch是否被填满。
调优建议：通常为了减少请求次数、提升整体吞吐量，建议设置一个大于0的值，比如设置为100，此时会在负载低的情况下带来100ms的延时。
8. request.timeout.ms
参数说明：这个参数表示生产端发送请求后等待broker端响应的最长时间，默认值为30000，即30s，超时生产端可能会选择重试（如果配置了retries）。
调优建议：该参数默认值一般够用了。如果生产端负载很大，可以适当调大以避免超时，比如可以调到60000。
9. max.in.fight.requests.per.connection
参数说明：这个参数非常重要，表示生产端与broker之间的每个连接最多缓存的请求数，默认值为5，即每个连接最多可以缓存5个未响应的请求。这个参数通常用来解决分区乱序的问题。
调优建议：为了避免消息乱序问题，建议将该参数设置为1，表示生产端在某个broker响应之前将无法再向该broker发送消息请求，这能够有效避免同一分区下的消息乱序问题。
无消息丢失配置
Producer既要保证吞吐量，又要确保无消息丢失。结合上面的参数介绍，这里给出消息无丢失的配置列表，如下：
-
acks = all or -1
-
retries = 3
-
max.in.fight.requests.per.connection = 1
-
使用带回调机制的send方法即send(record, callback)发送消息，并对失败消息进行处理
-
unclean.leader.election.enable = false
-
replication.factor = 3
-
min.insync.replicas = 2
-
enable.auto.commit = false
前3个参数本文已介绍。最后一个是消费端参数，表示禁用自动提交，后面我们再介绍。其他几个属于broker端的参数。
其中比较难理解的是min.insync.replicas，这个参数表示ISR集合中的最少副本数，默认值是1，并只有在acks=all或-1时才有效。acks与min.insync.replicas搭配使用，才能为消息提供最高的持久性保证。我们知道leader副本默认就包含在ISR中，如果ISR中只有1个副本，acks=all也就相当于acks=1了，引入min.insync.replicas的目的就是为了保证下限：不能只满足于ISR全部写入，还要保证ISR中的写入个数不少于min.insync.replicas。常见的场景是创建一个三副本（即replication.factor=3）的topic，最少同步副本数设为2（即min.insync.replicas=2），acks设为all，以保证最高的消息持久性。
来源：oschina
链接：https://my.oschina.net/u/4346143/blog/4650768