9、Kafka生产者各种启动参数说明

生产者启动实例

final String kafkazk="localhost:9092";
   String topic="testAPI";
    
   Properties properties = new Properties() {{
       put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, kafkazk);
       put(ProducerConfig.ACKS_CONFIG, "all");
       put(ProducerConfig.RETRIES_CONFIG, 0);
       put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
       put(ProducerConfig.LINGER_MS_CONFIG, 1);
       put(ProducerConfig.BUFFER_MEMORY_CONFIG, 33554432);
       put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
       put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer");
   }};
   KafkaProducer<String, String> producer = new KafkaProducer<>(properties);
    for(int i=0;i<10000000;i++){
               producer.send(new ProducerRecord<>(topic, UUID.randomUUID().toString(), String.valueOf(i)));
       }
   }

启动参数配置

    acks = all
    batch.size = 16384
    block.on.buffer.full = false
    bootstrap.servers = [localhost:9092]
    buffer.memory = 33554432
    client.id =
    compression.type = none
    connections.max.idle.ms = 540000
    interceptor.classes = null
    key.serializer = class org.apache.kafka.common.serialization.StringSerializer
    linger.ms = 1
    max.block.ms = 60000
    max.in.flight.requests.per.connection = 5
    max.request.size = 1048576
    metadata.fetch.timeout.ms = 60000
    metadata.max.age.ms = 300000
    metric.reporters = []
    metrics.num.samples = 2
    metrics.sample.window.ms = 30000
    partitioner.class = class org.apache.kafka.clients.producer.internals.DefaultPartitioner
    receive.buffer.bytes = 32768
    reconnect.backoff.ms = 50
    request.timeout.ms = 30000
    retries = 0
    retry.backoff.ms = 100
    sasl.jaas.config = null
    sasl.kerberos.kinit.cmd = /usr/bin/kinit
    sasl.kerberos.min.time.before.relogin = 60000
    sasl.kerberos.service.name = null
    sasl.kerberos.ticket.renew.jitter = 0.05
    sasl.kerberos.ticket.renew.window.factor = 0.8
    sasl.mechanism = GSSAPI
    security.protocol = PLAINTEXT
    send.buffer.bytes = 131072
    ssl.cipher.suites = null
    ssl.enabled.protocols = [TLSv1.2, TLSv1.1, TLSv1]
    ssl.endpoint.identification.algorithm = null
    ssl.key.password = null
    ssl.keymanager.algorithm = SunX509
    ssl.keystore.location = null
    ssl.keystore.password = null
    ssl.keystore.type = JKS
    ssl.protocol = TLS
    ssl.provider = null
    ssl.secure.random.implementation = null
    ssl.trustmanager.algorithm = PKIX
    ssl.truststore.location = null
    ssl.truststore.password = null
    ssl.truststore.type = JKS
    timeout.ms = 30000
    value.serializer = class org.apache.kafka.common.serialization.StringSerializer

参数说明

acks参数
在考虑请求完成之前，生产者要求leader收到的确认数量，这将控制发送的记录的持久性。
acks=0如果设置为零，则生产者不会等待来自服务器的任何确认。该记录将被立即添加到套接字缓冲区并被视为已发送。在这种情况下，retries不能保证服务器已经收到记录，并且配置不会生效（因为客户端通常不会知道任何故障）。为每个记录返回的偏移量将始终设置为-1。
acks=1这意味着领导者会将记录写入其本地日志中，但会在未等待所有追随者完全确认的情况下作出响应。在这种情况下，如果领导者在承认记录后但在追随者复制之前立即失败，那么记录将会丢失。
acks=all这意味着领导者将等待全套的同步副本确认记录。这保证只要至少有一个同步副本保持活动状态，记录就不会丢失。这是最强有力的保证。这相当于acks = -1设置。
batch.size
只要有多个记录被发送到同一个分区，生产者就会尝试将记录一起分成更少的请求。这有助于客户端和服务器的性能。该配置以字节为单位控制默认的批量大小。不会尝试批量大于此大小的记录。发送给brokers的请求将包含多个批次，每个分区有一个可用于发送数据的分区。
小批量大小将使批次不太常见，并可能降低吞吐量（批量大小为零将完全禁用批次）。一个非常大的批量大小可能会更浪费一点使用内存，因为我们将始终为预期的额外记录分配指定批量大小的缓冲区。
block.on.buffer.full
当我们的内存缓冲区耗尽时，我们必须停止接受新记录（块）或抛出错误。默认情况下，此设置为false，生产者不再抛出BufferExhaustException，而是使用该max.block.ms值来阻塞，之后将抛出TimeoutException。将此属性设置为true会将其设置max.block.ms为Long.MAX_VALUE。此外，如果此属性设置为true，则参数metadata.fetch.timeout.ms不再有效。
此参数已被弃用，并将在未来版本中删除，应该使用参数max.block.ms。bootstrap.servers
用于建立到Kafka集群的初始连接的主机/端口对列表。客户端将使用所有服务器，而不管在此指定哪些服务器用于引导 - 此列表仅影响用于发现全套服务器的初始主机。该列表应该以表格的形式出现host1:port1,host2:port2,…。由于这些服务器仅用于初始连接以发现完整的群集成员资格（可能会动态更改），因此此列表不需要包含全套服务器（但您可能需要多个服务器） 。
buffer.memory
生产者可用于缓冲等待发送到服务器的记录的总内存字节数。如果记录的发送速度比发送到服务器的速度快，那么生产者将会阻止max.block.ms它，然后它会抛出异常。
这个设置应该大致对应于生产者将使用的总内存，但不是硬性限制，因为不是所有生产者使用的内存都用于缓冲。一些额外的内存将用于压缩（如果启用了压缩功能）以及维护正在进行的请求。
client.id
发出请求时传递给服务器的id字符串。这样做的目的是通过允许将逻辑应用程序名称包含在服务器端请求日志中，从而能够跟踪ip / port之外的请求源，如果不手动指定，代码中会自动生成一个id。c
ompression.type
指定给定主题的最终压缩类型。该配置接受标准压缩编解码器（‘gzip’，‘snappy’，‘lz4’）。它另外接受’未压缩’，这相当于没有压缩，这意味着保留制片人设置的原始压缩编解码器，也可以修改源码，自定义压缩类型。connections.max.idle.ms
在此配置指定的毫秒数后关闭空闲连接。
interceptor.classes
用作拦截器的类的列表。通过实现ProducerInterceptor接口，您可以在生产者发布到Kafka集群之前拦截（并可能会改变）生产者收到的记录。默认情况下，没有拦截器，可自定义拦截器。
key.serializer
用于实现Serializer接口的密钥的串行器类。
linger.ms
生产者将在请求传输之间到达的任何记录归入单个批处理请求。通常情况下，这只会在记录到达速度快于发送时才发生。但是，在某些情况下，即使在中等负载下，客户端也可能希望减少请求的数量。此设置通过添加少量人工延迟来实现此目的 - 即不是立即发送记录，而是生产者将等待达到给定延迟以允许发送其他记录，以便发送可以一起批量发送。这可以被认为与TCP中的Nagle算法类似。这个设置给出了批量延迟的上限：一旦我们得到batch.size值得记录的分区，它将被立即发送而不管这个设置如何，但是如果我们为这个分区累积的字节数少于这个数字，我们将在指定的时间内“等待”，等待更多的记录出现。该设置默认为0（即无延迟）。linger.ms=5例如，设置可以减少发送请求的数量，但会对在无效负载中发送的记录添加高达5毫秒的延迟。max.block.ms
配置控制了KafkaProducer.send()并将KafkaProducer.partitionsFor()被阻塞多长时间。由于缓冲区已满或元数据不可用，这些方法可能会被阻塞止。用户提供的序列化程序或分区程序中的阻塞将不计入此超时。max.in.flight.requests.per.connection
在阻塞之前，客户端将在单个连接上发送的最大数量的未确认请求。请注意，如果此设置设置为大于1并且发送失败，则由于重试（即，如果重试已启用），可能会重新排序消息。
max.request.size
请求的最大大小（以字节为单位）。这实际上也是最大记录大小的上限。请注意，服务器在记录大小上有自己的上限，这可能与此不同。此设置将限制生产者在单个请求中发送的记录批次数，以避免发送大量请求。metadata.fetch.timeout.ms
首次将数据发送到主题时，我们必须获取有关该主题的元数据，以了解哪些服务器托管主题的分区。此配置指定在将异常抛回到客户端之前，此获取成功的最长时间（以毫秒为单位）。
metadata.max.age.ms
以毫秒为单位的时间段之后，即使我们没有看到任何分区领导改变以主动发现任何新代理或分区，我们强制更新元数据。
metric
以metric开头的是指标相关的，后面会讨论。partitioner.class
实现Partitioner接口的分区器类。默认使用DefaultPartitioner来进行分区。receive.buffer.bytes
读取数据时使用的TCP接收缓冲区（SO_RCVBUF）的大小。如果该值为-1，则将使用操作系统默认值。
reconnect.backoff.ms
尝试重新连接到给定主机之前等待的时间量。这避免了在紧密循环中重复连接到主机。该退避适用于消费者发送给代理的所有请求。
request.timeout.ms
该配置控制客户端等待请求响应的最长时间。如果在超时过去之前未收到响应，客户端将在必要时重新发送请求，或者如果重试耗尽，请求失败。retries
生产者发送失败后的重试次数，默认0
retry.backoff.ms
尝试重试对给定主题分区的失败请求之前等待的时间量。这可以避免在某些故障情况下重复发送请求。
sasl与ssl
与kafka安全相关

新版本对应值：
bootstrap.servers
kafka集群地址，ip+端口，以逗号隔开。不管这边配置的是什么服务器，客户端会使用所有的服务器。配置的列表只会影响初始发现所有主机。配置的格式应该是:ip:port,ip:port，因为配置的内容只是用于服务集群的初始发现（集群地址可能会变化），配置可以不包含所有的服务器（你可能需要配置多于一个，防止某个服务挂掉）
key.serializer
实现Serializer接口的序列化类键
value.serializer
实现Serializer接口的序列化类值
acks
生产者认为一个请求完成，所需要kafka集群主服务的应答次数。这个配置控制已发送消息的持久性。下面是这个配置可能的值。acks=0：如果设置为0，生产者不会等待kafka的响应。消息会被立刻加到发送缓冲通道中，并且认为已经发送成功。这种情况下，不能保证kafka接收到了这条消息，retries配置不会生效，每条消息的偏移量都是1；acks=1：这个配置意味着kafka会把这条消息写到本地日志文件中，但是不会等待集群中其他机器的成功响应。这种情况下，在写入日志成功后，集群主机器挂掉，同时从机器还没来得及写的话，消息就会丢失掉。acks=all：这个配置意味着leader会等待所有的follower同步完成。这个确保消息不会丢失，除非kafka集群中所有机器挂掉。这是最强的可用性保证。
buffer.memory
生产者等待发送到kafka的消息队列占用内容的大小。如果消息发送的速度比传输给kafka快，生产者会在抛出异常后，阻塞max.block.ms的时间。这个配置应该大体与生产者用到的内存差不多，但不全是，因为生产者使用的内存不全部用于消息队列。还有些内存会被用于压缩和保持长连接。
compression.type
生产者的数据压缩类型。默认是不压缩（no compression）。有效的配置可以是none，gzip，snappy或lz4。压缩是数据的批量压缩，所以批量的效果也就是压缩的比例（压缩的比例越好，数据量越小）。
retries
配置为大于0的值的话，客户端会在消息发送失败时重新发送。重试等同于在发送有异常时重新发送消息。如果不把max.in.flight.requests.per.connection设为1，重试可能会改变消息的顺序。两条消息同时发送到同一个分区，第一条失败了，并在第二条发送成功后重新发送，那么第二条消息可能在第一条消息前到达。
ssl.key.password
存在文件中的私钥密码，对于生产者来说可选。
ssl.keystore.location
存储私钥的文件地址，可以用于不同客户端的认证。
ssl.keystore.password
私钥文件存储密码。只有当ssl.keystore.location配置了，才有用。
ssl.truststore.location
信任存储文件路径。
ssl.truststore.password
信任存储文件密码
batch.size
当多条消息需要发送到同一个分区时，生产者会尝试合并网络请求。这会提高client和生产者的效率。如果消息体大于这个配置，生产者不会尝试发送消息。发送给kafka的消息包含不同的批次，每批发送给一个分区。批次大小太小的话可能会降低吞吐量。如果设为0，会禁用批处理功能。如果批次设置很大，可能会有些浪费内存，因为我们会预留这部分内存用于额外的消息。
client.id
发送请求给kafka时带上的生产者标识。目的是为了在ip+端口之外，通过逻辑上的应用名称跟踪请求，以便记录在kafka日志中。
connections.max.idle.ms
在配置项的时间之后，关闭空闲的链接
linger.ms
消息延迟发送的毫秒数，目的是为了等待多个消息，在同一批次发送，减少网络请求。
max.block.ms
这个配置控制KafkaProducer.send()和KafkaProducer.partitionsFor()的阻塞时间，当缓冲区空间不够或者源数据丢失时阻塞
max.request.size
生产者一次请求的最大字节数，这也是一次消息体的最大值。注意到kafka集群有自己的消息限制，可能与这个值不一样。这个配置限制的是生产者一次发送消息的大小，为的是避免发送大的数据量。
partitioner.class
实现Partitioner接口的分区类
receive.buffer.bytes
socket接收缓存空间的大小，读数据时用
request.timeout.ms
生产者发送消息后等待响应的最大时间，如果在配置时间内没有得到响应，生产者会重试。
timeout.ms
kafka集群的leader等待follower响应的超时时间。