kafka生产者配置参数详解

kafka生产者配置参数

参数	配置必要性	默认值	参数说明
key.serializer	必须	org.apache.kafka.common.serialization.ByteArraySerialize	这个接口表示类将会采用何种方式序列化，它的作用是把对象转换为字节。实现了Serializer接口的类主要有ByteArraySerializer、StringSerializer、IntegerSerializer。这三种序列化器的主要区别在于处理的数据类型不同，具体使用哪种序列化器取决于你需要序列化的数据类型。
value.serializer	必须	org.apache.kafka.common.serialization.ByteArraySerialize	同上
bootstrap.servers	必须	null	指定生产者客户端连接Kafka集群所需的broker地址列表，格式为host1:port1,host2:port2
acks	高	1	此配置是 Producer 在确认一个请求发送完成之前需要收到的反馈信息的数量。 这个参数是为了保证发送请求的可靠性。以下配置方式是允许的： acks=0 如果设置为0，则 producer 不会等待服务器的反馈。该消息会被立刻添加到 socket buffer 中并认为已经发送完成。在这种情况下，服务器是否收到请求是没法保证的，并且参数retries也不会生效（因为客户端无法获得失败信息）。每个记录返回的 offset 总是被设置为-1。 acks=1 如果设置为1，leader节点会将记录写入本地日志，并且在所有 follower 节点反馈之前就先确认成功。在这种情况下，如果 leader 节点在接收记录之后，并且在 follower 节点复制数据完成之前产生错误，则这条记录会丢失。 acks=all 如果设置为all，这就意味着 leader 节点会等待所有同步中的副本确认之后再确认这条记录是否发送完成。只要至少有一个同步副本存在，记录就不会丢失。这种方式是对请求传递的最有效保证。acks=-1与acks=all是等效的。
buffer.memory	高	32M	Producer 用来缓冲等待被发送到服务器的记录的总字节数。如果记录发送的速度比发送到服务器的速度快， Producer 就会阻塞，如果阻塞的时间超过 max.block.ms 配置的时长，则会抛出一个异常。 这个配置与 Producer 的可用总内存有一定的对应关系，但并不是完全等价的关系，因为 Producer 的可用内存并不是全部都用来缓存。一些额外的内存可能会用于压缩(如果启用了压缩)，以及维护正在运行的请求。 设置buffer.memory参数时，需要考虑以下几个方面： 1、生产者客户端发送消息的频率和消息的大小：如果生产者客户端发送消息的频率较高，且消息较大，那么需要设置较大的buffer.memory参数，以避免缓存不足。 2、Kafka集群的可用内存：Kafka集群的可用内存也会影响buffer.memory参数的设置。如果Kafka集群的可用内存较小，那么需要将buffer.memory参数设置得小一些，以避免占用过多内存。 3、生产者客户端的可用内存：生产者客户端的可用内存也会影响buffer.memory参数的设置。如果生产者客户端的可用内存较小，那么需要将buffer.memory参数设置得小一些，以避免占用过多内存。
compression.type	中	none	Producer 生成数据时可使用的压缩类型。默认值是none(即不压缩)。可配置的压缩类型包括：none, gzip, snappy, 或者 lz4 。压缩是针对批处理的所有数据，所以批处理的效果也会影响压缩比(更多的批处理意味着更好的压缩)。 选择不同的压缩格式可能会影响消息的压缩率和传输效率。因此，在设置compression.type参数时，需要根据实际情况进行权衡和调整。
retries	高	0	若设置大于0的值，则客户端会将发送失败的记录重新发送，尽管这些记录有可能是暂时性的错误。请注意，这种 retry 与客户端收到错误信息之后重新发送记录并无区别。允许 retries 并且没有设置max.in.flight.requests.per.connection 为1时，记录的顺序可能会被改变。比如：当两个批次都被发送到同一个 partition ，第一个批次发生错误并发生 retries 而第二个批次已经成功，则第二个批次的记录就会先于第一个批次出现。
ssl.key.password	根据安全协议配置	null	key store 文件中私钥的密码。这对于客户端来说是可选的。
ssl.keystore.location	根据安全协议配置	null	key store 文件的位置。这对于客户端来说是可选的，可用于客户端的双向身份验证。
ssl.keystore.password	根据安全协议配置	null	key store 文件的密码。这对于客户端是可选的，只有配置了 ssl.keystore.location 才需要配置该选项。
ssl.truststore.location	根据安全协议配置	null	trust store 文件的位置。
ssl.truststore.password	根据安全协议配置	null	trust store 文件的密码。如果一个密码没有设置到 trust store ，这个密码仍然是可用的，但是完整性检查是禁用的。
batch.size	中	16384	当将多个记录被发送到同一个分区时， Producer 将尝试将记录组合到更少的请求中。这有助于提升客户端和服务器端的性能。这个配置控制一个批次的默认大小（以字节为单位）。当记录的大小超过了配置的字节数， Producer 将不再尝试往批次增加记录。发送到 broker 的请求会包含多个批次的数据，每个批次对应一个 partition 的可用数据小的 batch.size 将减少批处理，并且可能会降低吞吐量(如果 batch.size = 0的话将完全禁用批处理)。 很大的 batch.size 可能造成内存浪费，因为我们一般会在 batch.size 的基础上分配一部分缓存以应付额外的记录。 在配置batch.size参数时，需要考虑以下几个方面： 1、生产者客户端的可用内存：batch.size参数的大小会影响生产者客户端每批发送消息的字节数，如果生产者客户端的可用内存较小，那么需要将batch.size参数设置得小一些，以避免占用过多内存。 2、网络带宽和延迟：如果网络带宽较小或者延迟较高，那么需要将batch.size参数设置得小一些，以避免一次性发送过多的数据而导致网络拥塞或者延迟过高。 3、消息的大小和频率：如果生产者客户端发送的消息较大或者发送的频率较高，那么需要将batch.size参数设置得大一些，以减少每批发送消息的数量，提高吞吐量。 综合考虑以上几个方面，可以设置合理的batch.size参数。一般来说，如果生产者客户端的可用内存充足、网络带宽较大且延迟较低，那么可以将batch.size参数设置得大一些，以提高吞吐量。但是需要注意的是，如果batch.size参数设置得太大，可能会导致生产者客户端缓存不足或者网络拥塞，从而影响性能。 ps：除了batch.size参数外，还可以通过设置linger.ms参数来控制生产者客户端的发送延迟，需要根据实际情况进行权衡和调整
client.id	中	""	发出请求时传递给服务器的 ID 字符串。这样做的目的是为了在服务端的请求日志中能够通过逻辑应用名称来跟踪请求的来源，而不是只能通过IP和端口号跟进。
connections.max.idle.ms	中	540000	在此配置指定的毫秒数之后，关闭空闲连接。
linger.ms	中	0	producer 会将两个请求发送时间间隔内到达的记录合并到一个单独的批处理请求中。通常只有当记录到达的速度超过了发送的速度时才会出现这种情况。然而，在某些场景下，即使处于可接受的负载下，客户端也希望能减少请求的数量。这个设置是通过添加少量的人为延迟来实现的&mdash；即，与其立即发送记录， producer 将等待给定的延迟时间，以便将在等待过程中到达的其他记录能合并到本批次的处理中。这可以认为是与 TCP 中的 Nagle 算法类似。这个设置为批处理的延迟提供了上限:一旦我们接受到记录超过了分区的 batch.size ，Producer 会忽略这个参数，立刻发送数据。但是如果累积的字节数少于 batch.size ，那么我们将在指定的时间内“逗留”(linger)，以等待更多的记录出现。这个设置默认为0(即没有延迟)。例如：如果设置linger.ms=5 ，则发送的请求会减少并降低部分负载，但同时会增加5毫秒的延迟。 linger.ms参数可以提高Kafka生产者客户端的性能和吞吐量。一般来说，如果需要频繁发送较小的消息，可以将linger.ms参数设置得小一些，以减少等待时间，提高发送频率。如果消息较大或者发送的频率较低，可以将linger.ms参数设置得大一些，以避免频繁地发送小消息导致的网络拥塞和延迟。 如果linger.ms参数设置得太大，可能会导致生产者客户端缓存中积累过多的消息，从而占用过多内存资源。因此，需要根据实际情况进行权衡和调整，以达到最佳的性能和吞吐量。
max.block.ms	中	60000	该配置控制 KafkaProducer.send()和KafkaProducer.partitionsFor() 允许被阻塞的时长。这些方法可能因为缓冲区满了或者元数据不可用而被阻塞。用户提供的序列化程序或分区程序的阻塞将不会被计算到这个超时。 合理配置max.block.ms参数可以提高Kafka生产者客户端的稳定性和性能。如果max.block.ms参数设置得较小，那么生产者客户端会频繁地阻塞等待服务器响应，从而增加了网络延迟和CPU占用率。如果max.block.ms参数设置得较大，那么生产者客户端会等待更长的时间才能收到响应，从而增加了消息的延迟。 因此，在配置max.block.ms参数时，需要根据实际情况进行权衡和调整。一般来说，如果Kafka集群的可用性较高，网络延迟较小，可以将max.block.ms参数设置得小一些，以减少阻塞等待的时间。如果Kafka集群的可用性较低，网络延迟较大，可以将max.block.ms参数设置得大一些，以避免频繁地阻塞等待服务器响应。 需要注意的是，max.block.ms参数的设置应该与Kafka集群的可用性和网络环境相适应。如果Kafka集群的可用性较低或者网络环境较差，那么应该将max.block.ms参数设置得大一些，以避免频繁地阻塞等待服务器响应。 ps：还可以通过调整其他参数如max.request.size、receieve.buffer.bytes和send.buffer.bytes等来优化Kafka生产者客户端的性能和稳定性。这些参数的设置应该根据实际情况进行权衡和调整，以达到最佳的性能和稳定性。
max.request.size	中	1048576	请求的最大字节数。这个设置将限制 Producer 在单个请求中发送的记录批量的数量，以避免发送巨大的请求。这实际上也等同于批次的最大记录数的限制。请注意，服务器对批次的大小有自己的限制，这可能与此不同。 在Kafka中，max.request.size参数用于控制生产者客户端发送消息的最大值。生产者客户端在发送消息时，会先将消息写入到本地的内存缓冲区（buffer.memory），然后收集多个消息并组成一个Batch，再发送到Kafka服务器。这个内存缓冲区的大小由buffer.memory参数控制。 合理配置max.request.size参数可以提高Kafka生产者客户端的性能和吞吐量。如果max.request.size参数设置得较小，那么生产者客户端需要频繁地发送多个请求才能将一个Batch中的所有消息发送到Kafka服务器，从而增加了网络请求的次数和延迟。如果max.request.size参数设置得较大，那么生产者客户端可以一次性发送更多的消息，从而减少了网络请求的次数和延迟，提高了吞吐量。 需要注意的是，max.request.size参数的设置应该与Kafka集群的可用内存和网络带宽相适应。如果Kafka集群的可用内存和网络带宽较大，那么可以将max.request.size参数设置得大一些，以减少网络请求的次数和延迟，提高吞吐量。如果Kafka集群的可用内存和网络带宽较小，那么需要将max.request.size参数设置得小一些，以避免一次性发送过多的消息导致网络拥塞或者延迟过高。 另外，还需要考虑消息的大小和频率等因素。如果生产者客户端发送的消息较大或者发送的频率较高，那么需要将max.request.size参数设置得大一些，以减少每批发送消息的数量，提高吞吐量。如果生产者客户端发送的消息较小或者发送的频率较低，那么可以将max.request.size参数设置得小一些，以避免一次性发送过多的消息导致内存占用过高。
partitioner.class	中	org.apache.kafka.clients.producer.internals.DefaultPartitioner	Kafka的partitioner.class参数用于指定分区策略的实现类。Kafka的分区策略决定了消息在Kafka集群中的分布方式，不同的分区策略可能会导致不同的性能和可靠性。 在Kafka中，有几种默认的分区策略可供选择，例如轮询策略（RoundRobinPartitioner）和基于键的策略（KeyedRoundRobinPartitioner）。轮询策略将消息按照顺序分配给不同的分区，而基于键的策略则将消息按照键的顺序分配给不同的分区。 ps：默认的分区策略外，用户还可以通过实现Kafka的Partitioner接口来自定义分区策略。在自定义分区策略时，需要实现以下方法： partition(topic, key, keyBytes, allReplicas)：根据给定的主题、键、键字节和所有副本，选择一个分区进行消息的发送。 partition(topic, key, keyBytes, partitions, availablePartitions)：根据给定的主题、键、键字节、分区列表和可用的分区列表，选择一个分区进行消息的发送。 在配置partitioner.class参数时，需要指定具体的分区策略实现类。例如，如果要使用轮询策略，可以将partitioner.class参数设置为"org.apache.kafka.clients.producer.RoundRobinPartitioner"。如果要使用基于键的策略，可以将partitioner.class参数设置为"org.apache.kafka.clients.producer.KeyedRoundRobinPartitioner"。
receive.buffer.bytes	中	32768	定义读取数据时 TCP 接收缓冲区（SO_RCVBUF）的大小，如果设置为-1，则使用系统默认值。 在Kafka中，receive.buffer.bytes参数用于设置生产者客户端接收消息时的缓冲区大小。 合理配置receive.buffer.bytes参数可以提高Kafka生产者客户端的性能和稳定性。 如果receive.buffer.bytes参数设置得较小，那么生产者客户端在接收消息时可能会频繁地进行缓冲区扩展和收缩操作，从而增加了CPU的占用率和内存的消耗。如果receive.buffer.bytes参数设置得较大，那么生产者客户端可以一次性接收更多的消息，减少了缓冲区扩展和收缩的次数，提高了性能。但是，如果receive.buffer.bytes参数设置得过大，可能会导致生产者客户端的内存占用过高，从而影响其他应用程序的性能。因此，在配置receive.buffer.bytes参数时，需要根据实际情况进行权衡和调整。一般来说，如果Kafka集群的可用内存较大，可以将receive.buffer.bytes参数设置得大一些，以减少缓冲区扩展和收缩的次数，提高性能。如果Kafka集群的可用内存较小，那么需要将receive.buffer.bytes参数设置得小一些，以避免内存占用过高。 ps:还可以通过调整其他参数如batch.size、buffer.memory和max.request.size等来优化Kafka生产者客户端的性能和稳定性。这些参数的设置应该根据实际情况进行权衡和调整，以达到最佳的性能和稳定性。
request.timeout.ms	高	30000	客户端等待请求响应的最大时长。如果超时未收到响应，则客户端将在必要时重新发送请求，如果重试的次数达到允许的最大重试次数，则请求失败。这个参数应该比 replica.lag.time.max.ms （Broker 的一个参数）更大，以降低由于不必要的重试而导致的消息重复的可能性。 1、如果request.timeout.ms参数设置得较小，那么生产者客户端发送请求后等待Kafka服务器的响应时间较短，可以减少等待时间，提高性能。但是，如果Kafka服务器响应较慢或者网络延迟较大，那么生产者客户端可能会在超时时间内没有收到响应，导致请求失败。 2、如果request.timeout.ms参数设置得较大，那么生产者客户端发送请求后等待Kafka服务器的响应时间较长，可以减少请求失败的可能性。但是，如果Kafka服务器响应较快或者网络延迟较小，那么生产者客户端可能会在超时时间内收到响应，导致超时时间过长，影响性能。
sasl.jaas.config	根据安全协议配置		SASL 连接使用的 JAAS 登陆上下文参数，以 JAAS 配置文件的格式进行配置。 JAAS 配置文件格式可参考这里。值的格式: ' (=)*;'
sasl.kerberos.service.name	根据安全协议配置		Kafka 运行时的 Kerberos 主体名称。可以在 Kafka 的 JAAS 配置文件或者 Kafka 的配置文件中配置。
sasl.mechanism	根据安全协议配置	GSSAPI	用于客户端连接的 SASL 机制。可以是任意安全可靠的机制。默认是 GSSAPI 机制。
security.protocol	根据安全协议配置	PLAINTEXT	与 brokers 通讯的协议。可配置的值有: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.
send.buffer.bytes	低	131072	定义发送数据时的 TCP 发送缓冲区（SO_SNDBUF）的大小。如果设置为-1，则使用系统默认值。 在Kafka中，send.buffer.bytes参数用于设置生产者客户端发送消息时的缓冲区大小。 合理配置send.buffer.bytes参数可以提高Kafka生产者客户端的性能和稳定性。如果send.buffer.bytes参数设置得较小，那么生产者客户端在发送消息时可能会频繁地进行缓冲区扩展和收缩操作，从而增加了CPU的占用率和内存的消耗。如果send.buffer.bytes参数设置得较大，那么生产者客户端可以一次性发送更多的消息，减少了缓冲区扩展和收缩的次数，提高了性能。但是，如果send.buffer.bytes参数设置得过大，可能会导致生产者客户端的内存占用过高，从而影响其他应用程序的性能。因此，在配置send.buffer.bytes参数时，需要根据实际情况进行权衡和调整。
ssl.enabled.protocols	根据安全协议配置	TLSv1.2,TLSv1.1,TLSv1	可用于 SSL 连接的协议列表
ssl.keystore.type	根据安全协议配置	JKS	key store 文件的文件格类型。这对于客户端来说是可选的。
ssl.protocol	根据安全协议配置	TLS	用于生成SSLContext的SSL协议。默认设置是TLS，大多数情况下不会有问题。在最近的jvm版本中，允许的值是TLS、tlsv1.1和TLSv1.2。在旧的jvm中可能会支持SSL、SSLv2和SSLv3，但是由于存在已知的安全漏洞，因此不建议使用。
ssl.truststore.type	根据安全协议配置	JKS	trust store 的文件类型。
其他待定