kafka-producer配置参数

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/qq_31617409/article/details/82315303

kafka配置参数详解

参数名称	参数解释
acks	acks指定了必须有多少个分区副本接收到了消息，生产者才会认为消息是发送成功的。 acks=0，生产者成功写入消息之前不会等待来自任何服务器的响应，这种配置，提高吞吐量，但是消息存在丢失风险。 acks=1，只要集群的leader（master）收到了消息，生产者将会受到发送成功的一个响应，如果消息无撞到达首领节点（比如首领节点崩愤，新的首领还没有被选举出来），生产者会收到一个错误响应，为了避免数据丢失，生产者会重发消息。不过，如果一个没有收到消息的节点成为新首领，消息还是会丢失。这个时候的吞吐量取决于使用的是 同步发送还是异步发送。如果让发送客户端等待服务器的响应（通过调用Futu re 对象的get（）方法，显然会增加延迟（在网络上传输一个来回的延迟）。如果客户端使用回调，延迟问题就可以得到缓解，不过吞吐量还是会受发送中消息数量的限制（比如，生产者在收到服务器响应之前可以发送多少个消息）。 acks=all，所有参与复制的节点全部收到消息的时候，生产者才会收到来自服务器的一个响应，这种模式最安全，但是吞吐量受限制，它可以保证不止一个服务器收到消息，就算某台服务器奔溃，那么整个集群还是会正产运转。
buffer.memory	该参数用来设置生产者内存缓冲区的大小，缓冲生产者发往服务器的消息，如果生产者发送速率大于服务器接受速率，那么会导致生产者内存空间不足，此时send方法要么阻塞，要么爬出异常，具体行为依赖于，block.on.buffer.full参数，0.9.0.0版本中被替换成了max.block.ms用来设置抛出异常之前可以阻塞一段时间。
compression.type	消息压缩算法，snappy消耗较低的CPU并且有较为理想的压缩比和压缩性能，如果对于性能和网络带宽，这是一种比较理想的算法（Google发明的算法，Google是真牛逼），gzip算法耗费CPU资源比较多，但是提高了很高的压缩比，如果对于网络带宽有着很高的要求，那么这种算法比较适合。使用压缩可以降低网络传输开销和存储开销，这也往往是向kafka发送消息的瓶颈所在。
retries	生产者从服务器收到的错误消息有可能是临时的，当生产者收到服务器发来的错误消息，会启动重试机制，当充实了n（设置的值）次，还是收到错误消息，那么将会返回错误。生产者会在每次重试之间间隔100ms，不过可以通过retry.backoff.ms改变这个间隔。
batch.size	当多个消息发往 同一个分区，生产者会将他们放进同一个批次，该参数指定了一个批次可以使用的内存大小，按照字节数进行计算，不是消息个数，当批次被填满，批次里面所有得消息将会被发送，半满的批次，甚至只包含一个消息也可能会被发送，所以即使把批次设置的很大，也不会造成延迟，只是占用的内存打了一些而已。但是设置的太小，那么生产者将会频繁的发送小，增加一些额外的开销。
linger.ms	该参数指定了生产者在发送批次之前等待更多消息加入批次的时间。KafkaPr oduce 「会在 批次填满或linger.ms达到上限时把批次发送出去。默认情况下，只要有可用的线程， 生 产者就会把消息发送出去，就算批次里只有一个消息。把linger.ms设置成比0 大的数， 让生产者在发送批次之前等待一会儿，使更多的消息加入到这个批次。虽然这样会增加延 迟，但也会提升吞吐量（因为一次性发送更多的消息，每个消息的开销就变小了）
client.id	服务器会根据该参数值来识别消息的来源，还可以用在日志配置以及配额指标里
max.in.flight.requests.per.connection	指定了生产者收到服务器响应之前可以发送多少个消息。它的值越高，将会消耗更多的内存，不过也会提升吞吐量。设置为1，可以保证消息是按照发送的顺序写入服务器。即使发生了重试。
timeout.ms	指定了broker等待同步副本返回消息的时间，如果指定时间同步副本没有返回消息，那么将会返回错误。
requests.timeout.ms	生产者发送数据时等待服务器返回响应的时间
metadata.fetch.timeout.ms	生产者在获取元数据（例如分区首领是谁？）时等待服务器的响应时间，如果响应时间接收不到消息，那么要么重试要么返回一个错误（抛出异常或者执行回调）
max.block.ms	该参数指定了在调用send()方法或使用partitionFor() 方法获取元数据时生产者的阻塞 时间。当生产者的发送缓冲区已满，或者没有可用的元数据时，这些方法就会阻塞。在阻 塞时间达到max.block.ms 时，生产者会抛出超时异常。
max.request.size	控制生产者发送消息的大小，它可以指定单个消息的最大值，也可以指定单个请求里所有消息大小的总和。比如1MB，那么单个消息最大大小是1MB，同时如果消息大小是1KB，那么一次可以发送1000条消息。另外broker也有接受消息最大的限制，message.max.bytes,(参考博主的broker配置文章)所以两边最好能够匹配。避免生产者发送消息被broker拒绝。
receive.buffer.bytes send. buffer.bytes	这两个参数分别指定了TCP socket 接收和发送数据包的缓冲区大小。如果它们被设为-1 , 就使用操作系统的默认值。如果生产者或消费者与broker 处于不同的数据中心，那么可以 适当增大这些值，因为跨数据中心的网络一般都有比较高的延迟和比较低的带宽。
kafka可以保证一个分区内的消息是有序的，如果生产者按照一定的顺序发送消息，那么broker会按照这个顺序将他们写到分区中，消费者也会按照同样的顺序消费他们，但是！如果设置了retries大于1，而设置了max.in.flight.requests.per.connection也是大于1的数，比如是2，那么。。当消息批次1发送之后，尚未收到服务器的响应，此时消息批次2也被发送，但是，消息批次1失败了，消息批次2成功了，那么此时由于retries设置了大于1的数，所以出发了重试机制，那么消息批次1开始进行重试发送，此时假设消息批次1发送成功了，那么这样的话，尽管消息发送的顺序是：消息批次1，消息批次2，但是最终服务端的顺序确实消息批次2，消息批次1。顺序被打乱了。。。所以如果对于顺序有着严格要求，最好将 max.in.flight.requests.per.connection 设置为1，将retries设置大于1的数。这样即使发生重试，也不会打乱消息的先后顺序。