Producer常用参数整理

官网可能太慢,可以参考Kafka中文文档

 //如下参数基于Kafka 2.3 Documentation
 1. buffer.memory
  官方解释:
  生产者可用于缓冲等待发送到服务器的记录的内存总字节数。如果记录的发送速度快于它们可以发送到服务器的速度,
  则producer端将在max.block.ms参数配置的时间内阻塞,超过该时间之后将会抛出异常。
  此设置应大致对应于生产者将使用的总内存，但不是硬限制，因为生产者使用的并非所有内存都用于缓冲。
  一些额外的内存将用于压缩（如果已启用压缩）以及维护飞行中的请求。大致意思就是配置的内存并不是
  所有的都用来缓存消息数据,一部分还用作其他的事情
  默认值:33554432字节=32MB	有效值:[0,...]	重要性: high

  Kafka的客户端发送数据到服务器,不是来一条就发一条,而是经过缓冲的,也就是说,通过KafkaProducer
  发送出去的消息都是先进入到客户端本地的内存缓冲里,然后把很多消息收集成一个一个的Batch,再发送到
  Broker上去的,这样性能才可能高。

  如果buffer.memory设置的太小,可能导致的问题是：消息快速的写入内存缓冲里,但Sender线程来不及把Request发送到Kafka服务器,会造成内存缓很
  快就被写满。而一旦被写满,就会阻塞用户线程,不让继续往Kafka写消息了。 
  所以“buffer.memory”参数需要结合实际业务情况压测,需要测算在生产环境中用户线程会以每秒多少消息的频率来写入内存缓冲。经过压测,调试来
  一个合理值
 2. batch.size
  同一个分区每批次要发送数据的大小字节数
  每当多个记录被发送到同一个分区时,生产者将尝试将记录一起批处理成更少的请求,这有助于提高客
  户机和服务器的性能,此配置以字节为单位控制默认批处理大小,不会尝试批处理大于此大小的记录,
  发送到broker请求将包含多个批处理,每个分区一个批处理,其中包含可发送的数据,
  小批量将使批处理不太常见,并可能降低吞吐量(批量大小为零将完全禁用批处理),非常大的批处理大小
  可能会更浪费内存,因为我们总是会分配指定批处理大小的缓冲区,以等待额外的记录
  默认值:16384=16kb	有效值:[0,...]	重要性:medium
 3. linger.ms
  linger.ms是sender线程在检查batch是否ready时候,默认大小是0ms。
  Producer端也可能希望减少发送数据请求的数量,此设置通过添加少量的人为延迟来实现此目的,
  即Producer将通过设置linger.ms参数值来实现单条数据的延迟发送,而不是立即发送单条记录,以允许
  发送其他记录,以便可以将多条记录成批地放在一起,直到达到batch.size指定的大小时批次发送数据,
  但是如果数据一直达不到batch.size,那么sender线程并不会一直傻傻的等待,lingger.ms设置的时间就
  是该批次最后的发送期限,默认大小是0ms,代表数据发送0延迟
  那么producer是按照batch.size大小批量发送消息呢,还是按照linger.ms的时间间隔批量发送消息呢?
  这里先说结论:其实满足batch.size和ling.ms之一,producer便开始发送消息,所以batch.size和
  linger.ms要结合起来使用
  默认值:0	有效值:[0,...]	重要性:medium
 4. bootstrap.servers
  host/port列表，用于初始化建立和Kafka集群的连接。列表格式为host1:port1,host2:port2,....，无需添加所有的集群地址,kafka会根据提供的地址 
  发现其他的地址(你可以多提供几个，以防提供的服务器关闭)
  props.put("bootstrap.servers", "192.168.137.131:9092,192.168.137.132:9092");
 5. 消息K,V序列化类
  key.serializer	    key的序列化类(实现序列化接口)
  value.serializer	value的序列化类(实现序列化接口)
  props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
  props.put("value.serializer", "org.apache.kafka.common.serialization.ByteArraySerializer");
 6. acks
  生产者需要leader确认请求完成之前接收的应答数。此配置控制了发送消息的可靠性,支持以下配置：
  acks=0(可能会大量丢数据) 如果设置为0,那么生产者将不等待任何消息确认。消息将立刻添加到socket缓冲区并考虑发送。在这种情况下不能保障消息被服
  务器接收到。并且重试机制不会生效因为客户端不知道故障了没有。每个消息返回的offset始终设置为-1
  acks=1(可能会丢数据),这意味着leader写入消息到本地日志就立即响应,而不等待所有follower应答。在这种情况下,如果响应消息之后但follower还未复
  制之前leader立即故障,那么消息将会丢失。
  acks=all(-1)(数据可能重复) 这意味着leader将等待所有副本同步后应答消息。此配置保障消息不会丢失只要至少有一个同步的副本或者。这是最强壮的可
  用性保障
  默认值:1	有效值:[all, -1, 0, 1]	重要性:high
  props.put("acks", "1");
 7. request.timeout.ms
  配置控制客户端等待请求响应的最长时间,如果在超时时间过去之前未收到响应,则客户端将在必要
  时重新发送请求,或者在重试次数用尽时使请求失败
  默认值:30000		重要性: high
 8. max.in.flight.requests.per.connection
  阻塞Produce端在单个连接上发送的未确认请求的最大数量,请注意如果该参数设置为大于1,那么当
  当前批次发送失败时由于重试(如果启用重试)的存在,send线程会后台重试发送当前失败的批次,
  而客户端又没有阻塞,所以会继续接收下一批次的数据发送,如果刚好这两个批次的数据都是发往
  同一个分区,如果刚好第二批次比重试的第一批次先发送成功,那么就会出现同一个分区数据顺序
  错乱的现象,先发的数据排在后面,如果设置为1,就可以保证发送成功的数据是区内有序的
  5	[1,...]	low
 9. retries
  当前批次由于各种原因发送失败时重试次数,默认底层会重试,请注意此重试与客户端在收到错误时
  重新发送记录没有区别,意思是客户端没必要在收到失败的ACK回调时再重新发送一遍当前数据,
  该参数受到delivery.timeout.ms的限制,不论重试次数设置为多少,当达到delivery.timeout.ms
  时间限制时,即使重试次数没有用完,那么本次发送会以失败告终,所以通常我们不怎么关心该
  配置,而是使用delivery.timeout.ms来控制重试行为
  默认值:2147483647	有效值:[0,...,2147483647]	重要性:high
 10. retry.backoff.ms
  在尝试重试对给定主题分区的失败请求之前等待的时间量,这避免了在某些失败场景下以紧密循环的方
  式重复发送请求,即重试N次,每次重试之间的时间间隔毫秒数
  100	[0,...]	low
 11. delivery.timeout.ms
  生产者发送完请求接受服务器ACK的时间,该时间包括重试时间,linger.ms时间,request.timeout.ms
  时间,所以该配置应该>=request.timeout.ms + linger.ms
  120000=2分钟	[0,...]	medium
 12. List item